Univention Bugzilla – Full Text Bug Listing |
Summary: | Regression: Handling of boolean UDM attributes by UMC | ||
---|---|---|---|
Product: | UCS | Reporter: | Erik Damrose <damrose> |
Component: | UMC - Domain management (Generic) | Assignee: | Florian Best <best> |
Status: | CLOSED FIXED | QA Contact: | Erik Damrose <damrose> |
Severity: | normal | ||
Priority: | P5 | CC: | best, brodersen, gohmann, grandjean, gulden, luft, scheinig, stoeckigt, troeder |
Version: | UCS 4.2 | ||
Target Milestone: | UCS 4.2-2-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: |
https://forge.univention.org/bugzilla/show_bug.cgi?id=41053 https://forge.univention.org/bugzilla/show_bug.cgi?id=41829 |
||
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?: | 4: A User would return the product |
User Pain: | 0.343 | Enterprise Customer affected?: | Yes |
School Customer affected?: | Yes | ISV affected?: | |
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | 2017072021000398, 2017080321000365, 2017090621000671, 2017100521000393, 2017102321000215 | Bug group (optional): | API change, External feedback, Regression, Usability, Workaround is available |
Max CVSS v3 score: | |||
Attachments: | proposed patch |
Description
Erik Damrose
2017-07-25 12:43:02 CEST
According to bug 41829 a not set attribute should always be interpreted as false. (In reply to Jürn Brodersen from comment #1) > Probably introduced in bug 41053 Yes! We do NOT store a "0" in LDAP for extended attributes (not for hardcoded properties!) which have the "boolean" syntax class. This causes that no state is detected and the default value is used. I have no clue how this could be fixed. IMHO, the best would be to change owncloud so that it uses a extended option and decides by the presence of the object class if the user is enabled. (In reply to Florian Best from comment #4) > I have no clue how this could be fixed. Is it possible to revert to the old behavior? It could also be implemented that an unchecked attribute is stored as false/"0" in LDAP, but that may introduce other unexpected behavior. (In reply to Erik Damrose from comment #5) > (In reply to Florian Best from comment #4) > > I have no clue how this could be fixed. > > Is it possible to revert to the old behavior? Not without loosing the new feature of Bug #41053. > It could also be implemented that an unchecked attribute is stored as > false/"0" in LDAP, but that may introduce other unexpected behavior. At least owncloud could do this, yes. We can't change this in UDM generically because then the usercrt-cool-solution breaks. > > Is it possible to revert to the old behavior? > Not without loosing the new feature of Bug #41053. But that feature is not even working for old users if a boolean syntax attribute is present. If i understand correctly, bug #41053 fixed that the default values are always set upon opening a user if they are not present in LDAP. For a single boolean attribute, the UMC then detects no changes, and when i click on 'save', nothing is changed. In my example, i cannot activate a user for owncloud via UMC. > > It could also be implemented that an unchecked attribute is stored as > > false/"0" in LDAP, but that may introduce other unexpected behavior. > At least owncloud could do this, yes. We can't change this in UDM > generically because then the usercrt-cool-solution breaks. I don't think it is ok that the new feature breaks several apps that use syntax=boolean (At least owncloud and kopano use it, a quick search also found it in u-radius) Created attachment 9055 [details]
proposed patch
Currently it's broken for all extended attributes with syntax class boolean and default value 1.
I added a patch that only sets booleans to the default value for new objects. Would that break the cool solution?
The problem is reported again by a customer, who had to activate and deactivate new Kopano users (In reply to Christina Scheinig from comment #9) > The problem is reported again by a customer, who had to activate and > deactivate new Kopano users Where can i find more information about that case? It currently seems to be only an issue with boolean syntax attributes. Kopano user activation is done with a different syntax (kopano4ucsRole, which is derived from the select syntax) (In reply to Christina Scheinig from comment #9) > The problem is reported again by a customer, who had to activate and > deactivate new Kopano users Sorry, this was a missleading information from a call. The circumstances were different here, so this was not the problem (In reply to Jürn Brodersen from comment #8) > Created attachment 9055 [details] > proposed patch The patch fixes the wrong place. If you do udm[property] the problem exists again - e.g. in UCS@school importer, OX hooks or whereever. A exception in __getitem__ would be necessary. But this might have other side effects. As possible solution I would suggest adding a new syntax class 'boolean2' which writes a "0" to LDAP instead of leaving it blank. Or my favorite would be to remove the special handling for the "boolean" syntax completely, write always a "0" to LDAP and fix the cool solution/etc. so that it can handle "0". (In reply to Florian Best from comment #12) > As possible solution I would suggest adding a new syntax class 'boolean2' > which writes a "0" to LDAP instead of leaving it blank. There are already other syntaxes that are doing this or something similar. I am hesitating to accept making boolean deprecated and having to update all occurences of the syntax as a solution. (In reply to Florian Best from comment #12) > Or my favorite would > be to remove the special handling for the "boolean" syntax completely, write > always a "0" to LDAP and fix the cool solution/etc. so that it can handle > "0". Of course, we would have to check if all current users of the syntax are still working with that change *** Bug 44866 has been marked as a duplicate of this bug. *** A partner testing/setting up UCS with owncloud/netxtcloud for several of his customers was affected by this problem and gave me feedback via phone I found a really simple solution and the real bug: The values of extended attributes with boolean syntax simply weren't ever unmapped. So self.oldinfo[prop] was never set and always contained "None" (or "1"). While we say that unset values (=None) equals to false ("0"). We treat them specially in _create(), __setitem__ and _ldap_object_classes but never really unmapped them. Now they are unmapped: If they are unset the internal value is set to a "0". The UDM-CLI now displays them also correct; udm users/user list | grep -i -e DN: -e owncloudEn Before: DN: uid=b.bluemchen,cn=schueler,cn=users,dc=school,dc=local owncloudEnabled: None DN: uid=b.bluemchen,cn=schueler,cn=users,dc=school,dc=local owncloudEnabled: 0 univention-directory-manager-modules (12.0.18-12): 7f6b091ffbff | Bug #45066: Merge branch 'fbest/45066-boolean-syntax' into 4.2-2 ba7cca533027 | Bug #45066: unmap boolean extended attributes so that default values don't overwrite the value univention-directory-manager-modules.yaml: 7f6b091ffbff | Bug #45066: Merge branch 'fbest/45066-boolean-syntax' into 4.2-2 fdd1eae5f1ef | YAML Bug #45066 OK: enable / disable boolean value with extended attribute via udm / UMC OK: yaml Verified *** Bug 45674 has been marked as a duplicate of this bug. *** |