Univention Bugzilla – Bug 30387
Some computer types do not show up in "Needed Module"-list
Last modified: 2019-07-25 18:16:25 CEST
Computer types like "computers/linux", "computers/ucc", "computers/ubuntu" (maybe others) do not show up in the drop down list of needed modules when creating/editing an extended attribute.
The problem is the syntax class univentionAdminModules that predefines all valid modules: > class univentionAdminModules(select): > # we need a fallback > choices=[('computers/managedclient', 'Computer: Managed Client'), ... ] > ... Maybe there is a feasible way to identify all existing modules dynamically.
*** Bug 31225 has been marked as a duplicate of this bug. ***
Ticket#: 2013052421000972 ] UCS Technikschulung computers/linux was found missing. syntax.py#update_choices only seems to be called for the CLI interface, but not for UDM UMC: $ git grep update_choices univention-directory-manager-modules/modules/univention/admin/syntax.py:def update_choices(): univention-directory-manager-modules/modules/univention/admincli/adduser.py:univention.admin.syntax.update_choices() univention-directory-manager-modules/modules/univention/admincli/admin.py:univention.admin.syntax.update_choices() univention-directory-manager-modules/scripts/change_srv_priority.py:univention.admin.syntax.update_choices() univention-management-console-module-ipchange/umc/python/ipchange/__init__.py:univention.admin.syntax.update_choices()
Created attachment 5295 [details] Add computers/linux, wrap long lines, use @classmethod
computers/ucc was found missing during QA for customer.
Created attachment 5581 [details] Screenshot Several module entries are empty for the extended attribute "objectFlag" which is shipped with UCS 3.2: > cn=objectFlag,cn=custom attributes,cn=univention,$ldap_base See screenshot.
*** Bug 41880 has been marked as a duplicate of this bug. ***
(In reply to Philipp Hahn from comment #4) > Created attachment 5295 [details] > Add computers/linux, wrap long lines, use @classmethod This is not the correct fix. There is already an update function that actively searches for available UDM modules and updates the corresponding UDM syntax. This works on the command line but does not in UMC. I triggered this bug when trying to modify extended attributes that are attached to 3rd party UDM modules (oxmail/* & oxresources/*). The choices list is empty after opening the existing extended attribute and results in an error message if the user tries to save the EA object because the EA is attached to oxmail/* only. If attached to standard UCS modules AND 3rd party modules, the 3rd party modules vanish from that list and if the EA object is saved, the assignment to those 3rd party modules is lost → information loss
Created attachment 8352 [details] patch?!
(In reply to Florian Best from comment #9) > Created attachment 8352 [details] > patch?! Will it create problems with one of the numerous scripts that call modules.update() manually? ucs-4.1-4$ rgrep -H 'modules.update[(][)]' | wc -l 43
(In reply to Sönke Schwardt-Krummrich from comment #10) > (In reply to Florian Best from comment #9) > > Created attachment 8352 [details] > > patch?! > > Will it create problems with one of the numerous scripts that call > modules.update() manually? No, we do this already twice in ucsschool.lib. But loading the syntax-choices at import time might not be good, because maybe some of them do a ldap connection? if so, we should add a syntax.choices_reload() also anywhere in UDM-UMC.
(In reply to Florian Best from comment #11) > No, we do this already twice in ucsschool.lib. But loading the > syntax-choices at import time might not be good, because maybe some of them > do a ldap connection? if so, we should add a syntax.choices_reload() also > anywhere in UDM-UMC. IIRC syntaxes have to be static if it's not a ldapsearch/udm syntax.
@Sönke: This needs to be fixed for OX, right? Or is there a workaround implemented in OX?
(In reply to Florian Best from comment #13) > @Sönke: This needs to be fixed for OX, right? Or is there a workaround > implemented in OX? Not that I'm aware of. I think our workaround works quite good.
still and again a customer struggled to create a designated extended attribute 'cause it's not possible to select specific modules - they're missing.
Fixed by calling update_choices() at the end of modules.update() univention-directory-manager-modules 13.0.25-22A~4.3.0.201811271640
OK: Problems as described in Comment #0 Comment #8 are fixed OK: YAML -> verified
<http://errata.software-univention.de/ucs/4.3/355.html>