I’m referring to the following, sadly already closed, Ticket:
What is your original issue/pain point you want to solve?
The exact same issue like on the ticket mentioned above also comes up at our installation quite often, as people join with a different mail address early, then get one from our company and if they leave again will get another mail or use a private one for some time.
we have an account on the mail server bob@here.com, but we don’t have bob@here.com in freeipa.
zammad creates accounts when it sees an email address, so it sees the address bob@here.com and creates an account.
6 months later we create a user on freeipa for bob@here.com
zammad sees the new user the next ldap sync run and tries to create an account but it can’t as there’s already an account with the email bob@here.com
Which are one or two concrete situations where this problem hurts the most?
I guess in most companys those things happen. It is very uncomfortable to find those issues and then move the tickets around manually. You would have to:
locate both users
rename the unwanted user (that was created by zammad by sending mail to it) to Bob (old) and change the address to bob@here.com.invalid
move all the single tickets of Bob (old) to new user Bob synced by LDAP integration
let the LDAP integration run to update the new users Bob mailaddress
In bigger environments this is really annoying and time consuming.
Why is it not solvable with the Zammad standard?
The function to merge users is missing completely. We have not found a way to automate those issues in a safe way.
What is your expectation/what do you want to achieve?
I request a feature that lets us decide what zammad should do in this situation:
throw error somewhere we can see / monitor
merge the existing user with mail bob@here.com to the synced user from ldap integration
do nothing / create new user
Or at least a function to merge users, that lets us decide which information we want to keep - the one from the LDAP integration or the one that zammad set up on first contact. Maybe you can also set this up in a way that it can be used with the API.
My Zammad environment:
Zammad 6.0.0-1692176490.0e2399eb.bullseye on Debian 11 (bullseye)
I’m moving this to technical assistance. This very much sounds like a technical question, as Zammad indeed does map existing user accounts to LDAP users even later on since day one.
well, guess zammad doesn’t do it based on the mail attribute. if the content there is different, e.g. because the data changed in AD, zammad will create another account and not updating the existing one.
givenname → firstname
sn → lastname
mail → email
samaccountname → login
can’t provide a production log right now as we’ve build a workflow around zammad to prevent this in the first place, but we got errors like (not the full output, just found this in my bash find history)
UnprocessableEntity
ERROR
Email address is already used for other user
If you can’t reproduce it with the steps above I can also try to do so and provide some more logs.
Can you safely cross out that you may have several users with the same mail address in your LDAP? If that’s the case, then this would be an issue, because Zammad knows that the mail address belongs to one specific LDAP user already and can’t map a second user on it (naturally)
this problem always makes my head spin - I can say for sure that I don’t have a second user in AD using the same mail address.
here again the exact procedure to trigger the problem.
we create user A in AD with private mail. zammad syncs and creates a local user, with the mapping as above, based on data from AD:
username → user A (samaccountname)
private mail → mail
…
no problems so far.
now user A gets his official e-mail of the company, which we add in the AD - sometimes we are not “fast enough”. with these changes problems can occur as follows - but only in case B:
Case A:
user A gets his company mail
replace the private mail in the AD with company mail
zammad syncs first
after sync: user A sends a mail to zammad ticket system → zammad finds the user and maps the ticket accordingly
no problem here either. zammad can sync this and everything fits.
Case B:
user A gets his company mail
we have not yet updated the mail in AD
user A sends a mail to zammad ticket system → zammad creates a new user with company mail (username: mail; mail: sender address)
we replace the private mail in the AD with company mail
sync problems, because there are already users with the address in zammad.
I can’t really help here as it would require me to have a deeper look into your instance which is out of scope I am afraid. What I can tell for sure is:
Zammad will detect an existing user that it has not yet synced (or seen) via LDAP and then “map” it to the ldap user if the email address is the same.
If I’d have to guess I’d say that something causes Zammad to see the user from a different source first which might become troublesome. A normal email from said user wouldn’t be such a case normally.
