Woof! On Mon, 20 Jul 2009 16:34:43 -0400, Damian Krzeminski <[email protected]> wrote:
> 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). > I wrote: >> What about "all"? ... >> 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. Damian replied: > sipXconfig magic would be OK Okay, let's drop the "group" concept, and instead have the admin define "system-wide lists" (which may or may not be groups, that's up to sipXconfig GUI to figure out). Those lists can then be applied by individual users to their own distributions if they want. Thus it is up to a user to specify his own distro lists (as it is today), and he may choose to include a system wide one as part of his. The VM UI doesn't know about them, and keeps the current "1-9" digit selection. In summary: 1. superadmin defines system-wide lists 2. user may add system-wide lists as one of their destinations 3. there is no change to the VM UI, there are still lists "1-9" if the user has defined them. There may be some sipXconfig magic to automatically add a newly created user to an "all" system-wide list. As for implementation, Damian and I had a voice discussion about this. The current per-user distribution list is saved in a distribution.xml file in the user's voicemail directory. It is generated by sipXconfig directly (not replicated via sipXsupervisor). If these files were to be changed whenever a user is added (as would happen when the "all" list changed, for example), it would require regenerating X files for X users. As X gets bigger (say, 10,000), it becomes cumbersome. In addition, as sipXconfig doesn't replicate it, it is one of the reasons that sipXconfig must be co-resident with the voicemail files. Moving them out of the voicemail directory would be a good thing. He and I decided that moving the per user distribution lists inside the <user> definition in validusers.xml makes more sense. That way only one file is replicated on a change. In addition, the "system-wide lists" would also be defined inside validusers.xml (or possibly in a separate "systemdistributions.xml" file). The the per-user section would include system-wide lists by reference of some ID, and sipXivr would expand them as needed to the full list of users, puring duplicates. This way changing the contents of the system-wide lists don't change the per-user sections at all. As the WebUI needs a major change (superadmin screen for defining system wide lists, user screen for applying them to distribution lists), changing what config files are generated at the same time shouldn't be too difficult. While waiting for the new WebUI, sipXivr work can be done to simultaneously handle both old and new situations easily enough. File format details will be posted to the JIRA, as I work them out. --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/
