Some time ago we’ve discussed how to generate e-mail address for resource target attribute. But almost everytime you would need to store user’s e-mail address in midPoint to push it anywhere you need. So we need to enter the value in midPoint (we have fancy “emailAddress” attribute handy) and let the resource schema handling mappings do its best.
But why should we always enter the e-mail address manually when we can do it automatically – and we can do it in midPoint!
All we need is:
- Object template for users (UserType) set as default user template in System Configuration
- One mapping to generate the address
- One mapping to validate the address to be unique in midPoint
Create a new object template and add the following mapping:
The e-mail address generator is very simple. It will generate a value for “emailAddress” user attribute by taking user’s givenName and familyName attributes and concatenate them with “@example.com” domain. See the inline comments in the Groovy expressions to see how the value is being constructed.
To avoid generating e-mail addresses for system users, this mapping has a condition, so only users where employeeType attribute is set to “EMPLOYEE” will match.
You can try to save the object template, import it to midPoint and make it default for Users: go to Configuration tab, click Basic, then click the “+” button near the “Object Policies” section:
- Select “UserType”
- Search for your “My User Template” object
- Save and then Save the page
Of course, you can do it quickly also by editing “System Configuration” object and adding:
You can try to create a new user in midPoint or change existing user givenName/familyName to see that the address is being generated. Just don’t forget to set the employeeType
Now we can attempt to make the address unique. Using Unique property value HOWTO it’s quite simple.
Add another mapping to “My User Template”:
Yes, this mapping has no target. In this case it’ correct, it’s by design. It will not store the value anywhere, just throw an exception if the address is not unique. This mapping will ensure that for each added e-mail address (boolean isNew …) midPoint will try to find an existing user with the same (case-insensitive) e-mail address. If there is another user (not the currently checked), the e-mail address is not unique.
Please note that the previous mapping is lacking the condition for employeeType. This is also by design; I simply assume that if I put e-mail address value to midPoint, I want to validate it for uniqueness even if the value was not generated. Adding the condition is just a simple copy/paste work.
You can create another user with the same givenName/familyName (and employeeType) attributes and see for yourselves. You should not be able to save the second user, because midPoint will generate the emailAddress attribute according to givenName and familyName attributes, and then the validation will fail. User will not be saved.
I agree this is quite simple. Maybe too simple. You can argue that you need multi-value e-mail address, both generated and manually entered; that you need to maintain the old e-mail address when user changes his/her familyName attribute… I say, everything is possible in midPoint, and just by changing the configuration. No coding needed. (Except Groovy expressions, of course