Allow Git Committer details to be mapped from Keycloak user details

[david-martin]

Description

Allow Git Committer details to be mapped from Keycloak user details.
This will avoid the user having to set them manually in Che (Profile > Preferences > Git > Committer) before they can commit and push code to their imported repo.

Reproduction Steps

• When setup with Keycloak (& a github identity provider), login to Che.
• Authorize Che to your Github account (Profile > Preferences > SSH > VCS > Github icon)
• Import a project from Github
• Modify a file and commit/push it back (Git > Commit)
• The below error is shown

OS and version:

Diagnostics:

Would it be possible to set the Git user name & email based on the user details from Keycloak (JWT?)

[skabashnyuk]

@david-martin can you elaborate a bit more about which exactly Keycloak user details you are talking about.

[david-martin]

@skabashnyuk If I have my email address & first name set in my Keycloak account, they will get mapped to the Git user name and email config in Che.

[skabashnyuk]

@david-martin What I should do to set up email address & first name in my Keycloak account?
Do I need to setup it manually? Or create Github IDP mapper

[david-martin]

@skabashnyuk I would say it could be set manually, maybe when the user was created in that Keycloak (Or automatically if users are federated to ldap or some other user system).
i.e. they show up in below screen before the user even tries to login to Che for the first time

After they login to Che, Che is able to read user details from Keycloak (from a JWT maybe?)

[skabashnyuk]

@david-martin So this has no relation to Github. You want to map Keycalok email to gitcommiter email and KK first and last name to gitcommiter name?

[david-martin]

@skabashnyuk Yes, exactly.
Apologies for any confusion about github

[skabashnyuk]

OK. I may rephrase this issue as follows.
In LocalGitUserResolver implementation of GitUserResolver add fallback logic.
git.committer.name - to username
git.committer.email - to user mail

[david-martin]

@skabashnyuk Sure, that sounds reasonable.

[gorkem]

@vparfonov @skabashnyuk can you please see if you can take this on to the next sprint?

[skabashnyuk]

@gorkem yes sure.

[gazarenkov]

@vinokurig to make sure - it will take default value (if empty) from user/email but it can be filled manually (as it is) as well, correct?

[vinokurig]

@gazarenkov sure, user will be able to change it in the preferences

[david-martin]

Thanks @vinokurig