Bug 39779 - Multi-edit throws traceback
Multi-edit throws traceback
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0-3-errata
Assigned To: Alexander Kläser
Alexander Kramer
:
: 39819 39823 (view as bug list)
Depends on: 38190
Blocks: 39833 39863
  Show dependency treegraph
 
Reported: 2015-11-04 17:10 CET by Alexander Kläser
Modified: 2015-11-10 16:48 CET (History)
5 users (show)

See Also:
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): Error handling, Usability
Max CVSS v3 score:


Attachments
patch (909 bytes, patch)
2015-11-07 23:25 CET, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2015-11-04 17:10:17 CET
Probably due to the changes with Bug 38190, the multi-edit feature does currently not work and shows a traceback.

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

If I open a user on demo.univention.de, it took between 2 to 4 seconds. A user should be opened in less than a second.
Comment 1 Alexander Kläser univentionstaff 2015-11-06 14:09:35 CET
The problem here is that it is not considered that it can only be determined whether the multi edit mode needs to be activated when the given ldapName for DetailPage has been resolved (this can be a Deferred):

> postMixInProperties: function() {
>     ...
>     this._multiEdit = this.ldapName instanceof Array;
>     ...
> }

There are multiple positions in the DetailPage class that rely on this._multiEdit, so it needs a careful evaluation how the logic mentioned above can be integrated here. Probably not too complicated, but this needs a bit of time. I would thus vote for an Erratum.
Comment 2 Florian Best univentionstaff 2015-11-07 14:13:10 CET
*** Bug 39819 has been marked as a duplicate of this bug. ***
Comment 3 Florian Best univentionstaff 2015-11-07 23:25:04 CET
Created attachment 7264 [details]
patch

patch: drop the pre-rendered detail page if detailpage is going to be opened in multi-edit mode.
It seems the easiest thing to do. Otherwise I have 2 other patches which 1. creates a detailpage for each mode (normal, multi-edit-mode) or 2. which calls buildRendering when we know if we are in multi edit mode.
I guess 2 would revert the performance enhancement (not sure).
So the attached patch seems to be reasonable?!
Comment 4 Alexander Kläser univentionstaff 2015-11-09 12:14:43 CET
(In reply to Florian Best from comment #3)
> Created attachment 7264 [details]
> patch
> 
> patch: drop the pre-rendered detail page if detailpage is going to be opened
> in multi-edit mode.
> It seems the easiest thing to do. Otherwise I have 2 other patches which 1.
> creates a detailpage for each mode (normal, multi-edit-mode) or 2. which
> calls buildRendering when we know if we are in multi edit mode.
> I guess 2 would revert the performance enhancement (not sure).
> So the attached patch seems to be reasonable?!

I think the solution in your patch is just fine as I assume that a multi-edit action is not called very frequently.

(BTW, we are not able to determine in our Piwik statistics between normal and multi-edit action.)
Comment 5 Alexander Kläser univentionstaff 2015-11-09 16:21:08 CET
I have addressed the following problems:
* Ignore pre-rendered detail page for multi-edit operations
* Only pre-render detail page for users/user flavor
* Make sure that a pre-rendered detail page is properly destroyed
  (e.g., when creating a new user)
* Correct problems when creating a new object in AD member mode
* Remove margin below search form


Commits for 4.0-3 erratum:

univention-management-console-module-udm (5.1.25-95):
r65332 | Bug #39779: correct various problems with pre-rendered detail page

2015-11-09-univention-management-console-module-udm.yaml:
r65333 | Bug #39779: added YAML file


Changes have been committed to 4.1-0, as well:

univention-management-console-module-udm (6.0.9-1):
r65334 | Bug #39779: correct various problems with pre-rendered detail page
Comment 6 Alexander Kläser univentionstaff 2015-11-09 17:31:02 CET
I forgot to add another patch which broke the creation of group/share objects.


2015-11-09-univention-management-console-module-udm.yaml:
r65339 | Bug #39779: adjusted package version in YAML file

univention-management-console-module-udm (5.1.25-96):
r65338 | Bug #39779: Fix error when creating a share or group UDM object

univention-management-console-module-udm (6.0.9-2):
r65337 | Bug #39779: Fix error when creating a share or group UDM object
Comment 7 Alexander Kläser univentionstaff 2015-11-09 17:38:43 CET
*** Bug 39823 has been marked as a duplicate of this bug. ***
Comment 8 Alexander Kramer univentionstaff 2015-11-09 17:44:56 CET
As discussed I tested the following cases:

UCS 4.0-3 
udm 5.1.25-95.627.201511091610 / 5.1.25-96.630.201511091727


(1) Opening a user is still fast
OK - opening Administrator took ~ 400ms

(2) MultiEdit (e.g. selected 3 users)
OK - works again

(3) Creating a new user should not create an abandoned DetailPage
OK - Creating a new destroys the detailPage before creating a new one, so no more abandoned Pages

(4) Opening a udm module that is not users/user should not preload a DetailPage
OK - no preloaded DetailPage for groups / computers / printers / shares ...

(5) Fix Traceback for new user and share if ad/member=true
OK - created a new user
OK - create 3 new shares and tried multi-editing

(6) Create object
OK - created 6 users
OK - created 3 Groups
OK - created DNS forward and reverse zone


OK - YAML file
Comment 9 Janek Walkenhorst univentionstaff 2015-11-09 18:17:43 CET
<http://errata.software-univention.de/ucs/4.0/363.html>