Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
Log:
[FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

Integrated in plugins_git-plugin #119
[FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
Files :

• src/main/java/hudson/plugins/git/GitChangeSet.java

Code changed in jenkins
User: Andrew Bayer
Path:
src/test/java/hudson/plugins/git/AbstractGitTestCase.java
http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2
Log:
Fixing test failures due to JENKINS-9016 fix.

I'm still having issues with this.
In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that).
What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).

I agree with Joel's comment.

In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits.

Using the e-mail address to do the mapping seems to be a better solution.

I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver.
I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies.

https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9

In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids.
Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.

The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7:

If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead.

We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.

The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback.

Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented.
Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus.

Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing.

We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.

Problem still persists.
In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?

I have seen that the issue had some activity recently. (I came here due to JENKINS-43178.)

I agree with Andréas Berg and Joel Hough. I would really be happy if the issue could be fixed as proposed in option #1 and #3.

Btw. there is already this global plugin option that uses the full email address:
Create new accounts based on author/committer's email
As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.

With the recent security fixes (e.g. JENKINS-43178) the situation is getting even worse.

Looking up a user based on it's configured email-address should solve so many problems.

Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses.

Andrew Bayer please consider raising the priority of this task!

I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho).

My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears.

For the options that Andréas Berg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?

– Workaround

Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround".

We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code:

def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS

RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true

// Send Email with emailext

RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal

(this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation)

I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.

Jose Camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin).

What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits.

Still a matching based on the email adress would be so much more convenient.

EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.

We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.

We also struggle on this issue, any progress ?

Code changed in jenkins
User: George
Path:
src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java
src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy
src/main/webapp/help/globalConfig/allowUnregistered.html
http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8
Log:
JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)

Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox?

For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'.

This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.

Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users?

The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account.  Why can those not be matched up?

I agree with everyone else here. We just started converting from old jobs to Pipeline jobs and are now faced with issues surrounding user mapping. I'll admit, it's probably more due to the fact we updated our 3 years old Jenkins instance.

The unique identifier IS the email address. This is what should be used for mapping with registered Jenkins user. As many others, our company use shorthand names for login in AD, yet in Git all our users configure their full name. This is a common practice in the corporate world at it makes it easy to login everywhere with a shorter name. In my case it's even a lifesaver.
Imagine if I had to type "Jeremie.Faucher-Goulet" every time I log in somewhere, instead of the much easier "jfaucher" I use against AD in all login forms everywhere.

Even Fisheye+Crucible from Atlassian is able to do proper mapping between AD and git committer based on emails.

I feel this is really needed, as I don't like disabling the security check against registered Jenkins users.... We did have in the past a few cases of embarrassing leaked emails from Jenkins because we compile 3rd party applications and committers outside the organization appeared as the culprits in some failed builds. Until Jenkins does proper user mapping based on email we are vulnerable to this issue because we are forced to disable the security feature in the meantime.

I was just hit by the same issue. E-mail should be compared against e-mail field, not processed and compared against some different field. Or at least please give an option to choose the behaviour.