Ramon Schouten
Recently we've encountered an issue during updates where the 'mail' field is selected for update and an external uniqueness check against a blacklist is in place for this field.
The problem that arises is thatn the commonName is updated with a '2' (the next iteration) despite no alteration to the email address itself. Consequently, it seems that the uniqueness check consistently returns a "not unique" status, primarily because the email address is already present on the blacklist for the same user.
To address this issue, I propose the implementation of a refinement in the uniqueness check process. One potential solution could involve incorporating a verification step within the uniqueness check to ensure that the updated email address is different from the current one associated with the user. By doing so, it would prevent unnecessary rejections due to the email being blacklisted for the same user.
Another approach could involve only triggering the uniqueness check for the email address if it has indeed been modified during the update process. This method would prevent unnecessary checks and potential conflicts with the blacklist if the email remains unchanged.
I believe incorporating either or both of these measures into the uniqueness check process could significantly improve the accuracy and efficiency of updates while mitigating false "not unique" outcomes triggered by unchanged email addresses on the blacklist.