Univention Bugzilla – Bug 41862
Set RecordUID/SourceUID for migrated users and new users created via wizards
Last modified: 2016-10-04 13:24:53 CEST
+++ This bug was initially created as a clone of Bug #41162 +++ ucsschoolSourceUID and ucsschoolRecordUID must contain correct values for all school users in LDAP, or the new legacy import will not find existing users and will try to add them.
Added code to /usr/share/ucs-school-import/scripts/ucs-school-migrate-objects-to-4.1R2. Code: 71265 Advisory: 71266
The UMC wizards should also set the legacy attributes. Otherwise
The UMC wizards should also set the legacy attributes. Otherwise new users created via the Ucs@school wizard can not be maintained via CLI import script.
The legacy import part of the new import code now finds users with and without SourceUID and RecordUID in LDAP. Modification of the UMC wizards is thus not necessary anymore. The migration code from r71265 was removed r71804: code r71806: advisory
r72536: added 90_ucsschool/34_import-users_legacy_migration to test migration from pre-4.1r2 user-import to the new-legacy user-import.
The code uses the abstract object class "ucsschoolType" for building the search filter. This abstract object class is required to be set on the object while we *currently* ensure this (the migrationscript sets this and the UDM handler by accident as well). So I think this is okay to use! But why doesn't the test script fail if I remove the ucsschoolType from the list of object classes in the migration script (/usr/share/ucs-school-import/scripts/ucs-school-migrate-objects-to-4.1R2)? I think in this case the test case should fail to recognize such errors. Even better would be a test case which doesn't use that script at all but creates users via the UMC wizard as this is what we need to test in the future.
(In reply to Florian Best from comment #6) > But why doesn't the test script fail if I remove the ucsschoolType from the > list of object classes in the migration script > (/usr/share/ucs-school-import/scripts/ucs-school-migrate-objects-to-4.1R2)? At that point, the test wants to ensure, that the ucsschoolType OC is _not_ set yet. 1. run old-legacy import and checks if afterwards users have no ucsschoolType OC 2. run migration script and checks if afterwards users have the new OCs 3. run new-legacy import and checks if afterwards users have ucsschoolSourceUID and ucsschoolRecordUID > I think in this case the test case should fail to recognize such errors. > Even better would be a test case which doesn't use that script at all but > creates users via the UMC wizard as this is what we need to test in the > future. The test tries to simulate the update scenario: 1. customer uses pre-4.1r2 (old-legacy) import 2. customer updates to 4.1r2 3. customer runs 4.1r2 new-legacy-import
OK: Adding of already existing users doesn't overwrite them OK: modification of users created via wizard works # ldiff anton1_pre.ldif anton1_post.ldif dn: uid=anton1,cn=schueler,cn=users,ou=gsmitte,dc=school,dc=local +ucsschoolSourceUID: LegacyDB +ucsschoolRecordUID: Anton1 +sn: Meyer -sn: Foobar +gecos: Anton Meyer -gecos: Anton Foobar +displayName: Anton Meyer -displayName: Anton Foobar +cn: Anton Meyer -cn: Anton Foobar OK: YAML
UCS@school 4.1 R2 v5 has been released. http://docs.software-univention.de/changelog-ucsschool-4.1R2v5-de.html If this error occurs again, please clone this bug.