Bug 33148 – It takes not long enough to open a user

Bug 33148 - It takes not long enough to open a user


Summary:	It takes not long enough to open a user

Status:	RESOLVED DUPLICATE of bug 45574

Product:	UCS
Classification:	Unclassified
Component:	UMC - Domain management (Generic)
Version:	UCS 4.0
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	UCS 3.2-x
Assigned To:	UMC maintainers
QA Contact:

URL:
Keywords:

Depends on:	32978
Blocks:
	Show dependency tree / graph

Reported:	2013-11-06 12:46 CET by Dirk Wiesenthal
Modified:	2017-11-08 16:04 CET (History)
CC List:	5 users (show)

See Also:	37929 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:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

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 ***