On Feb 23, 2006, at 1:01 AM, Bartek Kania wrote:

Has anybody given much

consideration to what a user object should encompass?  Have you written it

down anywhere to share? :)  I think we all *think* we know what a user

should include but somebody should try to write it down so we can give it

further consideration.  A user may need to be stored in LDAP, relationally

or as a flat-file record and be flexible enough to adapt to future needs.

We should start considering these questions now in case somebody reaches

this point in their branch or wants to run with it.


The user stuff by itself could be very simple, just an extension and a

pin-code perhaps,  that would work for the apps that require auth.

Users for iax/sip/etc are a bit more complicated tho.

I'll think about it and see if I can write up a proposal.



The user object should probably serve as a repository for any kind of user specific data, not just what's needed for authentication. This way it will be possible to achieve a very high level of integration. For example, if you configure something like voicemail in a GUI front end, you would want the GUI to automatically suggest a user's email address for the voicemail by email feature. Consequently, you'd want the user object to know one or more of the user's email addresses. Likewise, if you want to configure a Bluetooth or Jabber based presence system, you'd want to be able to fetch information about the user's Bluetooth device or Jabber account. If you want to configure follow-me/call-forwarding you will want to be able to fetch the user's cell phone number.

Also, you might want to have a user object model that allows to assign users to groups like "marketing", "technical support", "legal", "administration" etc etc.

Then you'd probably want to assign permissions based on group membership. Permissions in this context are about which type of calls a user is allowed to initiate, but also whether or not a user is permitted to make configuration changes and if so which kind of changes to what kind of data.

In certain type of setups you might even want to restrict the type of calls a user can receive. For example in a domestic setup you may want to allow young children to be able to receive incoming calls from other family members, for example the grandparents, but not from strangers. Further you may want to restrict the time during which they can receive calls.

From an ease of use point of view the whole configuration process should be centered around a user and his profile, then all the settings should be derived and propagated from there. At present we've got it upside down because we there is no concept of a user profile at all, but in order to get to a user centric model it is necessary that user profiles hold more information than just authentication credentials.

Of course, if the underlying OS has already got that user profile data available some place, then it may be sufficient to just provide a pointer and access method to it. For example, OSX has the Addressbook and the Addressbook API, and thus on OSX one could just have a user object which holds authentication credentials and a pointer to the user's Addressbook entry from where to get all the remaining data.

regards
benjk


_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev

Reply via email to