Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70382

Develop the User.CanonicalIdResolver extension point

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core

      I would like more control about how users are resolved

      Put all the CanonicalIdResolvers into their own plugins

      People should not be forces to use the FullNameIdResolver (https://github.com/jenkinsci/jenkins/blob/9d961dcce5f9e6094d2b9bf38ae4a112a27df4d8/core/src/main/java/hudson/model/User.java#L1216). By moving it into its own plugin, people could choose whether to use it.

      At the very least, its priority should be configurable (https://github.com/jenkinsci/jenkins/blob/9d961dcce5f9e6094d2b9bf38ae4a112a27df4d8/core/src/main/java/hudson/model/User.java#L1228), so people could give it an extremely low priority to, in practice, disable it.

      Create more resolvers

      The fact the git plugin has what's basically an embedded email ID resolver (https://github.com/jenkinsci/git-plugin/blob/bfc53ea9c0b4cca56630f29e5c4bd3cfe4fd13e1/src/main/java/hudson/plugins/git/GitChangeSet.java#L459) makes it clear that there is a need for an EMailIdResolver.

      There is a need for more context conventions than the REALM

      The only "context" that can be given to User.get (https://github.com/jenkinsci/jenkins/blob/9d961dcce5f9e6094d2b9bf38ae4a112a27df4d8/core/src/main/java/hudson/model/User.java#L514) is a REALM, which is used by the Additional Identities plugin.

      Nobody is creating ID resolvers using other context information because nobody is sending that information. Nobody sends context information because no resolver is going to read that information.

      The context works by conventions, without a convention you can't give anything to User.get because nobody will know the structure you are using to express what you want to say. Conventions need to be created first for people to use them.

      The whole user resolution thing may work for the Subversion plugin. Since commits only have an "id" assigned to them in SVN, it can just send that. But what's the git plugin supposed to do?

      Let's say we have reached the point where there is a FullNameIdResolver and EMailIdResolver, with configurable priorities. The Jenkins administrator decides it wants to give emails more priority than full names.

      But the git plugin has a "Full Name <email>" assigned to the commit. If it sends the whole thing, both the FullNameIdResolver and EMailIdResolver will fail to resolve to a user. Should it split it and try to resolve them independently? In what order? If it tries to resolve the full name first, it would break the configuration from the Jenkins administrator.

      A solution would be to have a "Type" context, which could have "FullNamePlusEmail" value. And once such a convention is created, somebody would create a FullNamePlusEmailIdResolver.

            Unassigned Unassigned
            reddwarf94 Cristian
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: