Univention Bugzilla – Bug 53876
Simple UDM API behaves different in Python2 / Python 3
Last modified: 2023-02-14 10:17:12 CET
# python Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] on linux2 >>> import univention.udm >>> udm = univention.udm.UDM().version(2) >>> p = next(udm.get('portals/portal').search()) >>> p.props.displayName [[u'de_DE', u'Univention Portal'], [u'fr_FR', u'Portail Univention'], [u'en_US', u'Univention Portal']] # python3 Python 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] on linux >>> import univention.udm >>> udm = univention.udm.UDM().version(2) >>> p = next(udm.get('portals/portal').search()) >>> p.props.displayName {'de_DE': 'Univention Portal', 'fr_FR': 'Portail Univention', 'en_US': 'Univention Portal'} UDM REST API: >>> from univention.admin.rest.client import UDM >>> from univention.config_registry import ucr >>> udm = UDM('https://%(hostname)s.%(domainname)s/univention/udm/' % ucr, 'Administrator', 'univention', user_agent='univention.cli/%(version/version)s-%(version/patchlevel)s-errata%(version/erratalevel)s' % ucr) >>> p = next(udm.get('portals/portal').search()) >>> p.open().properties['displayName'] {'de_DE': 'Univention Portal', 'fr_FR': 'Portail Univention', 'en_US': 'Univention Portal'}
Must have been fixed long ago, as there exists no "portals/portal" anymore. Tested it with "settings/portal_category" instead: root@traeger1:~# lsb_release -a No LSB modules are available. Distributor ID: Univention Description: Univention Corporate Server 4.4-9 errata1235 (Blumenthal) Release: 4.4-9 errata1235 Codename: Blumenthal root@traeger1:~# python2 Python 2.7.13 (default, Feb 6 2022, 20:16:18) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import univention.udm >>> udm = univention.udm.UDM.admin().version(2) >>> p = next(udm.get('settings/portal_category').search()) >>> p.props.displayName {'de_DE': 'Applikationen', 'en_US': 'Applications'}
(In reply to Daniel Tröder from comment #1) > Must have been fixed long ago, as there exists no "portals/portal" anymore. > Tested it with "settings/portal_category" instead: REOPEN: Wrong. settings/portal_category is obsolete. portals/portal is new in UCS 5.0 - you tested with UCS 4.4. The bug is still present in UCS 5.0.
Ah I see. Then the reason is, that when the new UDM module was written (or the old one renamed?) the encoder (.../udm/modules/settings_portal_category.py) was not also created/renamed/refactored/subclassed. I have a feeling, that there is not enough awareness in the development team, to keep the UDM modules of the original and the simple API in sync.
(In reply to Daniel Tröder from comment #3) > Ah I see. > Then the reason is, that when the new UDM module was written (or the old one > renamed?) the encoder (.../udm/modules/settings_portal_category.py) was not > also created/renamed/refactored/subclassed. That's not true. 1. the settings/portal* still exists parallel and are not removed or renamed - just deprecated and unused. portal/* modules are completely new since UCS 5.0. 2. the portal ships UDM simple API subclasses which do all the required stuff. See management/univention-portal/udm/api/portal.py 3. that new simple UDM API handler/encoders/whatever also define 'displayName': ListOfListOflTextToDictPropertyEncoder 4. the difference between Python 2 and 3 is there and it's not obvious from the code where it comes from > I have a feeling, that there is not enough awareness in the development > team, to keep the UDM modules of the original and the simple API in sync. This is a misconception. The SimpleUDM API requires additional code for every adjustment. We should drop that and simply use the UDM types interface (aka Bug #50178) which automatically does that.
(In reply to Florian Best from comment #4) > (In reply to Daniel Tröder from comment #3) > > Ah I see. > > Then the reason is, that when the new UDM module was written (or the old one > > renamed?) the encoder (.../udm/modules/settings_portal_category.py) was not > > also created/renamed/refactored/subclassed. > That's not true. > 1. the settings/portal* still exists parallel and are not removed or renamed > - just deprecated and unused. portal/* modules are completely new since UCS > 5.0. > 2. the portal ships UDM simple API subclasses which do all the required > stuff. See management/univention-portal/udm/api/portal.py Ah yes - I hadn't seen that. I had only looked for the encoder in the u-d-m-m package. > 3. that new simple UDM API handler/encoders/whatever also define > 'displayName': ListOfListOflTextToDictPropertyEncoder > 4. the difference between Python 2 and 3 is there and it's not obvious from > the code where it comes from The reason is that the "univention-portal" only installs Python 3 modules. > > I have a feeling, that there is not enough awareness in the development > > team, to keep the UDM modules of the original and the simple API in sync. > This is a misconception. The SimpleUDM API requires additional code for > every adjustment. > We should drop that and simply use the UDM types interface (aka Bug #50178) > which automatically does that. I think it is a good idea to have the conversion code directly in UDM instead of a wrapper. The Simple UDM APIs types-feature was created as a wrapper, so it did not have to modify the UDM internals. If UDM learns types internally, a lot of impractical code (encoder classes) can be removed. But my point was not that. It was about the _awareness_ in the dev team.
This is broken since UCS 5.0. But I haven't heard of any software using Python2 to work with portal objects and expecting it to work the same way as in Python3. Python2 software could work with that data format. But I doubt that it _exists_ in the first place. Although the fix is fairly trivial, it still seems to have a negative cost-value ratio. Please REOPEN when you know of such a piece of software that really relies on same behavior in the portal modules of the Simple UDM API.