I agree that the inclusion of groups is only useful if the user has the ability to view the list of Groups and their members.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alfred Campbell Sent: Wednesday, July 15, 2009 5:56 PM To: Andy Spitzer; [email protected] Subject: Re: [sipX-dev] Discussion on XX-4844 - System/Group widedistribution lists,and ability to forward a VM to all users in voicemail system > 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> > > 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: > > <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". > > > 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 <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). > > 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: > <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). > > Very good set of options. The groups being allowed to personal distribution lists isn't "great" as many users have no idea who is in a group. I guess if the admin notifies users of the existence it would be ok. With no ability for the user to know who is in a group not sure I see this being worth much effort. Of course I am sure others have opinions :) Groups would be good for the admin created lists though and I do think the all option you have is good. My nickel. > --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/ _______________________________________________ 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/ _______________________________________________ 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/
