<br><br><div class="gmail_quote">On Sat, May 30, 2009 at 8:05 AM, Giuseppe Sucameli <span dir="ltr"><<a href="mailto:brush.tyler@gmail.com">brush.tyler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/5/30 Sean Bright <<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>>:<br>
<div class="im">> I'm not really sure why you would necessarily want the voicemail menu<br>
> configuration to be available to non-privileged users. Also, I don't<br>
> see why "mixing the voicemail and dialplan configuration" is any more<br>
> complex from a management standpoint than throwing:<br>
><br>
> #include "voicemail-menus.conf"<br>
><br>
> at the bottom of my extensions.conf.<br>
><br>
</div><div class="im">> So the idea is that users (of the voicemail system) can modify the menu<br>
> layouts for themselves? Or just that a non-privileged user on the<br>
> server could be made able to change voicemail menu layout?<br>
><br>
<br>
</div>2009/5/30 Giuseppe Sucameli <<a href="mailto:brush.tyler@gmail.com">brush.tyler@gmail.com</a>>:<br>
<div class="im">>> We can keep the voicemail configuration separate from the<br>
>> dialplan, so the dialplan writer will only have to dispatch the call,<br>
>> and the voicemail config will do the rest. Then one can<br>
>> import/write/modify the voicemail config without having to bother<br>
>> (or needing to have permission) to touch the dialplan itself.<br>
<br>
</div>For unprivileged users I intend users with server access but which have a<br>
restricted scope. The dialplan is the main configuration file of asterisk,<br>
instead admin can demand the manage of voicemail to another user.<br>
The inclusion in the dialplan by #include directive is dangerous in this<br>
sense.<br>
<br>
2009/5/30 Sean Bright <<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>>:<br>
<div class="im">> One of my main concerns with this sample configuration is that we are<br>
> talking about adding another domain specific language to asterisk<br>
> (extensions.conf and AEL2 being the two biggies that spring to mind).<br>
<br>
</div>This is the dev mailing list aim: discussing for new code development.<br>
This proposal is as an extension of actual app_voicemail, not a replacement<br>
by a new voicemail.<br>
<br>
About the language, I have proposed a possible solution. We can discuss<br>
which is best way to create a config file for voicemail menu using existing<br>
config languages, and when we'll find a solution using it.<br>
<br>
2009/5/30 Jonathan Thurman <<a href="mailto:jthurman42@gmail.com">jthurman42@gmail.com</a>>:<br>
>> Two file are attached (only text/plain files):<br>
>> > brief.txt<br>
<div class="im">>> explain the voicemail_menu.conf file structure and its the<br>
>> most<br>
>> important functionality<br>
>><br>
>> > voicemail_menu.conf.txt<br>
>> is an example of config file to customize the voicemail<br>
>> menu<br>
><br>
> There are some inconsistencies with your example which makes it a little<br>
> hard to follow. You have the start = ast_vm but no ast_vm section defined,<br>
> did you mean vm_menu? Also a reference to vm_setup_options when I think you<br>
> meant vm_opt.<br>
<br>
</div>Oops, your right... start = vm_menu and vm_setup_options is vm_opt.<br>
I've send the message at 3.23 AM :)<br>
</blockquote><div><br>Been there... <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
2009/5/30 Jonathan Thurman <<a href="mailto:jthurman42@gmail.com">jthurman42@gmail.com</a>>:<br>
<div class="im">> I am really looking forward to customization of voicemail. It will make<br>
> migrating customers much easier. However, I think this is a bit in depth.<br>
> So here is an idea. For basic users: Make it so that you can change the<br>
> digits dialed for the current menu items, and have the prompts say the right<br>
> thing. For advanced users: export the menu items as dialplan functions<br>
> (maybe have a global variable in voicemail.conf to turn this on/off?) so<br>
> that users can create a more dynamic voicemail application if they so<br>
> choose. It would also be nice to add some more (admin controlled) abilities<br>
> for the users to change more options (like turning on/off attachments for<br>
> your mailbox)<br>
<br>
</div>It's hard, but is a nice idea. However in this moment is a lot in depth.</blockquote><div><br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>> (3) is an interesting issue of its own.<br>
> I don't really agree, minivm is much better in supporting language<br>
> codes and date syntaxes. You can have multiple mail templates<br>
> in different languages, and set a locale code for correct date formats<br>
> in the e-mail.<br>
><br>
</div><div class="im">> I would really love someone<br>
> - Adding channel datastores to minivm to carry account info between apps<br>
> - Adding missing building blocks so that you can build a full<br>
> voicemail app<br>
> - Adding different storage methods for voicemail</div></blockquote><div><br>These are crucial in my opinion. While for some users would be very upset if they could not get voicemail as email, others don't have regular access to a computer...<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Seriously, I'll wait for your ideas.<br>
</blockquote><div><br>I was trying to get out two main ideas:<br>
<br>
1. At a minimum, allow administrators to change what digits do what per menu as they exist on the current VoiceMailMain (Not to difficult)<br>
<br>
2. Use app_minivm as the groundwork to rewrite app_voicemail as building blocks. Export those to the dialplan and use them internally by VoiceMain / VoiceMailMain to keep it simple. Depricate MiniVM, or make it a wrapper for the new app_voicemail. (MiniVM is on the right track, but as a final solution in a merger I think app_voicemail is a better name) Then we have all the functionallity without having to maintain multiple code bases.<br>
<br><br>If you want feature requests on top of all that work, let me know. =)<br><br><br>-Jonathan<br><br></div></div>