You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In out company we use employeeID as moodle username. But its not available for selection in the Binding Username Claim page.
While talking to @weilai-irl in the #2550 issue I was requested to open this feature request.
Responding to the questions he asked in our last conversation:
Yes, the employeeId field is already available for mapping.
The print bellow shows its not one of the available user ID tokens available:
We are using Microsoft Entra ID as IdP.
We are syncing users and it's very important for us.
We don't create users on sync, only update existing ones.
We check the option on update to match UPN with moodle emails not moodle username.
During the sinc we see the record match but no update is done since it can't change de username. Here I expected it to update the other fields and leave username as is but no.
For testing porpoise we are using UPN as binding_username_claim for now until we can use employeeId if possible.
In out company we use employeeID as moodle username. But its not available for selection in the Binding Username Claim page.
While talking to @weilai-irl in the #2550 issue I was requested to open this feature request.
Responding to the questions he asked in our last conversation:
Yes, the employeeId field is already available for mapping.
The print bellow shows its not one of the available user ID tokens available:
We are using Microsoft Entra ID as IdP.
We are syncing users and it's very important for us.
We don't create users on sync, only update existing ones.
We check the option on update to match UPN with moodle emails not moodle username.
During the sinc we see the record match but no update is done since it can't change de username. Here I expected it to update the other fields and leave username as is but no.
For testing porpoise we are using UPN as binding_username_claim for now until we can use employeeId if possible.
Thanks for all assistance @weilai-irl
The text was updated successfully, but these errors were encountered: