Damian Krzeminski | 2 Apr 17:45

Re: [SFtrack] Created: (XCF-2414) improve management of users in paging groups

Michael Haag (JIRA) wrote:
> improve management of users in paging groups 
> --------------------------------------------
> 
> Key: XCF-2414 URL: http://track.sipfoundry.org/browse/XCF-2414 
> Project: sipXconfig Issue Type: Improvement Components: usability 
> Affects Versions: 3.10.2 Reporter: Michael Haag
> 
> 
> Currently users can only be added to a paging group one at a time.
> That's clumsy if more than a couple of users are added.  Suggested
> improvements:
> 
> - let Paging groups use existing usergroups.  The Intercom function
> already does this, so why the new approach for paging groups?  Is
> there some fundamental reason for creating separate user groups for
> paging?  It seems like a duplicate of effort for the sipx admin,
> since they may already have usergroups created which could serve as
> appropriate paging groups.
> 
> - if there is some reason why paging groups must continue to be
> separate from user groups then at least provide a UI that lets
> multiple users be displayed, sorted and selected (like on the main
> Users screen).  That way multiple users can be selected and added to
> a paging group at one time.
> 

This is a valid concern. But we need more discussion before opening a 
new issue.

The user selection UI (the page on which one selects users) is common 
for paging groups, huntgroups, ACD queues, phone lines (possibly 
something else). Contrary to what you write it does allow for adding 
more than a single user in "one shot". What it does not provide is an 
easy selection of all members of a single group.

At the minimum we could extend user selector UI so it would be easier to 
add (select) all members of the group.

Intercom is really a phone/device feature. You select phone groups; not 
users or users' groups. But your point remains valid: we could abandon 
maintaining separate users' list for paging group and let admin to 
specify user group instead. There is a difference between that approach 
and just extending user selector UI. If we let admin configure user 
group names, the paging group has to be modified whenever group 
membership changes (this is how phonebooks work). On the other hand, if 
user groups are just a convenient filter, then paging group membership 
is frozen at the time it was configured.

I see 2 improvements that we can possibly implement, but if someone has 
more ideas please share them here:
1. add "by group" filter to user selection UI
2. add capability of specifying page group membership as a list of user 
groups (in addition to current ability to select multiple individual users).

Opinions?
D.


Gmane