Univention Bugzilla – Bug 56249
Provide script to modify counter values for username and email schema generation
Last modified: 2024-02-26 09:34:42 CET
There are several reasons why a first or last name may change, such as marriage, divorce, adoption, or transsexual reasons for first names. By importing user, the first and last name can be changed, but the username will not be changed. It would be nice to have the username change with the first and last name change, and have the username change trigger the name counter. In general, it would be very helpful if there was a way to trigger the name counter separately. Somehow you have to be able to say Counter2 of the username MaxMustermann +1 At least it would be nice if there were.
(In reply to Mirac Erdemiroglu from comment #0) Can you elaborate that a bit more? > There are several reasons why a first or last name may change, such as > marriage, divorce, adoption, or transsexual reasons for first names. > > By importing user, the first and last name can be changed, but the username > will not be changed. Yes, agreed. The reason is that UCS itself normally does work fine with changed usernames, but the behavior of connected systems is undefined and needs to be evaluated individually: Often a changed username in UCS leads to a newly provisioned user in the connected service, so you normally want to put some thoughts into that before the system decides for you. > It would be nice to have the username change with the first and last name > change, and have the username change trigger the name counter. > > In general, it would be very helpful if there was a way to trigger the name > counter separately. Somehow you have to be able to say Counter2 of the > username MaxMustermann +1 This is the part I do not completely understand: Do you want to have the ability to supply the new username and let the system figure out the counter number it should append? Or do you want to have the possibility to add a counter to a present username?
Perhaps I can help Jan-Luca. Actually you need to delete the counter for max.mustermann if you manually change a username to. If one or more max.mustermann already exists, the counter must be deleted and created with the new number if you manually change a username (caused by marriage, adoption or whatever the reason is) It would be nice to reduce that work with a script that will in- or decrease the counter of username max.mustermann. The change of the username, what is wanted by more than one customer of us, is trivial, but the counter handling is a little bit tricky and error-prone.
(In reply to Mirac Erdemiroglu from comment #0) > There are several reasons why a first or last name may change, such as > marriage, divorce, adoption, or transsexual reasons for first names. > > By importing user, the first and last name can be changed, but the username > will not be changed. > > It would be nice to have the username change with the first and last name > change, and have the username change trigger the name counter. Allowing to change the username through the naming schema is possible using the UCRV ucsschool/import/generate/user/attributes/no-overwrite-by-schema The default is "mailPrimaryAddress uid" (space separated list). Remove "uid" to allow changing the username. As Jan-Luca wrote: Caution! Try this out in a staging environment first!
If you have a feature request, please describe the *problem and the goal*. Do not describe the method you think is the solution. I have read here two solution methods: deleting a counter and changing a counter. But I still don't understand to what *purpose*.
The problem is, that increasing or decreasing a counter is not possible. You must delete the counter and you must create it again with the new number. This may lead into broken counter and the actual solution costs much more time. The goal is to simplify the daily admin work.
(In reply to Dirk Schnick from comment #5) > The problem is, that increasing or decreasing a counter is not possible. You > must delete the counter and you must create it again with the new number. > This may lead into broken counter and the actual solution costs much more > time. > > The goal is to simplify the daily admin work. What is the goal of that work? Why do you wish to increase or decrease a counter?
(In reply to Daniel Tröder from comment #6) > What is the goal of that work? Changing the username as requested by the customer!¿! Especially name changes caused by gender change or divorce it is requested to change everythning. > Why do you wish to increase or decrease a counter? To prevent later problems!¿! I do not understand that question. You must change the counter if you manually change usernames or mail addresses or you will run into a problem with the next import that contains a new user with the same name.
I understood the following scenario: 1. A user exists with the username "daniel23". Where "daniel" is the basename and "23" is the counter because there is more than one user with that basename. 2. The user's username should be changed to have a basename "ada". There are already users with that basename. Currently, the counter for the next free number is at "14". 3. If the user gets renamed to "ada14", the next import that encounters a _new_ user that should get a username-base "ada" will create a conflict, as "ada14" is already taken. So to prevent that conflict in future imports, the counter for "ada" should be increased to "15" _before_ manually renaming "daniel23" to "ada14". Is that the scenario you are talking about?
Yes that's the scenario. You also need to decrease daniel23. ;-) Do you must increase _before_ manually renaming or _after_ I'm not sure. from my point of view this do not matter as the manual renaming do not trigger the counter. It _must_ be done _before_ the next import will take place. All in all it is possible to do this kind of change, but it is more complicated and error-prone than it has to be. A script that will de- or increase the counter (of the given basename) would help. I would not request that, if this would be a corner case; we have to do such changes quite often.
Just a quick note from the interested side-line reader: > Yes that's the scenario. You also need to decrease daniel23. ;-) Be cautious with that: Connected systems might not procedd the username change at all or by renaming the user itself (sometimes it cannot be done anyways) but instead create a new user. If the old account "daniel23" is still present, you decrease the counter and a new "daniel23" is created in the future this will lead to a conflict or even worse the new user gets access to the prior account!
(In reply to Jan-Luca Kiok from comment #10) > Just a quick note from the interested side-line reader: > > > Yes that's the scenario. You also need to decrease daniel23. ;-) > > Be cautious with that: Connected systems might not procedd the username > change at all or by renaming the user itself (sometimes it cannot be done > anyways) but instead create a new user. If the old account "daniel23" is > still present, you decrease the counter and a new "daniel23" is created in > the future this will lead to a conflict or even worse the new user gets > access to the prior account! ui well; very good point Jan-Luca. Thanks. I will not decrease the old name.