> 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/
