Bug 51283 - unstable UMC App-tab leads to lost LDAP data
unstable UMC App-tab leads to lost LDAP data
Status: NEW
Product: UCS
Classification: Unclassified
Component: UMC (Generic)
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
UMC maintainers
:
: 50469 (view as bug list)
Depends on:
Blocks: 51249 50469 51456
  Show dependency treegraph
 
Reported: 2020-05-13 11:05 CEST by Daniel Tröder
Modified: 2021-08-31 08:14 CEST (History)
8 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
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.257
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2020010921000744, 2020022521000471, 2020021121000363, 2020040221001367, 2020050821000293
Bug group (optional): Regression
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tröder univentionstaff 2020-05-13 11:05:27 CEST
The handling of the virtual UDM option introduced in UCS 4.4-0 is not stable in UMC.

Sometimes changing a users password leads to the deletion of all extended attributes of an app from the usesr LDAP object!
UDM then logs: "__setitem__: Ignoring property <ext.attr>"

This happens for all apps in UCS. But it only becomes visible for those that use more than one ext. attribute.

Sometimes a UDM hook will prevent the user from being saved, because the deleted attribute must not be empty, but the administrator cannot work around that, because in the UMC the property seems to be set.
The result can be especially problematic, when the deleted attribute leads to errors in connected software like listener modules. For example in the OX app tracebacks happen in the listener module.

The error does not happen when changing properties through with the UDM command line utility or through Python.
Comment 1 Daniel Tröder univentionstaff 2020-05-15 15:52:37 CEST
*** Bug 50469 has been marked as a duplicate of this bug. ***
Comment 5 Ingo Steuwer univentionstaff 2020-09-01 08:43:08 CEST
We had tests and discussions around fixing this issue. As of now all attempts to fix the race condition either were not successfull or changed the API for ISVs and/or UDM REST API.

At the point in time where we decided to fix the OX integration by moving attributes from the App Tab to "normal" extended attributes we were unaware that the problem exists also for other Apps.
Comment 7 Florian Best univentionstaff 2020-09-01 10:03:38 CEST
(In reply to Ingo Steuwer from comment #5)
> We had tests and discussions around fixing this issue. As of now all
> attempts to fix the race condition either were not successfull or changed
> the API for ISVs and/or UDM REST API.
The UDM REST API is not affected by fixing this correctly (aka. using real extended options) because the UDM REST API already exposes the fake extended options.

> At the point in time where we decided to fix the OX integration by moving
> attributes from the App Tab to "normal" extended attributes we were unaware
> that the problem exists also for other Apps.

The openproject problem was already known at this point and we mentioned it when discussing how to fix the OX problem.