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

          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.

          Removing unrelated components.

          Kohsuke Kawaguchi added a comment - Removing unrelated components.

          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

          Paul Blundell added a comment -

          We have this issue in that there are two Jenkins users for 1 person, 1 that has logged in using credentials and one that has committed a change.

          Would be nice to merge these two people into the one human they are.

          Paul Blundell added a comment - We have this issue in that there are two Jenkins users for 1 person, 1 that has logged in using credentials and one that has committed a change. Would be nice to merge these two people into the one human they are.

          Daniel Beck added a comment -

          The Additional Identities Plugin aims to resolve this:

          https://wiki.jenkins-ci.org/display/JENKINS/Additional+Identities+Plugin
          https://github.com/ndeloof/additional-identities-plugin

          ndeloof: Any chance you could create a release?

          Daniel Beck added a comment - The Additional Identities Plugin aims to resolve this: https://wiki.jenkins-ci.org/display/JENKINS/Additional+Identities+Plugin https://github.com/ndeloof/additional-identities-plugin ndeloof : Any chance you could create a release?

          Even with the Additional Identities Plugin, this is still an issue for me.
          I have multiple emails that I use for commits with Github, for some personal projects and then work projects.
          I viewed the People list in Jenkins, deleted the "automatic" users created by Jenkins (I presume based on commits across various projects), added the email address for each user to my Additional Identities on my primary account (tried with and without Realm), yet upon revisiting the People list, I see the previously deleted users have again returned.

          Jonathan Langevin added a comment - Even with the Additional Identities Plugin, this is still an issue for me. I have multiple emails that I use for commits with Github, for some personal projects and then work projects. I viewed the People list in Jenkins, deleted the "automatic" users created by Jenkins (I presume based on commits across various projects), added the email address for each user to my Additional Identities on my primary account (tried with and without Realm), yet upon revisiting the People list, I see the previously deleted users have again returned.

          trejkaz added a comment -

          Is there some kind of way to work around this problem? Some users on ours show up more than 3 times...

           

           

          trejkaz added a comment - Is there some kind of way to work around this problem? Some users on ours show up more than 3 times...    

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

              Created:
              Updated: