• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Medium Medium
    • None
    • 2.0, 2.0.1, 2.0.2, 2.0.3
    • None

      When the User does not exist in the Delegated Directory and Crowd finds him in LDAP, the user is correctly added to Crowd's DB, however, the JIRA App Cache is not Updated.

      Possible consequences:

      1. The user can login, but will not be a member of the jira-users group
      2. Sometimes the user can't login


      Steps to Reproduce:

      1. Delete the test user from Crowd delegatedDirectory. The directory is configured to automatically add jira-users group membership on new user creation in the local group memberships directory.
      2. Restart Crowd, JIRA, and start up Confluence. We log into JIRA as an administrator account, and view the user browser. The test user is not present. Log out of the administrator account, and then log in with the test user.
      3. The test user authenticates, but does not gain group membership of jira-users. The user does belong to confluence-users, however.
      4. The test user then authenticates to Confluence. This is successful, and the user belongs to both jira-users and confluence-users.
      5. The test user logs out of JIRA, and back into JIRA, but still does not have jira-users membership. Verifying in Crowd, the user now exists and owns both jira-users and confluence-users.
      6. After restarting JIRA, the test user can now log into JIRA, and has membership of both groups.

            [CWD-1796] Crowd Integration Cache for JIRA is not updated

            Diego Berrueta added a comment - - edited

            I've tried to reproduce the issue with Crowd 2.5.2, Jira 5.1.4 and Confluence 4.3, without success. This is the setup I've used:

            1. I've configured a delegated OpenLDAP directory in Crowd.
            2. Groups 'jira-users' and 'confluence-users' have been created in the delegated directory in Crowd.
            3. The directory has been configured in Crowd to automatically add users to these two groups after a successful login.
            4. A remote Crowd directory has been configured in Jira and Confluence, making sure it has been configured for incremental synchronisation. Directory synchronisation has been tested successfully.
            5. Products have been restarted as described in the original report.
            6. To make sure there is no previous trace of the user in any of the directories/caches, a new user has been created directly in the LDAP directory, i.e., without using Crowd. It has been verified that the user does not appear in Crowd, Jira or Confluence.
            7. When the user authenticates in Jira or Confluence, the user is automatically created in the delegated directory and added to both groups (checked using Crowd), and is also created in Jira/Confluence and added to both groups (checked using the admin console of Jira/Confluence).

            We would be interested to know if this issue is still affecting users of older versions of the products.

            Diego Berrueta added a comment - - edited I've tried to reproduce the issue with Crowd 2.5.2, Jira 5.1.4 and Confluence 4.3, without success. This is the setup I've used: I've configured a delegated OpenLDAP directory in Crowd. Groups 'jira-users' and 'confluence-users' have been created in the delegated directory in Crowd. The directory has been configured in Crowd to automatically add users to these two groups after a successful login. A remote Crowd directory has been configured in Jira and Confluence, making sure it has been configured for incremental synchronisation. Directory synchronisation has been tested successfully. Products have been restarted as described in the original report. To make sure there is no previous trace of the user in any of the directories/caches, a new user has been created directly in the LDAP directory, i.e., without using Crowd. It has been verified that the user does not appear in Crowd, Jira or Confluence. When the user authenticates in Jira or Confluence, the user is automatically created in the delegated directory and added to both groups (checked using Crowd), and is also created in Jira/Confluence and added to both groups (checked using the admin console of Jira/Confluence). We would be interested to know if this issue is still affecting users of older versions of the products.

            Hi. I experienced the exact same behaviour using crowd 2.2.7 and jira 4.2 (user could log in but had no permissions at all)
            However - I am not using a delegated directory but a Crowd Internal Directory.
            Is "my" problem another issue or does this issue arise even when not using a delegated directory?

            Nils Andresen added a comment - Hi. I experienced the exact same behaviour using crowd 2.2.7 and jira 4.2 (user could log in but had no permissions at all) However - I am not using a delegated directory but a Crowd Internal Directory. Is "my" problem another issue or does this issue arise even when not using a delegated directory?

            I'm having the exact same problem as Juha Sadeharju reported for a delegated OpenLDAP directory. Updates to users and groups in Crowd will not have effect until after 1h (3600s set as timeToLiveSeconds: in crowd-ehcache.xml). Voted for this to be fixed.

            Affected version: Crowd 2.0.7

            Erik Töyrä Silfverswärd added a comment - I'm having the exact same problem as Juha Sadeharju reported for a delegated OpenLDAP directory. Updates to users and groups in Crowd will not have effect until after 1h (3600s set as timeToLiveSeconds: in crowd-ehcache.xml ). Voted for this to be fixed. Affected version: Crowd 2.0.7

            Same problem here. Would be great if someone could fix that.

            Lars Heinemann added a comment - Same problem here. Would be great if someone could fix that.

            To clarify, as the issue title is not so obvious:

            If you have a Crowd delegated Active Directory, and you're using JIRA with it, sometimes accounts signing in for the first time do not get full access rights in the first login, due some caching issue. In this case JIRA does grant login access, but nothing else, so for example Dashboard gadgets are not shown (or anything else for that matter.)

            After the user waits for awhile (an hour usually, after JIRA or Crowd has updated its cache), this user can use JIRA normally.

            Juha Sadeharju added a comment - To clarify, as the issue title is not so obvious: If you have a Crowd delegated Active Directory, and you're using JIRA with it, sometimes accounts signing in for the first time do not get full access rights in the first login, due some caching issue. In this case JIRA does grant login access, but nothing else, so for example Dashboard gadgets are not shown (or anything else for that matter.) After the user waits for awhile (an hour usually, after JIRA or Crowd has updated its cache), this user can use JIRA normally.

              Unassigned Unassigned
              rbattaglin Renan Battaglin
              Affected customers:
              10 This affects my team
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - 40h
                  40h
                  Remaining:
                  Remaining Estimate - 40h
                  40h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified