After creating a public shared roster group, logging on as a user not in the new public group results in a client error warning of being unsubscribed from the users in the shared roster. This differs from the behavior of normal shared roster groups where mutual subscriptions are automatically handled. *What version of the product are you using? On what operating system?* Prosody 0.6.1 on Ubuntu Server 8.04. client Gajim 12.5 for Linux. *Please provide any additional information below.* This bug arose from my attempt to create shared roster groups available to users who are not members of those groups. My intention is to use this feature in a large organisation to have all users available to all other users but divided out into groups based on functional roles of the business.

Confirmed, thanks. Not entirely sure what's going on yet, but I'm investigating.

• tags Milestone-0.7 Status-Accepted
• owner MattJ

What likely happens: Given user Alice in a public shared roster and Bob being a normal user not in a public shared roster: 1. Bob logins and retrieves his roster 2. Bob gets roster which has Alice with subscription 'both' 3. Bob sends presence probe to Alice 4. Alice's roster does not have Bob, so the server auto-replies with an 'unsubscribed' 5. Bob gets 'unsubscribed' and his roster is updated 6. Bob now has Alice with subscription 'from' and Alice has Bob as 'none'

Possible fix: If the above is correct, hooking presence probes, and always replying with presence for users on a public shared roster should fix this. Alice would still see Bob as having no subscription though, and Bob will uselessly send Alice presence (which the client may or may not display).

Yes, your flow is correct, as I found out this morning. The fix is another matter though - can I hook local->local probes?

Yes, they are routed as usual, with events fired, etc. Filters like privacy lists require this.

New plan (noting here mainly just so I remember to try it): give up on keeping full separation, and add a new flag to roster entries to signal that they shouldn't be included in the roster sent to the client. 'hidden' for example. I can't see any issues in this, but haven't tried it yet. For those following this thread, the earlier suggestions of handling probes doesn't work because later presence updates wouldn't get processed unless the contact is really on the group member's roster. If we included everyone on the server in a public group member's roster then things would get unwieldy on most services pretty quickly (though it would probably be a fine compromise for small setups).

• title Public shared roster groups don't work as expected

There are issues in the approach mentioned above. I find it hard to believe that any decently-designed server supports this feature now :) The best solution is now to await util.roster, which should be appearing in 0.8.

• tags Milestone-0.7 Milestone-0.8

As annoying as this issue is, there is no easy solution. Despite several attempts to avoid it, to do this properly requires essentially a rewrite of the roster code and possibly all code that deals with rosters. I'll never look at shared rosters the same way again - and I now have my doubts that any of the other servers are doing them properly and/or efficiently (I never tried shared roster support in another server). Since this is going to take longer than we can afford with a 0.8 release around the corner I'm removing the milestone for now, but I'm very keen to see this done and it'll probably be worked on for 0.9.

• tags Milestone-0.8

To try and clarify a particularly confusing issue based on some feedback: Shared rosters in Prosody work *fine* when using normal groups, where every member is listed in the group. This issue applies only to what we call "public" groups, where members of the group appear not only to each other, but also magically to *every* user on the server. It would also apply to groups that dynamically include all users on the server as members (rather than an explicit list of configured members). People looking to insert establish a relationship between all users on the server and e.g. the server admin should look at mod_support_contact in prosody-modules: http://code.google.com/p/prosody-modules/wiki/mod_support_contact

• title "Public" shared roster groups don't work as expected

hello is there any progress in this "bug"?

Hi, Unfortunately no, not yet. The "roster provider" plan hasn't made 0.9. I'm still as keen as I ever was on implementing it though, because roster providers would also allow other often-requested functionality like fetching all or part of the user's roster from an external data source (often a web app). I'll keep this issue posted, including announcing when I have some code ready for testing. Thanks for your patience!

Hi, MWild1, any chances of pointing me towards the code you're working on? I'm writing a shared roster based on an LDAP group and while the basics seem to mostly work, any update requires the user to log out and back in. I'm also getting weird behaviour after selecting 'show when offline', but I expect that to be pidgin-related weirdness. Cheers.

Hello! Any update here?

I would love to see updates on this, too. It should be noted that this is one of the most-starred Prosody issues.

+1 This is a must-have for corporate network chat. Issue is one of the most-starred Prosody issues but it's been 5 years old now.... :(

I too really need to see this bug fixed for a local chat between VPN users.

If you care about this please just fill in name and email and press the "star issue" button. You can leave the comment field empty.

+1

+1

+1

+1

+1 hey any progresss! its one or almost the most higest rated featured and seems are delayed always

Support to share a group (Support Team) to all users would be awesome. The ability to share a group to other group would help a lot as well.