rajumesfin / avaajotalo Goto Github PK

Admin mode currently doesn't allow you to approve/reject pending messages.
One way to implement this is to simply add an additional prompt in the
normal flow of the forum, but this may not be ideal for a forum with
replies (you'd have to fish through all threads for pending replies).

I propose a simple pending messages section in admin mode, coming off of
the main menu. It will be like an aggregated version of the inboxes present
in the admin console (for all forums). Admins listen to pending top-level
posts and/or replies one by one and are prompted to approve/reject after each.

A drawback of this simple approach is that replies are moderated without
other parts of the thread, though we can add an option to allow the admin
to listen to the thread. I just am concerned about how complicated that
will get.

Let me know your thoughts.

doesn't take you back; goes to next

Again, not sure if this applies to the new code, but there is a problem
with this check in that a top level msg can have rgt>2 but may not have
*approved* replies. So you could hear a prompt to listen to replies but
then the list be empty.

On balance this seems like not a huge deal so im keeping the priority low

The DSC server should run both web server and freeswitch on boot

not enough time for even me to decide to respond

the option should repeat, not cancel by default. People may just be indecisive.

In general, we should never take any action for the user by default but
wait till they choose

when i go to radio as admin and barge in with 0 it takes me to listen to
the messages

Our app-level logging doesn't tell us how many calls we are getting to the
system, but I'm guessing FS logs do. Can we verify this and perhaps
implement a simple script to give us call stats?

doesn't work

I usually bypass the record instructions by pressing 1, but that doesn't go
to the beep anymore.

If u are skipping through messages, it doesnt prompt to listen to replies

on no input it defaults to forum 1
on bad input it says no forum and hangs up

Neither of these seem very good. Let's just repeat the welcome prompt on both.

recordmessage requires you to specify the rgt position to place the new
message. When recording multiple replies to the same message succession, we
do not update the rgt value of the parent message that we pass to
recordmessage each time.

I haven't checked if you address this in the refactored code, but keep it
in mind.

back doesn't go beyond the list of messages you're in, or the replies
you're in. Seems like back should be analog of mini-next (#1).

Given how the code is laid out this could be a challenge, so feel free to
re-prioritize.

otalo.lua and responder.lua both record messages in pretty much the same
way. Merge the functions.

This means responder should have consideration for admin privileges when
setting the message status. 

when summary file present, summary is played but when you choose 1 to
listen to content it doesn't work.

Messages should be tag-able through the web console. For AO, a simplified
version of free-form tagging will be implemented: admins will select from a
pre-defined set of crops, and agricultural topics (we will use the taxonomy
from the transcription of content last summer). The interface will present
two combo boxes, one for crop, the other for topic. At least one tag will
be required in order to approve/reject a message.

Data model changes:

A Tag table will define all possible tags in the system. It will be seeded
by the crop and topic tags for AO, but can be extended to allow free-form
tagging later on.

A MessageTag join table will map MessageIds to TagIds.

inbound and outbound will both need this

DB

We need a prompt telling the user that the message has been paused, and
that they should press 2 again to restart it.

setup a nightly db backup on the server.

doesn't bypass instructions. I liked that in the earlier version

right now this doesn't go back to the previous message. It would be nice,
though I don't think essential

to be able to approve/reject

keep posts/responses disallowed

goes back to the forum (or message if recording a response) instead of back
all the way to MM

in console, only show this if necessary

A couple issues with logging that may or may not be already addressed:

1. The timestamp. Can you verify that this converts to an accurate date and
time? I'd also like to verify that its accurate on the server here.

2. The goal of the log is to record each call's trail, so every step should
be indicated and we should be able to piece an individual call's trail
together. Does the log allow us to differentiate between calls (for callers
who keep re-dialing in rapid succession, which we saw with AO 1.0)? Can we
accurately track which msgs (identified by id for eg) were listened to?
Responses Do we log re-records? 

Just going through the script with a comb and adding places that logging is
probably all that's needed here

With obvious ramificiations.

What steps will reproduce the problem?
1. have a forum with two msgs
2. on the 2nd msg, choose command back
3. prompt says, "first message"

There used to be logic that first checked if back was clicked so the prompt
is "previous message" even for the first msg.

After recording a message, takes you back to the main menu instead of
listening to messages in that forum.

order list of messages by date

1. Record a message on any forum
2. press 0

Should go to main menu

let's add a 5 second pause after all the options have been read from the
main menu. There is no rush to repeat the prompt again.

Main problem: comments are all getting created with status=APPROVED for
non-admins; looks like you are not passing around moderated.

Subtler problem: when I am listening to replies and i bargein with a 2
(record response), the recorded msg gets created as a sub-reply of that
reply (i.e. lft/rgt are set so that this reply's parent is the reply that
you barged in on) instead of the parent message.

Finally, I see that after recording a reply the replies are not re-fetched
from the db so if you happen to be an admin who should actually get things
approved immediately, you don't see your reply until you nav away from that
parent msg and come back. This part is probably not critical to fix.

When an answer is recorded to AO, the questioner is alerted by the system
through a missed call. The questioner then calls AO and navigates the
regular interface to get listen to the answer either on the forum or in
their personal inbox (implemented as a third option of the forum).

A data model change is required if we include the personal inbox: a new
parameter for the forum object for the personal inbox option.

It doesn't look like we are logging when a call enters the MM, and what
option is chosen from there. This is clearly necessary.

currently it requires pressing #

Tap, let me know if this was deliberate and why

What steps will reproduce the problem?
1. make sure inbox x is empty and go to radio
2. click on inbox x

the controls for radio remain

When a msg is paused, some commands (0, 1, 6) work. I think when paused
either all commands should be disabled but unpause (to avoid accidental
commands) or all buttons should unpause.

for both test and production server. According to Django tutoria #1, it is
a security risk keeping it there.

There are several places where listen periods for user input are too short.
A couple in particular are to record a reply to a message after listening
to replies and choosing a forum.

We should decide on a standard wait period for everything and access it as
a constant

nice to have

nice to have

The current keypad mapping (3 FWD, 4 BACK, 5 REPLAY) is awkward, and doesnt
take advantage of the natural mapping between fwd and back.

Also, the prompt describing this mapping is also quite complicated.

I suggest only describing the FWD functionality in the prompt, and then
leaving the rest to advanced users.  I also suggest a mapping of 1-FWD,
2-BACK and 3-REPLAY (although that still doesnt match the mental model).

the mysql driver has a known memory leak; so switch asap

I don't think these are important to keep around and they just clutter up
the directory.

What steps will reproduce the problem?
1. add two msgs to a forum
2. listen to both
3. right after the last message, go back and listen to the last message again

You will get this error:
2009-12-17 17:23:28.576847 [ERR] mod_lua.cpp:182
/usr/local/freeswitch/scripts/AO/otalo.lua:63: calling 'fetch' on bad self
(cursor is closed)
stack traceback:
    [C]: in function 'fetch'
    /usr/local/freeswitch/scripts/AO/otalo.lua:63: in function 'msgs'
    /usr/local/freeswitch/scripts/AO/otalo.lua:414: in function 'playmessages'
    /usr/local/freeswitch/scripts/AO/otalo.lua:327: in function 'playmessage'
    /usr/local/freeswitch/scripts/AO/otalo.lua:379: in function 'playmessages'
    /usr/local/freeswitch/scripts/AO/otalo.lua:617: in function 'playforum'
    /usr/local/freeswitch/scripts/AO/otalo.lua:642: in main chunk


The cause is that you are trying to get from the cursor even though it has
been emptied out. The logic needs to differentiate between a
current_msg_idx that has exceeded the size of the forum (truly last msg)
and current_msg_idx has exceeded the msgs that have not yet been heard
(curr_msg_idx > #prevmsgs check). See
http://code.google.com/p/avaajotalo/source/diff?spec=svn26&r=26&format=side&path
=/trunk/IVR/otalo.lua
line 357-362 for how this used to work.

The just replay from the beginning.

This likely seems related to introducing mp3s instead of wavs.

All of the new voice prompts give me the following warning:

2009-12-07 16:00:40.844359 [WARNING] switch_core_file.c:120 Sample rate
doesn't match

Check the sample rate (8000Hz).

otalo.lua doesn't create message_forum objects for responses, even though
it should. Fix this, and patch the db for any messages without message_forums.