[asterisk-bugs] [Asterisk 0011837]: Patch: ability to sent to multiple recipients.

Fri Feb 29 02:00:11 CST 2008

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11837 
====================================================================== 
Reported By:                travishein
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11837
Category:                   Applications/app_voicemail
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-24-2008 11:47 CST
Last Modified:              02-29-2008 02:00 CST
====================================================================== 
Summary:                    Patch: ability to sent to multiple recipients.
Description: 
for the menu option 3 (advanced), 5 (leave voice message to a recipient)

we came across the need to allow a user to be able to enter more than one
extension to send a message to (instead of the leave a message for just one
extension at a time as the current implementation was).

To make this work the logic is now
1- user presses 3, 5 to get to the leave voicemail prompt.
2- the existing prompt to enter the extension is played.
3- the user enters the extension for which to send the voicemail to
4- (NEW): the system play a message :press 1 to send message, press 2 to
add another recipient.
  if user presses 2  on this new prompt, the system returns to the step 3,
to prompt and process of entering  the extension.
  if the user presses 1 on this new prompt, the system continues to the
"please say your message" as it used to before.
5- system plays the please say your message when finished hang up.
prompt.
6- user sais their message, and hangs up, or preses pound key.

In order to realize this, we changed input gathering function so that the
char[] buffer that stores the target recipient is larger, as long as the
max receiver string. The operation of adding more recipients now builds the
delimited recipient string that leave_voicemail() understands and expects,
mainly
 extension at context&extension at context
There is also boundary checking so that if the user tries to enter more
exensions than is room in the char[] array, the system will play a (new)
vm-forward-multiple-too-many message to indicate the user is attempting to
forward the message to too many recipients.

So in addition to the attached patch file, there are two new sound audio
prompts that the system must find in the sound prompts folder, so that it
can of course play these when needed.

vm-forward-multiple : "Press 1 to enter an send message, press 2 add
another recipient"
vm-forward-multiple-too-many  : when the user has attempted to enter too
many exensions to leave a message to.

====================================================================== 

---------------------------------------------------------------------- 
 travishein - 02-29-08 02:00  
---------------------------------------------------------------------- 
Sorry to be so long in replying. I have done some reworking of this and
attached a new patch file
(app_voicemail_multi_recipient_trunk_20080228.diff), and addresses the
following items to  putnopvut's feedback items:

1. We had the MOVEHEARD patch back applied for our 1.4 series we were
running, and it seems to have snuck in there. This diff no longer has that
MOVEHEARD stuff.

2. Thats true, we were on the 1.4 branch at the time. The patch today is
against the trunk.

3. I dont seem to get warnings anymore; warnings were in the moveheard
stuff that is now removed. 

4. Yes, thats a very good point. The way it is now done is the currently
entered user is computed into a mailbox string, and then it is evaluated if
this mailbox string would fit into the recipients string, and if not play
the error message. (no more arbitrary +40 chars hack thing).

5. I think I am now handling the contexts gracefully, in that i do the
test if context is not null and sprintf it into mailbox, otherwise copy
just the mailbox. (like the 1.4 and trunk codes do for this now):
/* Make sure that context doesn't get set as a literal "(null)" (or else
find_user won't find it) */
if (context)
  snprintf(mailbox, sizeof(mailbox), "%s@%s", username, context);
else
  ast_copy_string(mailbox, username, sizeof(mailbox));

6. Not sure why the extra effort to make sure forwarding message would not
allow multiple recipients. I guess in our user base it just has not come up
yet where they would want to have to do that. Perhaps they did not want to
have to be prompted with the additional "press 1 to enter message, press 2
to add another recipient" for forwarding messages mode.   I can't see a
technical reason why we would not be able to just do the allow multiple
recipients in the both forward and leave message modes, and it would likely
be less confusing if it was consistent right. Well, what do you think ? 
For now, I have removed the checking / restriction to only do the
multi-recipient in the leave meessage mode, so forwarding a message would
receive the same feature now.

7. Yes, good point. I have cleaned the extra debug messages out, and
removed the commented out dead code parts.

8. Removed the num_receivers variable. This was following the cleaning up
of the unnecessary debug outputs from 7.

9. Had a read over coding guidelines, and now following the conventions of
same line and use of braces for single-line if statements.

So thats the going over the initial glaring problems checklist. 

For your second comment, on the possible easier way to do this in the
forward_message section, I think they actually wanted to hear the prompt
telling them to go ahead and enter another or start leaving message now.  

So what you are saying, is the user experience would be instead of (my
patch way of)
1
1234
1
2345
1
3456
2
<leave message>

it would be
1234*2345*3456
<leave message>

I guess one advantage to my patch implementation is  each extension is
validated as it is entered, instead of getting an invalid extension message
at the end of entering some really long one. ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-29-08 02:00  travishein     Note Added: 0083141                          
======================================================================