Univention Bugzilla – Bug 57551
Improved, concrete error handling for missing username counter (instead of the more generic ucsschool.importer.exceptions.UniqueIdError)
Last modified: 2024-09-02 11:34:54 CEST
1. Import users, the username scheme must not contain [COUNTER2] and the record_uid is set to <firstname>.<lastname>MYTESTID 2. Change the record uid to something different (e.g. <firstname>.<lastname>MYTESTID2) and add [COUNTER2] to the username schema. 3. Start an import with the --dry-run flag ``` Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ucsschool/importer/mass_import/user_import.py", line 197, in create_and_modify_users check_username=True, File "/usr/lib/python3/dist-packages/ucsschool/importer/models/import_user.py", line 1363, in validate self._check_username_uniqueness() File "/usr/lib/python3/dist-packages/ucsschool/importer/models/import_user.py", line 1375, in _check_username_uniqueness self.name, uut.dn, uut.source_uid, uut.record_uid ucsschool.importer.exceptions.UniqueIdError: Username 'xeorgina.sirp' is already in use by 'uid=xeorgina.sirp,cn=lehrer,cn=users,ou=school4,dc=school,dc=test' (source_uid: 'MYTESTID', record_uid: 'Xeorgina.SirpMYTESTID'). ``` The correct behavior should be that the user name is set one which has an incremented counter value, but the counter was not stored in LDAP by the first import run.
> Change the record uid to something different That is not something customers should do. The property is hidden because it is a system-managed value. > the counter was not stored in LDAP by the first import run. Changing the usage of COUNTER is not a supported feature, as is changing the naming schema. IMHO, this is a feature request. Requests for solutions to similar problems exist: - Bug 51664 - seed unique-usernames (unique-emails) database with existing usernames (emails) - Bug 52418 - create a UDM module for unique-email and unique-usernames LDAP objects - Bug 56249 - Provide script to modify counter values for username and email schema generation Those feature requests intend to allow customers to handle the username/email counters. Currently, they are _private_ data, and no tooling exists to modify it. Please don't make the import code more complex by handling more customer edge cases. Instead, improve the tooling so that customers can adapt the data to their environment.
Hey Daniel, (In reply to Daniel Tröder from comment #1) > Please don't make the import code more complex by handling more customer > edge cases. Instead, improve the tooling so that customers can adapt the > data to their environment. I completely agree. :) The bugs description here may be a bit misleading: The behavior described was not meant as a valid use case to be supported, but as an observation of something that happened in an environment and lead to some headache and confusion while debugging. The intention of Johannes was that instead of just throwing the UniqueIdError our importer could be more verbose and give you specific output, maybe instructions, how to resolve this, because working on the issue this was not clear to Support nor us for some time (fyi: https://git.knut.univention.de/univention/dev-issues/dev-incidents/-/issues/71 ). I have rephrased the headline a bit to make that clearer.