Uploaded image for project: 'ejabberd development'
  1. ejabberd development
  2. EJAB-730

shared rosters @all@ are not upgrade when users are connected

    Details

      Description

      To reproduce:

      • Set up an ejabberd 2.0.2 beta1 server
      • Configure a shared roster "All" with @all@ as members
      • Create and connect and account A
      • Create and connect and account B

      B is not in A's roster. A have to reconnect to receive his updated roster and then will see B.

        Issue Links

          Activity

          Hide
          cassidy Guillaume Desmottes added a comment -

          Note that in this more complex scenario one account see the newly created account:

          • Create and connect an account A
          • Create and connect an account B
          • Create and connect an account C
          • Disconnect and reconnect A
          • Disconnect and reconnect C
          • Disconnect and reconnect B
          • Create an account D

          D appears in B's roster but not in the roster of A and C.

          Show
          cassidy Guillaume Desmottes added a comment - Note that in this more complex scenario one account see the newly created account: Create and connect an account A Create and connect an account B Create and connect an account C Disconnect and reconnect A Disconnect and reconnect C Disconnect and reconnect B Create an account D D appears in B's roster but not in the roster of A and C.
          Hide
          cassidy Guillaume Desmottes added a comment -

          Bug still present in HEAD revision 1553.

          Show
          cassidy Guillaume Desmottes added a comment - Bug still present in HEAD revision 1553.
          Hide
          badlop Badlop added a comment -

          I can reproduce the simple scenario with current ejabberd trunk SVN. But when I try the complex scenario, nobody gets D.

          In general, the problem is that when an account is registered in ejabberd, the shared roster must be reevaluated. This is done in mod_register calling the hook 'user_registered'. So, when an account is registered using In-Band Registration, it appears correctly in the rosters of all the other clients.

          But the hook is not called when the account is registered using:

          • WebAdmin
          • Ad-hoc commands
          • ejabberdctl commands

          So, when the account is registered with any of those methods the other clients do not get the new user in their rosters.

          The solution is quite simple: the hook 'user_registered' must be called in all ways to register an account.

          Show
          badlop Badlop added a comment - I can reproduce the simple scenario with current ejabberd trunk SVN. But when I try the complex scenario, nobody gets D. In general, the problem is that when an account is registered in ejabberd, the shared roster must be reevaluated. This is done in mod_register calling the hook 'user_registered'. So, when an account is registered using In-Band Registration, it appears correctly in the rosters of all the other clients. But the hook is not called when the account is registered using: WebAdmin Ad-hoc commands ejabberdctl commands So, when the account is registered with any of those methods the other clients do not get the new user in their rosters. The solution is quite simple: the hook 'user_registered' must be called in all ways to register an account.
          Hide
          cassidy Guillaume Desmottes added a comment -

          During all my tests, accounts were created using In-Band Registration with Psi.

          Show
          cassidy Guillaume Desmottes added a comment - During all my tests, accounts were created using In-Band Registration with Psi.
          Hide
          badlop Badlop added a comment -

          I have just tried the simple scenario with ejabberd trunk SVN r1553 and Psi 0.12. When B account is registered using Psi, A immediately gets the new contact. When B logins, he gets A as contact and his presence; and A gets B's presence.

          So, when accounts are registered using in-band it works correctly. The only problem still present in ejabberd trunk SVN is, as I described earlier, when accounts are registered using webadmin, ejabberdctl or ad-hoc commands.

          I suspect you didn't try with ejabberd trunk SVN r1303 or newer
          https://forge.process-one.net/changelog/ejabberd?cs=1303
          nor with ejabberd 2.0.x SVN r1304 or newer.
          https://forge.process-one.net/changelog/ejabberd/?cs=1304

          Maybe you forgot to install after compilation, or you downloaded 2.0.2 tag instead of trunk/2.0.x-branch ?

          Show
          badlop Badlop added a comment - I have just tried the simple scenario with ejabberd trunk SVN r1553 and Psi 0.12. When B account is registered using Psi, A immediately gets the new contact. When B logins, he gets A as contact and his presence; and A gets B's presence. So, when accounts are registered using in-band it works correctly. The only problem still present in ejabberd trunk SVN is, as I described earlier, when accounts are registered using webadmin, ejabberdctl or ad-hoc commands. I suspect you didn't try with ejabberd trunk SVN r1303 or newer https://forge.process-one.net/changelog/ejabberd?cs=1303 nor with ejabberd 2.0.x SVN r1304 or newer. https://forge.process-one.net/changelog/ejabberd/?cs=1304 Maybe you forgot to install after compilation, or you downloaded 2.0.2 tag instead of trunk/2.0.x-branch ?
          Hide
          badlop Badlop added a comment -

          Fixed in ejabberd trunk SVN r1752, and in ejabberd 2.0.x branch SVN r1753.

          Show
          badlop Badlop added a comment - Fixed in ejabberd trunk SVN r1752, and in ejabberd 2.0.x branch SVN r1753.
          Hide
          fly-away fly-away added a comment -

          Looks like the hook also is not called when the account is created using ldap
          So with

          {auth_method, ldap}

          I got same buggy behaviour.

          Show
          fly-away fly-away added a comment - Looks like the hook also is not called when the account is created using ldap So with {auth_method, ldap} I got same buggy behaviour.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development