[MGNLUI-5523] Findbar queries all public users on initialization of admin central Created: 24/Oct/19  Updated: 06/Feb/24  Resolved: 29/Nov/19

Status: Closed
Project: Magnolia UI
Component/s: find bar
Affects Version/s: None
Fix Version/s: 6.1.4, 6.2

Type: Improvement Priority: Critical
Reporter: Jan Schulte Assignee: Michael Duerig
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 5h
Time Spent: 59m
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes MGNLUI-8683 Findbar filter is slow with many users Open
Relates
relates to MGNLUI-4765 Make Find Bar configurable via YAML Closed
relates to MAGNOLIA-7691 Populating the last editor filter dro... Closed
causality
documentation
to be documented by MGNLUI-5547 DOC: Admincentral module (new page) Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Support
Sprint: UI Framework 11
Story Points: 5

 Description   

The findbar is querying the full user repository including the public users when admin central initialises.

This is leading to a massive performance degradation for clients with huge number of public users. (Up to an disfunct authoring instance)

Additionally the public users are offered as a Last Editor filter option in the search bar.

 

info.magnolia.admincentral.findbar.FindBar.initUi()
this.editorField.setItems(resolveUsers());

private List<String> resolveUsers() {

        Collection<User> allUsers = securitySupport.getUserManager().getAllUsers();

        return allUsers.stream()
                .map(User::getName)
                .collect(_toList_());
    }

Acceptance Criteria:

  • Don't query all users at initialisation time.


 Comments   
Comment by Michael Duerig [ 25/Nov/19 ]

AFAIU this is about users of admin central seeing or not seeing public users in the last-editor filter. For these I guess this should be made configurable as otherwise we might break things for existing users who rely on the current behaviour.

Comment by Roman Kovařík [ 25/Nov/19 ]

AFAIU this is about users of admin central seeing or not seeing public users in the last-editor filter.

As the public users can't edit content, how they could be last-editors?

For these I guess this should be made configurable as otherwise we might break things for existing users who rely on the current behaviour.

There can be rare use case but we can still introduce a config later.

Comment by Michael Duerig [ 25/Nov/19 ]

I was thinking of user generated content, wouldn't public users be the editor here?

Anyway, I'm fine with the proposed solution as it addresses the main concern of the support ticket. I guess there is still room for refining it later if necessary.

Comment by Michael Duerig [ 27/Nov/19 ]

rkovarik, apchelintcev and myself had a call today where we agreed on deferring the offending query to the time when the filter icon of the find bar is clicked. This brings back admin central for customers that have many public users. However, for such customers the find bar filter will still be suffering from this problem and probably not be usable.

Beyond this we still have to find consensus on how to proceed.

cc slutz

 

 

Generated at Mon Feb 12 09:27:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.