Bug 48696 - Using "normalize" in import config produces usernames that don't match "scheme"
Using "normalize" in import config produces usernames that don't match "scheme"
Status: CLOSED WORKSFORME
Product: UCS@school
Classification: Unclassified
Component: Import scripts
UCS@school 4.3
Other Windows NT
: P5 normal (vote)
: UCS@school 4.3 v7
Assigned To: Daniel Tröder
Sönke Schwardt-Krummrich
:
: 49784 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-18 10:20 CET by Michael Grandjean
Modified: 2019-07-04 11:02 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.154
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2019-02-18 10:20:06 CET
Using this:

        "normalize": {
                "firstname": false,
                "lastname": false
    },


will keep umlauts etc. in firstname, lastname and displayname. However it contradicts the scheme for username and mail, e.g.:

    "scheme": {
        "username": {
            "allow_rename": false,
            "default": "<firstname>[0:5].<lastname>[0:5]<:umlauts,lower>[COUNTER2]"
        }


This should generate something like this:

Elisabeth Schäfer -> elisa.schae (5 characters)

But in fact it generates this:

Elisabeth Schäfer -> elisa.schaef (6 characters)


I assume that internally we do have a "elisa.schäf" that is compliant to the scheme at some point and then the normalization happens afterwards, expanding "schäf" to "schaef".
Comment 2 Daniel Tröder univentionstaff 2019-02-18 11:09:20 CET
That's an encoding problem:

from univention.admin import property as uadmin_property
prop = uadmin_property("_replace")

prop._replace('<firstname>[0:5].<lastname>[0:5]<:umlauts,lower>', {'firstname': 'Elisabeth', 'lastname': 'Schäfer'})
→ 'elisa.schae'

prop._replace(u'<firstname>[0:5].<lastname>[0:5]<:umlauts,lower>', {u'firstname': u'Elisabeth', u'lastname': u'Schäfer'})
→ 'elisa.schaef'

len(u'Schäfer')
→ 7
len('Schäfer')
→ 8
Comment 3 Daniel Tröder univentionstaff 2019-02-18 11:15:47 CET
You can fix your configuration by 1st normalizing the names and then truncating them:

prop._replace(u'<firstname:umlauts,lower>[0:5].<lastname:umlauts,lower>[0:5]', {u'firstname': u'Elisabeth', u'lastname': u'Schäfer'})
→ u'elisa.schae'


"default": "<firstname:umlauts>[0:5].<lastname:umlauts>[0:5]<:lower>[COUNTER2]"
Comment 4 Michael Grandjean univentionstaff 2019-02-18 13:45:25 CET
yes, works like a charm :) Thanks!
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2019-03-12 10:55:30 CET
UCS@school 4.3 v7 has been released.

https://docs.software-univention.de/changelog-ucsschool-4.3v7-de.html

If this error occurs again, please clone this bug.
Comment 6 Sönke Schwardt-Krummrich univentionstaff 2019-07-04 11:02:53 CEST
*** Bug 49784 has been marked as a duplicate of this bug. ***