>>> "Andy Spitzer" <[email protected]> 07/15/09 5:30 PM >>>
Woof!
I've been thinking about how to best implement this. From the Voicemail
system's point of view, currently a user's distribution list is a simple
list of user mailboxes tied to the digit being pressed:
(index == digit pressed, destination == mailbox)
NaN.
1
201
202
NaN.
2
200
Here are three possible interpretations/implementations.
Implementation 1:
One way to view this is to have "group" defined distribution lists.
A distribution list for a group would be setup by the admin, and
would define an index and destinations just like above. It would
then "join" them somehow with the user's personal definitions and
create a per user distribution list based on what groups that user
is a member of. This is a natural fit with the way
a user gets group attributes, but can override them with personal
ones. But I believe this will be un-workable if a user is in
multiple groups, and each group defines their index "1" list
as something different. sipXconfig would then have to deal with
that somehow. Either by merging all destinations per index together
for that user, or by "moving" indicies around so there are no
conflicts.
Implementation 2:
A second way is to view a group as being a distribution list
defined as all the users in that group, and allowing the user to
specify groups as destinations in his personal list. Represented
by something like this:
NaN.
1
201
administrators/group>
group1/group>
NaN.
2
200
This defines that distribution list "1" is sent to user 201, all users
in the "administrators" group, and all users in "group1".
Implementation 3:
A third possibility is to have a "system distribution list" concept.
A system list is defined by the admin and is written out in a single
top level configuration file with the same format as Implementation 1.
The IVR would change from this:
"Please select the distribution list."
"Press Star * to cancel."
to this:
"Please select the personal distribution list."
"Press 9 for the system wide distribution list."
"Press Star * to cancel."
(presses 9)
"Please select the system wide distribution list."
"Press 9 for the personal distribution list."
"Press Star * to cancel."
This would drop the number of possible personal lists from the current
9, to 8. It might cause problems on upgrades if a person has defined
"9" already. Somehow, I don't think that is much of an issue.
Implementation 4:
Combine Implementations 2 and 3. This would define system wide lists,
as well as let users (and the system list) select groups as
destinations.
More choices:
If we were to allow tags in distribution lists, then
Voicemail would need access to what users are in what groups.
Here are two proposals to enable that.
Proposal 1:
Let sipXconfig "expand" the groups into tags.
This is great from Voicemail's point of view, nothing changes! Not
so great from sipXconfig and performance...whenever group membership
changes, sipXconfig will have to write out large numbers of files
(one per user that uses that group in one of her lists).
Proposal 2:
Have sipXconfig export group membership into in validusers.xml
This one isn't bad, only one file to update on group changes. Voicemail
can iterate through it and discover who is in what groups easily enough.
This is not difficult to implement for both Voicemail and sipXconfig.
What about "all"?
Oh yeah, that. Well, either let the admin define a group with all
users in it (or whatever users he really wants in the "all" group, which
somehow I get the feeling isn't really "all") and just specify that.
Or have the system generate a new "allusers" group that somehow new users
are magically added as part of that group on creation. That's some sipXconfig
magic that would have to occur to do that, I think.
Another way is to have a "special" name that Voicemail knows expands
to "all", as in:
~~allusers~~
And some special sipXconfig UI to allow the user to specify that. This
is a kludge, there really isn't an "~~allusers~~" group, just some
magic string that Voicemail can detect which it will expand by
iterating through the validusers.xml file.
A third way is to define yet another tag:
And some special sipXconfig UI to allow the user to specify that.
My personal choice would be Implementation 4, along with Proposal 2.
This would allow the existing personal distribution lists to be
augmented by a top level system wide distribution list. In addition,
I advocate adding the tag and letting the voicemail system
expand the group into the current members as needed. For the "all"
case, create a new "allusers" group that all new users are a member
of (allowing the admin to remove select users as desired).
--Woof!
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
</[email protected]>
** Yes. I think the overall functionality needs to be set within sipxconfig to
allow certain users with the ability to edit the group lists. Perhaps a
distribution list option would be easier to implement?
What might be more workable is to reduce the number of personal distribution
lists, and resever "9" for access to the group lists. Obviously this might only
affect the users who have access to edit or send those messages to groups.
The idea I originally had with this was to allow department managers to edit
and send these messages, and make it unseen to the average user. So if the user
is part of the distribution group (editors/senders), they would lose "1"
distribution list, but then gain a submenu of lists.
I'd really hate to task this to the superadmin to maintain, I think ti makes
more sense to task it to the people who are going to use it the most.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
