The main (but far from only) reason we use Jive on my company is the shared roster feature. It is a beautiful solution on a difficult problem However, after enjoying its benefits for some time now, I have come up with some suggestions of features I would like to see in the future:
The ability to set priority[/b] on a group: If a user belongs to two groups, the one with the highest priority is the one deciding which “Group display name” the user appears in.
The ability to set matching-rules[/b] for a group: If the user logon and match rules for a group, the user will belong to that group. Rules could be IP-address - thus enabling geografically bound groups, but also other conditions.
The ability to set groups for a user[/b] in AC (not only to set users in a group as it is now).
The ability to put a group in a group[/b]: This is to avoid the need to put users in more than one group (generally). This could maybe demand a “do not inherit to parent group” flag on the group/user coupling…
The ability to put a group-chat in a group[/b]: Some clients supports chat-groups in roster and could benefit from this. This is perhaps already be covered in JM-210?
i was thinking about this, though in our environment there are no such conditions to determine which group will user belong to. But there is already an option in Registration plugin beta version to add new users automaticly to some group. So any new user registered with server will be in roster in some temporary group and you will need to put it in right place later.
Yes, but JM-239 is for registration[/i], my suggestion means that a group could be created in such a way that all users in, lets say a ip-range, will belong to it when logging in[/i]. That way a user could belong to one group when going online from work, and another when going online from home.
Great!
I meant nested server-groups[/i]. Nested client groups would also be nice and I think JEP-0083 is about that? The point of having nested server-groups[/i] would be if you want all users in some groups to also belong to another group - and when using the shared roster feature.
After fiddeling around with public roster groups and especially after using the “Show group to members’’ rosters of these groups:”-thingy, I realize that this can be very complex feature to use, and probably even more so to develop, and this is just suggestions I came up with when using it.
such a way that all users in, lets say a ip-range,
will belong to it when logging in[/i]. That way a
user could belong to one group when going online from
work, and another when going online from home.
With JM-347 resolved this sort of feature could be added to a future version of the registration plugin, or an entirely new plugin. I can add that to my todo list.