#698 mod_groups not updating shared roster for a user using multiple devices
Reporter
Paolo Nesti Poggi
Owner
MattJ
Created
Updated
Stars
★ (1)
Tags
Status-New
Type-Defect
Priority-Medium
Paolo Nesti Poggi
on
If you are connected with multiple clients a prosodyctl reload won't be enough to force an update of your shared roster.
What steps will reproduce the problem?
0. restart the server
1. connect to the server with 2 different clients (I use a BOSH chat and Psi+ client)
2. edit the sharedgroups.txt and run prosodyctl reload
3. log out and log in in one of your clients
4. the roster will be updated
5. edit again sharedgroups.txt and run prosodyctl reload
6. log out and log in in one of your clients
What is the expected output? What do you see instead?
The shared roster should be updated again, instead it fails to be updated
What version of the product are you using? On what operating system?
Debian jessie Prosody 0.10 nightly build 264 (2016-06-12, 82d8c11ab0cb)
Please provide any additional information below.
Doing some poking around shows that the reason is to be found in the following:
mod_groups.lua line 86 runs inject_roster_contacts() when the event 'roster-load' is triggered
rostermanager.lua, function load_roster() loads the roster for the user (and triggers 'roster-load' ) only if the user has not an existing session, the session is read by: user = bare_sessions[jid]; that returns the bare jid, hence without the resource part that distinguishes different devices of the same user account.
Being connected with two different devices user = bare_sessions[jid]; always returns a user even if one of the devices has logged off. One should log off with both devices at the same time to force a reload of the roster, which actually works, but is impractical.
As a hack to make this thing work in this scenario (multiple devices for one account), I have commented out line 106, hence reloading the roster no matter if the account has an existing session or not. I have yet to test if this will have negative effects. For now I can say that because the roster is reloaded when the user has logged off and logged back in (that is the user has closed the session anyway), it should make no negative difference, but I have by no means the full picture of when and where this piece of code is used otherwise in the full lifetime of a session.
I would appreciate if someone with some more insight could either fix this or make a comment as to whether my fix has some kind of negative impact.
Tia, Paolo
Paolo Nesti Poggi
on
just to be clear: commented out line 106 in rostermanager.lua
Zash
on
Thanks for the report, sorry that we haven't responded to it until now. Assigning to MattJ so he can look at it.
If you are connected with multiple clients a prosodyctl reload won't be enough to force an update of your shared roster. What steps will reproduce the problem? 0. restart the server 1. connect to the server with 2 different clients (I use a BOSH chat and Psi+ client) 2. edit the sharedgroups.txt and run prosodyctl reload 3. log out and log in in one of your clients 4. the roster will be updated 5. edit again sharedgroups.txt and run prosodyctl reload 6. log out and log in in one of your clients What is the expected output? What do you see instead? The shared roster should be updated again, instead it fails to be updated What version of the product are you using? On what operating system? Debian jessie Prosody 0.10 nightly build 264 (2016-06-12, 82d8c11ab0cb) Please provide any additional information below. Doing some poking around shows that the reason is to be found in the following: mod_groups.lua line 86 runs inject_roster_contacts() when the event 'roster-load' is triggered rostermanager.lua, function load_roster() loads the roster for the user (and triggers 'roster-load' ) only if the user has not an existing session, the session is read by: user = bare_sessions[jid]; that returns the bare jid, hence without the resource part that distinguishes different devices of the same user account. Being connected with two different devices user = bare_sessions[jid]; always returns a user even if one of the devices has logged off. One should log off with both devices at the same time to force a reload of the roster, which actually works, but is impractical. As a hack to make this thing work in this scenario (multiple devices for one account), I have commented out line 106, hence reloading the roster no matter if the account has an existing session or not. I have yet to test if this will have negative effects. For now I can say that because the roster is reloaded when the user has logged off and logged back in (that is the user has closed the session anyway), it should make no negative difference, but I have by no means the full picture of when and where this piece of code is used otherwise in the full lifetime of a session. I would appreciate if someone with some more insight could either fix this or make a comment as to whether my fix has some kind of negative impact. Tia, Paolo
just to be clear: commented out line 106 in rostermanager.lua
Thanks for the report, sorry that we haven't responded to it until now. Assigning to MattJ so he can look at it.
Changes