Uploaded image for project: 'Migration Platform'
  1. Migration Platform
  2. MIG-1326

Different user_name with the same lower_user_name causes JCMA to show inconsistent User Directory information

XMLWordPrintable

    • 2
    • Severity 3 - Minor
    • 1

      Issue Summary

      This is reproducible on Data Center: (yes)

      Steps to Reproduce

      1. Create a user in the Jira Internal Directory with username abcde
      2. Create a user in the External User Directory (LDAP/AD) with username Abcde
      3. Create a plan in JCMA and assess the users
      4. JCMA will list duplicated usernames
      5. JCMA will give the "Update users based on a CSV file"

      In the example above, the user orelhaseca comes from the Internal Directory and the user orelhaseca@mig.crypto.net.br comes from the LDAP.
      JCMA shows them correctly.

      The second duplicated user (ramisobuchao@mig.crypto.net.br) comes from the Internal Directory.
      And the user RamisoBuchao@mig.crypto.net.br (same username, different casing) comes from the LDAP.
      JCMA shows as both coming from LDAP (which is the first directory in the User Directory login order):

      Expected Results

      • Only the user from the directory with higher priority (canonical user) will be displayed and migrated (similar to the UI on Users admin page)

      Actual Results

      • JCMA will list only the information from the User Directory with priority in the login order
      • This will cause confusion in the UI - showing both user names as coming from the same User Directory (which is not the case)
      • Usernames are displayed as coming from the first User Directory in the login order in Jira.

      This should not block the migration as the admin will be able to fix the dup users when using the CSV feature in JCMA. It can cause confusion as to where the admin should go in order to fix the user (Internal or External User Directory) if they decide to fix it in the User Directory source.

      Workaround

      Currently, there is no known workaround for this behavior. A workaround will be added here when available.

              Unassigned Unassigned
              omedeiros@atlassian.com Osimar M. (Osi) | Atlassian Support
              Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: