See http://jenkins.361315.n4.nabble.com/Users-unicity-td2542625.html for related discussion.

      Jenkins is missing a way to ensure users unicity since they are created from various sources: authentication method (LDAP in my case), code commits (Subversion, Mercurial, Git, ...).
      Depending on the way the user is retrieved by Jenkins (from a commit on a given SCM or its authentication), multiple identities are created for the same real user.
      As a consequence, some features are not fully or badly working (login, notifications, user's builds, continuous integration game, ...) and configuration of users is a pain as it must be done multiple times for each real user.

      Wanted features are:

      • a merging feature. Allow to merge multiple Jenkins users into a single account.
      • a user pattern per SCM. Allow to choose how to extract a username from a commit for each SCM and how to optionally match existing one instead of creating a new user.
      • an id pattern per notification type. Allow to define how to generate the default id used for notification from the user data (from his jenkins id, his name, his scm id, ...): for instance his mail or his jabber id, ...

          [JENKINS-10258] Allow users unicity

          Julien Carsique created issue -

          redsolo added a comment -

          re-assigning to Kohsuke as Im the maintainer of the ci-game and this is not really an issue that comes from the game. The game only gets the names from the SCM plugins, the merging has to be done in core.

          redsolo added a comment - re-assigning to Kohsuke as Im the maintainer of the ci-game and this is not really an issue that comes from the game. The game only gets the names from the SCM plugins, the merging has to be done in core.
          redsolo made changes -
          Assignee Original: redsolo [ redsolo ] New: Kohsuke Kawaguchi [ kohsuke ]

          Removing unrelated components.

          Kohsuke Kawaguchi added a comment - Removing unrelated components.
          Kohsuke Kawaguchi made changes -
          Component/s Original: other [ 15490 ]
          Component/s Original: mail [ 15493 ]
          Component/s Original: ci-game [ 15510 ]

          I agree with the problem, but this is a somewhat involving work. I think there are two parts to this.

          One is that when external systems tell us user IDs, we need to define an extension point that converts that ID into the user ID in Jenkins. We need a few decent generic implementations of this extension point as well. We should be able to define just one such extension point that takes enough context so that it can work with Git, Mercurial, Subversion, etc.

          The other is the equivalent of MailAddressResolver for IRC, Jabber, etc., that can infer the default value from the User object so that everyone doesn't have to fill in those values separately. I think this is a nice-to-have, not a must-have, and it needs to be addressed by individual plugins separately.

          I'm not sure about the merge feature. Perhaps this is a separate extension point to allow user ID to be translated to another before we grab the User object?

          Kohsuke Kawaguchi added a comment - I agree with the problem, but this is a somewhat involving work. I think there are two parts to this. One is that when external systems tell us user IDs, we need to define an extension point that converts that ID into the user ID in Jenkins. We need a few decent generic implementations of this extension point as well. We should be able to define just one such extension point that takes enough context so that it can work with Git, Mercurial, Subversion, etc. The other is the equivalent of MailAddressResolver for IRC, Jabber, etc., that can infer the default value from the User object so that everyone doesn't have to fill in those values separately. I think this is a nice-to-have, not a must-have, and it needs to be addressed by individual plugins separately. I'm not sure about the merge feature. Perhaps this is a separate extension point to allow user ID to be translated to another before we grab the User object?

          You got it.
          The first point about user IDs is the most important one.
          The MailAddressResolver is an improvement.
          The merge feature is only required for existing data. Since the two preceding problems would have been resolved, the merge becomes useless. However, user ID translation seems interesting in case of multiple external accounts (SCM for instance) per user.

          Julien Carsique added a comment - You got it. The first point about user IDs is the most important one. The MailAddressResolver is an improvement. The merge feature is only required for existing data. Since the two preceding problems would have been resolved, the merge becomes useless. However, user ID translation seems interesting in case of multiple external accounts (SCM for instance) per user.

          Justin Wesley added a comment -

          What is the status of this request? It looks to be inactive for 18 months or so. We have the same issue where a user id in SVN is different that our LDAP user.

          Justin Wesley added a comment - What is the status of this request? It looks to be inactive for 18 months or so. We have the same issue where a user id in SVN is different that our LDAP user.

          partially addressed by hudson.model.User.CanonicalIdResolver

          Nicolas De Loof added a comment - partially addressed by hudson.model.User.CanonicalIdResolver
          Nicolas De Loof made changes -
          Component/s Original: git [ 15543 ]

            Unassigned Unassigned
            jcarsique Julien Carsique
            Votes:
            35 Vote for this issue
            Watchers:
            33 Start watching this issue

              Created:
              Updated: