Univention Bugzilla – Bug 50469
OX user listener or UDM hook trying to empty mandatory "display_name" attribute
Last modified: 2020-09-10 16:11:46 CEST
It seems the ox-user listener or the UDM hook is trying to remove/empty the "display_name" attribute of some users. This results in an error message: ----------------------------------------------------- ERROR [RMI TCP Connection(135)-10.x.x.xxx] com.openexchange.admin.rmi.impl.OXUser.change(OXUser.java:1156) com.openexchange.admin.rmi.exceptions.InvalidDataException: Field "display_name" is a mandatory field and can't be set to null. at com.openexchange.admin.rmi.dataobjects.EnforceableDataObject.testMandatoryCreateFieldsNull(EnforceableDataObject.java:284) ----------------------------------------------------- The "display_name" attribute is mandatory. This should be enforces by both a UDM hook and the listener. It happens only under specific circumstances, which we haven't yet been able to reproduce.
This is also mentioned in our forum: https://help.univention.com/t/ox-display-name/12032/7
Now happened in a customer environment.
Next customer has trouble with that. Now he has some users in the listener queue. He deactivated a user, to understand the problem, but now the user cannot be activated anymore
Next customer (now @school) with same error. See Ticket 2020021121000363
(In reply to Christina Scheinig from comment #4) > Next customer has trouble with that. Now he has some users in the listener > queue. > > He deactivated a user, to understand the problem, but now the user cannot be > activated anymore I just have experienced the same error after adding an alternative e-mail address for several users. For one user I disabled the Open-Xchange App and then was unable to enable the App again through the UMC. Finally I managed to enable the App for this user again by issuing: # udm oxmail/oxdomain modify [...] --set isOxUser=OK Environment here is: root@mail:~# univention-app info UCS: 4.4-3 errata454 Installed: letsencrypt=1.2.2-8 mailserver=12.0 oxseforucs=7.10.2-ucs3 self-service=4.0 Upgradable:
A few more details on the customer problem I brought in: The mail system can be used by all users according to current knowledge. There is no option to select the affected users when these users are contacted. All class aliases that are regularly needed are affected. It is a school environment. The queue was archived by: /usr/share/univention-ox/manage_listener_queue --archives Listener is quiet now; no more failing retries. An attempt to get an affected user into context by changing the LDAP failed: 26.02.20 12:30:25.961 LISTENER ( PROCESS ) : ox-user(xyz): lockfilename: /var/lock/deleteuid-1234 26.02.20 12:30:25.961 LISTENER ( INFO ) : ox-user(xyz): erzeugen (1) (2) (5) 26.02.20 12:30:25.961 LISTENER ( PROCESS ) : ox-user(xyz): Creating ox user "xy26.02.20 12:35:02.749 DEBUG_INIT Listener stops during creating User in ox-context.
Is this still a "random" occurance, or do we have an environment where the issue can be reproduced?
(In reply to Ingo Steuwer from comment #9) > Is this still a "random" occurance, or do we have an environment where the > issue can be reproduced? At least one customer had this issue regulary and restarts the UMC now daily via a cron job.
(In reply to Sönke Schwardt-Krummrich from comment #10) > (In reply to Ingo Steuwer from comment #9) > > Is this still a "random" occurance, or do we have an environment where the > > issue can be reproduced? > > At least one customer had this issue regulary and restarts the UMC now daily > via a cron job. Is this a comment to the correct bug? I thought this one is about the listener plugin?
Customer of Ticket 2020021121000363 still have the problem. They would be very pleased if it continued here. Actual Status in Ticket.
(In reply to Ingo Steuwer from comment #11) > Is this a comment to the correct bug? I thought this one is about the > listener plugin? No, sorry, wrong tab.
Got a new information from the customer (Ticket: 2020021121000363) It seems that manipulation of users via importer do not have the problem, only if the a user is changed via umc the listener problem occurs
The problem with the disappearing attributes can be traced back to unsafe code creating a "virtual UDM option" for the App Tab. It seem that the state of the "virtual UDM option" can get lost during a UMC session, and then UDM will "correctly" remove all OX extended attributes. We have decided to implement a correct extended UDM option, as other apps have. This will make sure that the state of the UDM option is always correct. The consequence of this is, that when the OX app option is removed/disabled, all ext. attributes of the app (ox_context, ox_display_name, ox_private_firstname, ox_more_address_attrs...) will be removed from the user. To not remove data from *upgrading* customers, a migration script will detect user that have been deactivated for OX, but have data in OX ext. attributes. Those users will be _enabled_ for the OX app, bnut their OX-login will be disabled. This way the data will be retained. A help-article will explain this and how to find those users, in case a complete deactivation is desired.
Are the deactivated users displayed in the OX Address Book? Is there an estimation of the time until provision?
(In reply to Dirk Schnick from comment #17) > Are the deactivated users displayed in the OX Address Book? Yes. To remove them from OX deactivate the OX-App checkbox. > Is there an estimation of the time until provision? End of may.
The problem is in UMC and will be fixed in the scope of Bug #51283. ---------------------------------------------------------------------- A workaround in the meantime is to use the UDM command line. It is not affected by this bug. ---------------------------------------------------------------------- Examples: * To enable a user for provisioning to OX run: # udm users/user modify --dn "uid=daniel,cn=users,$(ucr get ldap/base)" --set isOxUser=OK * To disable a user for provisioning to OX run: # udm users/user modify --dn "uid=daniel,cn=users,$(ucr get ldap/base)" --set isOxUser=Not * To change a users password run: # udm users/user modify --dn "uid=daniel,cn=users,$(ucr get ldap/base)" --set password=s3c3r3t ---------------------------------------------------------------------- For further explanation see the manual section "Command line interface of domain management (Univention Directory Manager)": https://docs.software-univention.de/manual-4.4.html#central:udm *** This bug has been marked as a duplicate of bug 51283 ***
Very duplication of bug 51283
The problems described in this bug have been fixed with bug #51456