Bug 49526 - Changes of portal entries don't apply
Changes of portal entries don't apply
Product: UCS
Classification: Unclassified
Component: Portal
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-0-errata
Assigned To: Florian Best
Dirk Wiesenthal
: 46554 48793 (view as bug list)
Depends on: 49113
Blocks: 49943
  Show dependency treegraph
Reported: 2019-05-22 08:26 CEST by Ingo Steuwer
Modified: 2019-07-31 13:49 CEST (History)
6 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?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:

listener (2.04 MB, text/x-log)
2019-05-23 12:01 CEST, Ole Schwiegert

Note You need to log in before you can comment on or make changes to this bug.
Description Ingo Steuwer univentionstaff 2019-05-22 08:26:32 CEST
+++ This bug was initially created as a clone of Bug #49113 +++

Portal changes don't apply, seen with UCS 4.4 Errata 109
Comment 1 Ole Schwiegert univentionstaff 2019-05-23 12:01:17 CEST
Created attachment 10044 [details]
Comment 2 Ingo Steuwer univentionstaff 2019-05-29 15:29:39 CEST
see also https://help.univention.com/t/cant-change-umc-portal-icons/12217
Comment 3 Florian Best univentionstaff 2019-06-25 19:21:50 CEST
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?
Comment 4 Florian Best univentionstaff 2019-06-25 19:26:38 CEST
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.
Comment 5 Florian Best univentionstaff 2019-06-25 19:30:03 CEST
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.
Comment 6 Ingo Steuwer univentionstaff 2019-06-25 21:03:06 CEST
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.
Comment 7 Florian Best univentionstaff 2019-06-26 16:59:20 CEST
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')

with open('/var/cache/univention-portal/refresh_portal', 'w'):

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.
Comment 8 Florian Best univentionstaff 2019-06-26 17:02:49 CEST
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.
Comment 9 Florian Best univentionstaff 2019-06-26 18:07:41 CEST
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.
Comment 10 Florian Best univentionstaff 2019-06-26 18:08:10 CEST
*** Bug 46554 has been marked as a duplicate of this bug. ***
Comment 11 Florian Best univentionstaff 2019-06-26 18:08:20 CEST
*** Bug 48793 has been marked as a duplicate of this bug. ***
Comment 12 Florian Best univentionstaff 2019-06-26 18:20:00 CEST
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

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

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

79d61f24906c | Bug #49526: Merge branch 'fbest/49526-portal-entry-changes' into 4.4-0
Comment 13 Florian Best univentionstaff 2019-06-27 15:27:06 CEST
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).
Comment 15 Dirk Wiesenthal univentionstaff 2019-07-10 00:49:27 CEST
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".