> > > > > > That's correct, the notification group would select the > > User and send > > > a message to the User's email/IM/SMS, so if we could add > the IM and > > > SMS fields to the User it would reduce the effort needed > to resolve > > > the E911 notification jira issue. > > > > Quite frankly that looks like an overkill to me. > > Think about all those case where you just want to get a > single e-mail > > alarm notification. Now you will have to configure > notification group. > > > > Don't get me wrong - I am not saying I won't take the well tested > > patch if it shows up, but please try to preserve the > manageability of > > the system for cases where you have up to 100 users and 1 > or 2 admins. > > > > If I had to choose I prefer Robert's original idea with > optional users > > groups as alarms. At least it does not introduce any new > concepts for > > the admin to master. > > Damian > > > > To simplify initial installation we could provide a default > notification Group1 with a default user "superadmin", then > the installer would only need to configure the superadmin's > email address to get all their email notifications, so no > more configuration than they do now. > > Robert's original idea didn't seem to allow the additional > notification addresses (although I guess you could add dummy > users), and may make it harder to add time-of-day notification later. > On the other hand it may be easier to write the software for this. > > Dave >
Hi Damian, I discussed this with Robert on Tuesday, we took a look at the added effort that any new alarms (with a new set of notification users) would add. Robert agrees that the "notification group" design would be easier to evolve since no software changes would be required when a new role is added. With the "user group roles" design it would require a software change to add a new role. Would you be OK with my proceeding with the "notification group" design, with a default notification group to simplify the configuration of small systems? Dave. _______________________________________________ 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/
