[asterisk-gui] Opinion, what do you want in the gui for users?

[santosam at alexandre-santos.com]

Firtly I would like to say that I'm very happy with the number of emails
this list is getting :-) We're going on the right track.

Before Asterisk I had a Siemens HiPath PBX. It had two BRI and 8
extensions (4+4). The configuration was done with a digital phone (a
Siemens specific for that PBX series) or using a software, only available
to the Siemens partners. All configuration was done by professionals and
the users couldn't change anything.
Before this experience I worked in big company that had several Nortel
Meridian PBX with thousands extensions. Here the configuration was done by
an outsourcer.
This two paragraphs above make me ask all a simple question: is this GUI
intended for the end user that has a softphone that sometimes needs to
change his VM password or is it a GUI for admins, just like that Siemens
software?


> On Fri, Apr 13, 2007 at 04:39:11PM -0500, Pari Nannapaneni wrote:
>> > that if you give someone access to configuration (i.e. enable the
>> > 'config' option) you are giving them blanket access to the PBX's
>> > configuration files -- including other user's passwords, the passwords
>> > for your various ITSP accounts, etc.
>>
>> As most of the users personal settings can be managed from users.conf,
>> We
>> can have a modified version of
>> getconfig for the user (something get_myconfig ) using which the user
>> can
>> retrieve/edit only
>> his section (context) of users.conf.
>>
>> This would let the user change most of the things he wants to manage
>> like
>> email adress, vm passwords,
>> sip/iax passwords etc, but we will soon run into the same problem as
>> steve
>> mentioned here - which is
>> this would also give the user ability to change his dialplan etc which
>> is
>> probably not what we want.
>
> This should be done very carefully. Should a user be allowed to change
> the context into which its extension goes?
>
> I'm sure that there are some other ways this allows users to inflict
> damage on the system
>
>>
>> So using a database looks like the most logical thing here as we can
>> define
>> a per entry basis
>> permissions using a database.
>
> Why?
>
> sqlite does not have any inherent permissions system. Thus if you want
> such an authorization layer, it would have to be implemented by the
> application. And hence indirect access to the database by any
> third-party program will break it.
>
> And I don't think you want to depend on an external server to store all
> the configuration.
>
>> Infact we can even implement multiple levels
>> of user privileges
>> if we have database - like [SuperAdmin] --> [admin1, admin2..]-->
>> [user1,
>> user2, user3, user4..] etc.
>> It also have additional benefits like ease of use, ability to do CDR
>> stuff,
>> ability to do detail statistics/reports of queues and other resources
>> like
>> cpu/network/disk usage etc.
>
> This requires too much application logic inside the permissions system,
> IMHO. We'll end up with a huge and monolithic permissions system that
> can only be manipulated by the GUI.
>
> --
>                Tzafrir Cohen
> icq#16849755                    jabber:tzafrir at jabber.org
> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
> http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-gui mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-gui
>