#167 "Public" shared roster groups don't work as expected
Reporter
ninjahdavid
Owner
MattJ
Created
Updated
Stars
★★★★ (11)
Tags
Status-Accepted
Priority-Medium
Type-Defect
ninjahdavid
on
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.
MattJ
on
Confirmed, thanks. Not entirely sure what's going on yet, but I'm investigating.
Changes
owner MattJ
tags Milestone-0.7 Status-Accepted
Waqas
on
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'
Waqas
on
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).
MattJ
on
Yes, your flow is correct, as I found out this morning. The fix is another matter
though - can I hook local->local probes?
Waqas
on
Yes, they are routed as usual, with events fired, etc. Filters like privacy lists
require this.
MattJ
on
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).
Changes
title Public shared roster groups don't work as expected
MattJ
on
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.
Changes
tagsMilestone-0.7 Milestone-0.8
MattJ
on
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.
Changes
tagsMilestone-0.8
MattJ
on
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
Changes
title "Public" shared roster groups don't work as expected
holden42
on
hello is there any progress in this "bug"?
MattJ
on
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!
T.Dubrownik
on
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.
MattJ
on
akrusmobile
on
Hello! Any update here?
subsonic17
on
I would love to see updates on this, too. It should be noted that this is one of the most-starred Prosody issues.
Zephir
on
+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.... :(
cun
on
I too really need to see this bug fixed for a local chat between VPN users.
Zash
on
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.
Mario K
on
+1
Katas
on
+1
kaliko
on
+1
mrtux
on
+1
PICCORO Lenz McKAY
on
+1 hey any progresss! its one or almost the most higest rated featured and seems are delayed always
ntuseracc
on
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.
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.
ChangesWhat 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).
ChangesThere 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.
ChangesMilestone-0.7Milestone-0.8As 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.
ChangesMilestone-0.8To 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
Changeshello 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.