wikipbx-dev team mailing list archive

[Dmytro Mishchenko <wikipbx@xxxxxxxxxxxxx>]

Traun Leyden wrote:
> 
> Just one comment -- I think its really important to preserve the raw xml
> editing ability
> for power users.  So if there is a GUI for visually building extensions
> and their
> associated actions, it should still be possible for an admin user to
> skip past that
> and just work with raw xml.  
> 
> Is that the current plan?  Sorry this is a little "off topic" from the
> data model discussion.
> 

Yes, one of pre-configured action templates will be raw xml. It'll allow
user to specify xml code.

Dmitry


> Regards,
> Traun
> 
> On Mon, Jul 5, 2010 at 2:11 PM, Stas Shtin <antisvin@xxxxxxxxx
> <mailto:antisvin@xxxxxxxxx>> wrote:
> 
>     On 05.07.2010 17:17, Dmytro Mishchenko wrote:
>     > Proposing one-to-one mapping, I was thinking about simplicity of
>     > extension configuration for customer. Opening extension page user
>     choose
>     > required action and specify it's parameters. Having multiple
>     actions per
>     > extensions will require extra step in configuration: "add new action"
>     > and other operation like changing order, removing actions.
>     >
>     > Anyway, lets go with multiple actions per extension.
>     >
>     You'll also need one-to-many for dialplan editing for creating custom
>     IVRs. In fact, it seems like after adding some common built-in action
>     templates you can achieve this goal.
> 
>     >> class ActionTemplate(models.Model):
>     >>     name = models.CharField(100)
>     >>     description = models.TextField(blank=True)
>     >>     xml_template = models.TextField()
>     >>
>     >>
>     >> class ActionVariable(models.Model):
>     >>     TYPE_CHOICES = ((0, 'Selection'), (1, 'Prompt'))
>     >>     SELECTION_CHOICES = ((0, 'Local endpoint'), (1, 'Gateway'), (2,
>     >> 'Audio file')) # etc..
>     >>     FIELD_CHOICES = ((0, 'String'), (1, 'Integer'), (2, 'IP'), (3,
>     >> 'Host')) # etc...
>     >>
>     >>     template = models.ForeignKey(ActionTemplate)
>     >>     name = models.CharField(100, blank=True)
>     >>     variable_type = models.IntegerField(choices=TYPE_CHOICES)
>     >>     kind = models.IntegerField(blank=True, null=True)
>     >>     default = models.CharField(blank=True, null=True)
>     >>
>     >>     class Meta:
>     >>         unique_together = (('template', 'name'),)
>     >>
>     >>
>     >> class Extension(models.Model):
>     >>     owner = models.ForeignKey(User)
>     >>     name = models.CharField(100)
>     >>
>     >>
>     >> class Action(models.Model):
>     >>     template = models.ForeignKey(ActionTemplate)
>     >>     order = models.PositiveIntegerField()
>     >>
>     >>     class Meta:
>     >>         unique_together = (('template', 'order'),)
>     >>
>     >>
>     >> class ActionData(models.Model):
>     >>     action = models.ForeignKey(Action)
>     >>     variable = models.ForeignKey(ActionVariable)
>     >>     value = models.CharField(100)
>     >>
>     >>
>     > This model look ok for me except I don't see Action assignment to
>     > extension. So I assume Extension may look like:
>     >
>     > class Extension(models.Model):
>     >     account = models.ForeignKey(Account)
>     >     auth_call = models.BooleanField(default=True)
>     >     dest_num = models.CharField(255)
>     >     desc = models.CharField(255)
>     >     is_temporary = models.BooleanField(default=False) # ? I'm not sure
>     > if we still need this field
>     >     priority_position = models.IntegerField()
>     >
> 
>     Temporary extensions are needed in some cases, like for recording
>     soundclips with outgoing call, so that field should be kept.
> 
>     > and Action:
>     >
>     > class Action(models.Model):
>     >    extension = models.ForeignKey(Extension)
>     >    template = models.ForeignKey(ActionTemplate)
>     >    order = models.PositiveIntegerField()
>     >
>     >     class Meta:
>     >         unique_together = (extension template order)
>     >
>     Yes, I've missed the Action.extension foreign key, it's certainly
>     required there.
>     >
>     >> I don't think that any changes for adding new actions or action
>     >> templates are necessary in this case. Action templates would
>     contain a
>     >> piece of XML dialplan with some places replaceable by variables
>     and we
>     >> just have to specify all available SELECTION_CHOICES and
>     FIELD_CHOICES
>     >> values and handle them in our code.
>     >>
>     >>
>     > Right.
>     >
>     >
>     > Summarizing this discussion:
>     >
>     > - we define any possible Action template using DB model described
>     above.
>     > Action template code stored in DB, and its fields configured in DB.
>     >
>     > - we support certain numbers of internal variables like end points
>     list,
>     > extensions list, etc. and custom defined variables (defined by admin
>     > adding records to ActionVariable) that can be used in templates.
>     >
>     > - We generate HTML forms for action configuration based on
>     > ActionVariable fields description. We don't need to generate JS
>     code as
>     > was originally proposed in blueprint doc.
>     >
>     First two points look ok to me. As for generating forms - it's still
>     possible to use the approach that we originally had in mind. The biggest
>     benefit would be that client makes considerably less requests for adding
>     multiple actions. But it would require generating info about all
>     possible action templates, which would require a more complicated
>     implementation. So I agree that we should try to avoid that if possible
>     and create HTML-only output.
> 
>     > I would also like to have possibility of limiting user access to
>     certain
>     > actions. So users may not see all actions from ActionTemplate. That
>     > probably can be done with django access model, but lets take case
>     about
>     > it later.
>     >
>     Django's permission model is extensible, so you don't have to use it's
>     built-in authentication scheme (a permission is granted to a user or
>     user group), but you could override it to look up in other sources (it
>     doesn't even have to be stored in DB). In our case, I imagine it could
>     be something like ExtensionTemplateGroup model, so that each extension
>     template belongs to one (or many with many-to-many relation) and each
>     user has a relation to one (m2m could be used here as well). It should
>     be rather straightforward to add this once you have working code and
>     decide which relations make more sense for your use cases.
> 
>     On a second thought, using permissions is not really needed here at all
>     - you just adjust your queries after adding extension template groups.
> 
>     Stas.
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~wikipbx-dev
>     Post to     : wikipbx-dev@xxxxxxxxxxxxxxxxxxx
>     <mailto:wikipbx-dev@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~wikipbx-dev
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~wikipbx-dev
> Post to     : wikipbx-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~wikipbx-dev
> More help   : https://help.launchpad.net/ListHelp