Andy Spitzer wrote: > 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)
> > <distributions> > <list> > <index>1</index> > <destination>201</destination> > <destination>202</destination> > </list> > <list> > <index>2</index> > <destination>200</destination> > </list> > </distributions> > For the record: the internal representation has little to do with how the the distribution list is configured. The format above is actually quite flexible: we can implement the groups entirely on the sipXconfig side. > 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. > As it has been mentioned in other responses: non-admin users do not have any notion of user groups. sipXecs server side does not have any notion of user groups either (in current implementation locations are user groups but that goes away with the introduction of branch concept so you cannot rely on that.) Actually the schedules implementation gives an excellent example how distribution lists could be implemented. Administrator defines one or more schedules and it's up to the user to use those or to define their own schedules. In the same way - superadmin could predefine distribution lists and user could use them when assigning to specific indexes (in addition to being able to just list the users). > > > 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: > > <distributions> > <list> > <index>1</index> > <destination>201</destination> > <group>administrators/group> > <group>group1/group> > </list> > <list> > <index>2</index> > <destination>200</destination> > </list> > </distributions> > > This defines that distribution list "1" is sent to user 201, all users > in the "administrators" group, and all users in "group1". > I think it would be simpler if group concept were left to sipXconfig only. > > 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. > I do not think users will like it: they would have to remember which list is system and which is their own. > > 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 <group> 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 <destination> 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). That's really the best option. > > 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. sipXconfig magic would be OK > > Another way is to have a "special" name that Voicemail knows expands > to "all", as in: > <group>~~allusers~~</group> > 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: > <all></all> > 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 <group> 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! > > Let's keep the <distributions/> format intact and: (1) improve UI for the end-users so that they can create lists by selecting users (2) add notion of system distribution lists that admins define (based on user group memebership) and users can use when creating distribution list D. _______________________________________________ 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/
