Univention Bugzilla – Bug 49526
Changes of portal entries don't apply
Last modified: 2020-05-27 08:58:54 CEST
+++ This bug was initially created as a clone of Bug #49113 +++ Portal changes don't apply, seen with UCS 4.4 Errata 109
Created attachment 10044 [details] listener
see also https://help.univention.com/t/cant-change-umc-portal-icons/12217
I could reproduce the following thing: I initially had a jpeg photo set as background(logo) of the "domain" portal. Then I changed via UMC the image to a PNG photo and updated the portal-description/title. The listener created the /var/cache/univention-portal/refresh_portal file correctly. When I now access the Portal, the *old* logo is still shown and the *new* title is displayed. When I press F5 the correct logo/background is shown. The reason is an architectural problem in the univention-portal-server: It writes the new image to various locations in /var/www/univention/portal/icons/backgrounds/, e.g: domain.csv, domain.jpeg, domain.png. When one accesses the portal the first step by the browser is fetching index.html, which contains a link to /univention/portal/portal.css. This file contains the old image path: body.umc.portal { background: url("/univention/portal/icons/backgrounds/domain.jpeg") no-repeat top center / cover; } Then the portal.json is fetched. That causes in the univention-portal-server that the new logo/background image is fetched from LDAP and written to disk as well that a new portal.css is generated. The new portal.json then cotains the correct path and values. Better behavior would be, if the listener would write the new files. Why is the univention-portal-server doing this job?
As the code is already in the univention-portal-server and not in the listener, I suggest calling "service univention-portal-server reload" in the postrun of the listener. Then implement the "reload" action by using kill -SIGUSR1 and install a signal handler in the univention-portal-server which does all the things directly.
The alternative to this solution is to generate the /univention/portal/portal.css via the univention-portal-server. The problem keeps existing for other cases then. But if the univention-portal-server doens't run at that time, the bug would also be present. So I might do both? Another alternative would be to check in the javascript, if the image changed and trigger a reload of the background then. But this has the disadvantage, that the portal would start with the old image and apparently switches to the new image.
Please note that the main problem is not that a page reload is needed to apply portal changes, and the problem is not limited to images. The reported problems are often while creating new portal items which don't appear, even not with a page reload or a new browser profile.
I could also trigger that categories or entries disappear by renaming or moving them. I fixed that in the branch fbest/49526-portal-entry-changes as well. Also fixed the escaping of DN chars and ldap filters, which could also cause strange effects. And also updated "portal-unjoined.json" to include the recently added fields, just in case that the javascript expects they exists. Also replace "/" in portal and entry names with "-" to not create images in sub-directories. In the listener I replaces the line: open('/var/cache/univention-portal/refresh_portal', 'w') into: with open('/var/cache/univention-portal/refresh_portal', 'w'): pass Because otherwise I don't think it's 100% ensured that the file is created. That at least adds an explicit close. I tried to leave out some language keys (or remove them) so that e.g. only fr_FR is set but then just no title/description is set using a german browser locale. With all these changes I am unable to reproduce any inconsistency.
Timo said it didn't happen anymore in our environment. The forum speaks about these concrete problems: """ I can’t change some of the default icons on the UMC portal. I tried many different types of icons adding re-moving and again … But all I see are the standard UCS icons. It seems that the first icons are there but any new does not work? """ And also: """ If I create a new entry with a dot “.” the image will not be visible. """ Which is caused by Bug #48793.
With ucr set directory/manager/web/modules/settings/portal_entry/properties/name/syntax=string I create a portal entry named: o!nl§y.a$d% mi(n)ca}n-s_e`e#m*e=f/o&b\a and referenced it in any portal. Then the portal crashes (displays nothing just the category headers) with: DOMException: Failed to execute 'insertRule' on 'CSSStyleSheet': Failed to parse the rule '.umcPortal-o!n"l§y_a$d% &m-i(n)ca}n-s_e`e#m*e {background-image: url("/univention/portal/icons/entries/o!n"l§y.a$d% &m-i(n)ca}n-s_e`e#m*e.jpeg") !important;}'. Fixed this by adding urlencoding to the paths and by renaming the CSS selector to something more valid. Renaming of entries containing \ or = currently does not work due to invalid dn syntax errors, I think we don't need to fix this, as the syntax doesn't allow these characters.
*** Bug 46554 has been marked as a duplicate of this bug. ***
*** Bug 48793 has been marked as a duplicate of this bug. ***
All changes are described above. One note: Now portal entries named "foo.bar", "foo__bar", "foo bar" will result in having the same logo. If you want to REOPEN this bug then please make a suggestion with what characters I should replace the entities. univention-directory-manager-modules (14.0.12-41) fabededf8b65 | Bug #49526: fix updating of portal references on name changes and escape dn characters univention-directory-manager-modules.yaml 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0 univention-directory-manager-modules (14.0.12-42) 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0 univention-portal (3.0.1-26) 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0 univention-management-console (11.0.4-23) 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0 univention-portal.yaml 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0 univention-portal (3.0.1-25) e0f45af8d555 | Bug #49526: include latest schema 90e49532d9cb | Bug #49526: implement reloading of univention-portal-server univention-management-console.yaml 79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0
Another way to reproduce this is by changing the wrong portal. Changing the portal "local" doesn't cause any changes. You have to change the "domain" portal (at least on a DC Master).
OK, lots of small improvements. Not sure if they fix the original problem (my guess is the reconnect in Bug#49746), but they "increase the robustness". VERIFIED
<http://errata.software-univention.de/ucs/4.4/181.html> <http://errata.software-univention.de/ucs/4.4/182.html>