History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JM-802
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Gaston Dombiak
Reporter: Gaston Dombiak
Votes: 16
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
Openfire

Add support for not showing a shared group to its group members

Created: 08/08/06 03:03 PM   Updated: 04/05/07 06:56 PM
Component/s: Core
Affects Version/s: 3.0.1
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Related to
 

Support Plan Customer Issue: No
Acceptance Test - Add?: No


 Description  « Hide
Sometimes it may be required to create a group and add a list of members. However, the new group is not required to appear in the members' rosters but only to some other list of groups. This means that only selected groups in "Show group to members' rosters of these groups:" will be able to see this group but not the group members (unless they belong to a group of the list).

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Harald Steindl - 08/08/06 03:10 PM
A typical scenario would be to link a pool of support people to a group of sales guys:
Users Ext1 and Ext2 are members of group EXTERNALS
Users Tech1 and Tech2 are members of group TECHIES

Now configure Group EXTERNALS with "Group Display Name "Externals" and "Show group to members' rosters of these groups: TECHIES"
2. configure Group TECHIES with "Group Display Name "Techies" and "Show group to members' rosters of these groups: TECHIES + EXTERNALS"

As far as I understand it, that should show
a) Ext1, Ext2, Tech2 in the Roster of Tech1 (because of 1. & 2.)
b) Ext1, Ext2, Tech1 in the Roster of Tech2 (because of 1. & 2.)
c) Tech1, Tech2 in the Roster of Ext1 (because of 2.)
d) Tech1, Tech2 in the Roster of Ext2 (because of 2.)

Fact (bug?) is that
e) Ext1 sees ALSO Ext2 in his roster
f9 Ext2 sees ALSO Ext1 in his roster


Harald Steindl - 09/06/06 07:43 AM
Hi!

Is there any pricetag on solving this anytime soon?
I am desparately waiting for it.


James Clements - 09/15/06 11:43 AM
Im desperate for this feature or bug fix as well

Any news?


Matt Tucker - 09/15/06 05:52 PM
Hey guys – if you would be willing to sponsor development of this feature, please drop me an email!

Thanks,
Matt


James Clements - 02/18/07 06:56 AM
Its been a hile since any post was made here. Any news on when this issue might be addressed? Whether the fix is sponsred or not over 6 months is still a long time to wait with no indication of anything being done. Could we have an update on this issue please?

Gaston Dombiak - 02/23/07 01:28 PM
Hey James - we are not working on this feature and not planning to do it anytime soon. However, if anyone is willing to sponsor this work then our priorities can be modified. Thanks. – Gato

James Clements - 02/23/07 02:57 PM
How much sponsorship are we talking? I work in the education sector, and to be honest you can probably imagine how I have to prioritise our funds anyway. Give us a figure and lets see what everyone can come up with. I cant imagine its much to change really. Sharing a group with a diferent group allows the first group to see their whole group when they shouldnt be allowed to. To be frank I can only imagine that (in a poor form of pseudo) its something like an if statement that has to be changed:

If group1 is shown in group2 roster then

group2 users get group1 in roster

**whereas at the moment**

If group1 is shown in group2 roster then

(group2 users get group1 in roster) AND (group1 users get group1 roster)


Ante Lukac - 02/23/07 03:25 PM
Oh my, good to know.
We have a top10 (or something) list, but it's good to know that somebody is making a fool of me.
Thank you Gaston for your honesty.

Gaston Dombiak - 02/23/07 03:36 PM
Hey James - Drop me, Matt or Greg an email so we can discuss about this. BTW, I wish the change would look like that pseudo code but shared groups is a very complex functionality with so many different use cases. We would need to perform an impact analysis to be able to estimate the effort of this change.

Matt --> matt at jivesoftware.com
Greg --> greg at jivesoftware.com
Me --> gaston at jivesoftware.com


Harald Steindl - 02/24/07 04:46 AM
Hello Gato!

Without wanting to sound sarcastic in a way, but shared groups are IMHO in no way difficult or complex! Instead the concept isvery clear and plain simple:
There is a kind of "sender" whose presence is exposed and a number of receivers which should get these presence. Is there any more to it?
Now we simply have a finite amount of cases, with the two most important ones are:

  • receiver gets updates because of a direct subscription to the sender
  • receiver is part of a groupX which should get updates of the groupY the sender is in, where X=Y is not only possible but some kind of "default" as this would mean sharing to members of the group your are also in.
    There seems to be more behind it, but for me this looks like JUST looking up what groups the sender is in and enumerate through one group at a time and sending out presence changes according to "what to do with each group". This means send out to members of this group yes/no (which is this very JM-802 !) and then look up the"addon" groups . For each add group we have to enumerate through its members.
    Before any optimisations receiver X could get multiple updates because of some redundancies (member of more than 1 group envolved, has direct subscription to sender anyway, etc...)
    Thats about it? Did I miss something?

But it is very likely that your implementation as well as some performance driven "shortcuts" now make it difficult to actually deliver the flexibility as it was originally intended. Take this with a bit of salt from a non-coder thinking more in concepts than in source code!
Dont consider this as a harsh critics but instead of sombody feeling with you who also suffers sometimes from legacy stuff ....
Bye
Starry