Bug 33148

Summary:	It takes not long enough to open a user
Product:	UCS	Reporter:	Dirk Wiesenthal <wiesenthal>
Component:	UMC - Domain management (Generic)	Assignee:	UMC maintainers <umc-maintainers>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P5	CC:	best, gohmann, klaeser, troeder, wiesenthal
Version:	UCS 4.0
Target Milestone:	UCS 3.2-x
Hardware:	Other
OS:	Linux
See Also:	https://forge.univention.org/bugzilla/show_bug.cgi?id=37929 https://forge.univention.org/bugzilla/show_bug.cgi?id=45574
What kind of report is it?:	---	What type of bug is this?:	---
Who will be affected by this bug?:	---	How will those affected feel about the bug?:	---
User Pain:		Enterprise Customer affected?:
School Customer affected?:		ISV affected?:
Waiting Support:		Flags outvoted (downgraded) after PO Review:
Ticket number:		Bug group (optional):
Max CVSS v3 score:
Bug Depends on:	32978
Bug Blocks:

Description Dirk Wiesenthal

2013-11-06 12:46:27 CET

Now the form is presented to the user before static values are set. E.g. printers: Open an existing printer (CUPS installed so it takes a bit longer to finish loading) and you will notice that the value for "Samba name" is not set when the form is already accessible.

You may set a value in this widget but after a short time this value is overwritten again by the value fetched from the server.

Please standbyDuring() this phase where the static values are not yet set.

+++ This bug was initially created as a clone of Bug #32978 +++

As discussed, the time for opening a user or a computer in UMC takes to much time. I think the progress bar suggests a long wait.

Comment 1 Alexander Kläser

2013-11-06 13:24:01 CET

Probably, each value needs to be set separately according to the widget's "ready" state.

Comment 2 Florian Best

2013-11-11 16:49:50 CET

The detailpage should not be visible (or at least covered by standby / progressbar) before all values are collected from server and set into the widgets.

Comment 3 Dirk Wiesenthal

2013-11-11 17:06:07 CET

(In reply to Florian Best from comment #2)
> The detailpage should not be visible (or at least covered by standby /
> progressbar) before all values are collected from server and set into the
> widgets.

But this is intentionally not done so strictly due to Bug #32978. We were just too greedy here.

Comment 4 Stefan Gohmann

2013-11-21 08:54:37 CET

Is it only a problem for the printer module? Maybe we could decide in the UDM module whether it should be wait for all values and show an animation / progress.

Comment 5 Florian Best

2013-11-27 11:30:11 CET

(In reply to Stefan Gohmann from comment #4)
> Is it only a problem for the printer module?
→ No, it applies to every module.

Comment 6 Alexander Kläser

2015-07-09 16:17:50 CEST

From Bug 32978, comment 1:
> [...]
> * The form is shown as soon as it is rendered. Until all dynamic values
> (i.e., combo boxes) have been loaded, the submit button is disabled.

This should explain the behaviour. It was a decision taken at Bug 32978... I do not remember to which extent it was discussed, though :) .

Comment 7 Daniel Tröder

2017-10-26 14:00:22 CEST

Would it be possible to disable a widget (hinting "loading...") until it has loaded its value?

Comment 8 Florian Best

2017-11-08 16:04:08 CET


*** This bug has been marked as a duplicate of bug 45574 ***