wikipbx-dev team mailing list archive

[Dmytro Mishchenko <wikipbx@xxxxxxxxxxxxx>]

>> we would like to make a wikipbx
>> more suitable for end customers, which might be not as technical as
>> developers. Based on that initially we would like to make changes in the
>> following areas:
>> 1. Extensions configuration
>> 2. IVR configuration
>>   
> I'd say that those are two biggest features that wikipbx is missing. For
> 0.9 we were planning to work mostly on infrastructural changes to get it
> in line with modern version of django. We would probably add feature #1
> in version 1.0 then. If you're interested in working on it, we can
> either release it in 0.9. Or maybe we'll skip that release number and
> call it 1.0 as the amount of changes gets rather big.
> 

We are interested in stable release with #1 feature. #2 can wait,
initially it'll be enough to have possibility to turn off IVR scripting
in admin backend.

If you think the current trunk is ready for release it's fine for us
too. It can be released while we are working on Extensions configurator.

>> 1. Extensions.
>> From our point of view it's a little bit complicated for end customer to
>> edit raw XML. Also it's not secure to give them this ability. We would
>> like them to configure extension filling simple form fields required for
>> chosen action.
>> Initially he has to choose Template (or we may call it Action). Then
>> based on selected action we show action specific fields.
>> E.g.
>> - when user choose Local Endpoint we give him picklist of existing
>> endpoints.
>> - when user choose "Conference Room" we give him list of configured
>> conference rooms.
>> - when user choose "Echo test" we don't ask him anything extra
>> - when user choose "Speak text" we ask him to enter text and choose type
>> of voice. etc...
>>   
> We've been thinking about that some time ago. Traun had the general idea
> and I've written my thoughts about implementing it. What we wanted to do
> is to create a way to add templates for extensions that could prompt
> user for values. It looks like that would do just what you want, so I'll
> create a blueprint for that issue later and we'll discuss it then. I
> think it can be done in reasonable amount of time.
> 
Sounds ok to me. Lets create blueprint asap so we can move on with it.

>> 2. IVR.
>> We would like to give user ability to configure IVR visually without
>> having him to write Python, Lua, JS code. This part will be implemented
>> later.
>>   
> I've thought about something like this before. It's definitely a cool
> thing to have - otherwise we have to choose a secure or powerful system,
> but not both. We weren't going to work on such feature in near future
> and just briefly discussed a few times.
> 
> Here's one possible approach. It would give user access to some system
> APIs (numeric, regex and string operations; date and time), his data
> (gateways, endpoints), call control (bridge, hangup, transfer) and
> programming structures (variables, arrays, if/case switches, loops).
> There would be a WYSIWYG editor that would output JSON data structures
> that could be compiled into actual IVR code (i.e. mod_python). The
> problem is that it's rather complicated.
> 

I'm thinking about more simple solution. Except general IVR settings
like announcement, timeout, etc. we allow customer to choose action
performed when digit is pressed. List of these action is limited.
E.g.:
- another IVR
- extension
- ... action based on pre-configured template. E.g. Playing certain
instructions.

Action - can be implemented using the same kind of templates "that
prompt for values" as you describe in extension configurator.

Examples of templates:
name: ivr; parameters: ivr_name
name: extension; parameters: ext #
name: play_file; parameters: recording_file_name
name: speak_text; parameters: type_of_voice, text_to_speak
...

That should be enough for 90% of customers. Templates for combined cases
like "play_file then speak_text" can be created by admin on customer
request.

These actions will be building blocks for IVR and they can be put
together in some visual way.

> A simpler approach would be to let admin users write IVR scripts and
> share it with all/some users. However, I'm pretty sure that most admins
> in the real world won't be able to do it, even in a language as simple
> as python. We could create a library with common IVR scripts for them,
> but it's still impossible to customize their functionality without
> programming knowledge and it isn't fool-proof.
> 

I'm thinking about scripting library as an addition to IVR actions
described above. They can be used together for more complicated stuff
where dialplan XML is not enough. Scripts should be editable only by
wikipbx admin (initially even outside web gui) if he knows what he is
doing.

Dmitry


> Do you have some ideas for a simpler solution?
> 
>> For both #1 and #2 I think we should keep possibility to allow certain
>> users to use raw XML or ivr scripts code.
>> Probably it can be controlled by administrator at "Accounts" page by
>> checking checkboxes to allow raw extensions or scripting IVR. So some
>> users will be able to use both interfaces.
>>   
> Yes, it's a good idea to have an ability to override the safe but
> limited way of doing things for trusted users.
> 
>> Please let me know how does it sound for your. I would be glad to hear
>> any notes or development instructions. If you think it is worth to talk
>> on the phone (or skype) and discuss this stuff it'll be great too.
>>
>> I've installed trunk version and started to play with it. Some pages
>> were not working so I committed fixes and minor improvements to a
>> separate branch at LP lp:~wikipbx/wikipbx/wikipbx-dt-dev
>> I hope you have access to it. Please take a look.
>>   
> That's great - I was sure there were places that got broken. Thanks for
> taking care of it, I've had a look at your changes and merged them to trunk.
> 
> Stas.
> 
> 
>