Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-15614

Follow info not removed when user is removed with LDAP integration or Crowd

      If a user (say user1) is in LDAP and another user (say admin) follows that user. Then user1 gets deleted, the admin user will have following 'anonymous' on their profile. When the user1 gets created again, the admin user is then considered already following user1.

      The user follow info should be wiped out when user1 is deleted.

      This is causing the LDAP build to fail: UserProfileAcceptanceTest.testFollowOnProfile (cause testFollowMacroOnPage() is run first and sets up the exact scenario described above).

            [CONFSERVER-15614] Follow info not removed when user is removed with LDAP integration or Crowd

            We've experienced the problem in 5.4.4, which is described in https://confluence.atlassian.com/x/T4VCEg, which points here.

            Intel CHD Jira Admin added a comment - We've experienced the problem in 5.4.4, which is described in https://confluence.atlassian.com/x/T4VCEg , which points here.

            I'm going to close this as I believe all the bugs this causes have already been fixed.

            We are still not actually removing the follow data from the DB when a user is deleted from LDAP, however this is consistent with the behaviour of the rest of Confluence. Actually deleting the data would make it easy for things to be lost if a user is temporarily removed from an LDAP directory.

            Matthew Erickson added a comment - I'm going to close this as I believe all the bugs this causes have already been fixed. We are still not actually removing the follow data from the DB when a user is deleted from LDAP, however this is consistent with the behaviour of the rest of Confluence. Actually deleting the data would make it easy for things to be lost if a user is temporarily removed from an LDAP directory.

            Is there any news? Confluence 5.1.4 is also affected and we some users that are facing this issue (including myself).

            Joachim Sengenberger added a comment - Is there any news? Confluence 5.1.4 is also affected and we some users that are facing this issue (including myself).

            Ryan Goodwin (Inactive) added a comment - - edited

            https://support.atlassian.com/browse/CSP-99206

            Support case where ldap user removed from ldap then shows up as undefined in the manage watchers list.

            Confluence 5.1 affected.

            Ryan Goodwin (Inactive) added a comment - - edited https://support.atlassian.com/browse/CSP-99206 Support case where ldap user removed from ldap then shows up as undefined in the manage watchers list. Confluence 5.1 affected.

            Hi Maree,
            I've opened this to track the specific issue of likes not working when a user has an invalid follower: https://jira.atlassian.com/browse/CONF-27589

            We should be able to mitigate this problem

            Steve Lancashire (Inactive) added a comment - Hi Maree, I've opened this to track the specific issue of likes not working when a user has an invalid follower: https://jira.atlassian.com/browse/CONF-27589 We should be able to mitigate this problem

            We're having this problem: https://confluence.atlassian.com/pages/viewpage.action?pageId=306349391

            Which is apparently caused by this issue. We have 15,000 users in our LDAP directories so this has the potential to stop a large number of users from liking content.

            It is not feasible for us to frequently shut down the production system and run the suggested query.

            Is it likely that this will be fixed?

            Maree Milne added a comment - We're having this problem: https://confluence.atlassian.com/pages/viewpage.action?pageId=306349391 Which is apparently caused by this issue. We have 15,000 users in our LDAP directories so this has the potential to stop a large number of users from liking content. It is not feasible for us to frequently shut down the production system and run the suggested query. Is it likely that this will be fixed?

            CharlesA added a comment -

            Note that we can't actually detect when a user is deleted from LDAP.

            I guess we could add a sanity check that whenever a person's follows are retrieved, if any don't correspond to a real user we nuke the follow at that point.

            It might make certain operations more expensive though (since we have to retrieve the user data for everyone in a follow list, whether the list is being displayed or not?)

            CharlesA added a comment - Note that we can't actually detect when a user is deleted from LDAP. I guess we could add a sanity check that whenever a person's follows are retrieved, if any don't correspond to a real user we nuke the follow at that point. It might make certain operations more expensive though (since we have to retrieve the user data for everyone in a follow list, whether the list is being displayed or not?)

            AudraA added a comment -

            Should be fixed in 3.0.1 or 3.1

            AudraA added a comment - Should be fixed in 3.0.1 or 3.1

            I've given this a priority of 4. While it leads to pretty strange behaviour for the following user, it doesn't have much functional impact. The fact that if the ldap user is recreated they are then followed again automatically wouldn't seem to be too much of a shock.

            Paul Curren added a comment - I've given this a priority of 4. While it leads to pretty strange behaviour for the following user, it doesn't have much functional impact. The fact that if the ldap user is recreated they are then followed again automatically wouldn't seem to be too much of a shock.

            Agnes Ro added a comment -

            For now I will skip the testFollowOnProfile() test if in LDAP mode. If you fix this bug, please remove the LDAP check in the test.

            Agnes Ro added a comment - For now I will skip the testFollowOnProfile() test if in LDAP mode. If you fix this bug, please remove the LDAP check in the test.

              merickson Matthew Erickson
              agnes@atlassian.com Agnes Ro
              Affected customers:
              11 This affects my team
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: