[MGNLUI-4333] Re-enable select all checkbox in Pulse Created: 04/Dec/17  Updated: 16/Sep/21  Resolved: 19/Jan/18

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.6
Fix Version/s: 5.6.2

Type: Task Priority: Major
Reporter: Federico Grilli Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: regression, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File all.png     File clear-all.m4v     PNG File config-example.png     PNG File impossibleToSelect.png     File select-all.m4v     PNG File selected.png    
Issue Links:
Cloners
is cloned by MGNLUI-4776 Make select all checkbox in notificat... Open
causality
caused by MGNLUI-4292 Update Pulse to Vaadin 8 Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Basel 129, Basel 130
Story Points: 8

 Description   

Selecting all rows in Pulse has been disabled when upgrading to Vaadin 8. Reason is that, due to the nature of Vaadin's AbstractBackEndDataProvider we use there, all rows would be put in memory if we were to enable the select all checkbox, which would cause severe performance issues with a large enough dataset.

Some ideas to tackle this:

What we could do is to simply add a button "Remove all messages" - this way we'll allow them to erase all the stuff, but also will avoid the possible performance problems, cause we wouldn't query anything at all.

and

Found this by chance but don't know if it's doable (and not too complicated) in Java
https://cdn.vaadin.com/vaadin-elements/latest/vaadin-grid/demo/selection.html#custom-select-all-with-data-provider


Solution eventually implemented is the following:

  • make the select all checkbox configurable and enable it by default
  • make an item threshold configurable (e.g. 1000 items by default)
  • if a user tries to select all items AND the total item size is > threshold, emit a message saying something like "operation can't be carried out due to possible memory issues. Contact admin if needed"
    In extreme cases, an admin can either increase the threshold or use a Groovy script to perform bulk operations w/o using the UI.

The advantage of all this would be that (in probably 99% of cases) users would keep on using a familiar and effective UX pattern.
Also, from Magnolia's perspective this solution seems easier to implement and maintain.



 Comments   
Comment by Federico Grilli [ 09/Jan/18 ]

"Remove all messages" only solves part of the problem. Bulk actions also involve claiming, aborting and archiving tasks. I tried to reintroduce a "Select all" button and then programmatically set all items as selected (see select-all.m4v ) but this eventually triggers the DataProvider to fetch all objects in memory anyway. Possibly one way around this is to create a custom SelectionModel for the Grid but this means extending the grid.

If we're fine with the "Remove all" option we need to decide what this means for tasks (archive?). Also this would involve exposing new ad hoc methods for Task/MessageStore and Task/MessageManager which would efficiently remove/archive all messages/tasks for a given user w/o first fetching all items in memory. See example of UX interaction clear-all.m4v

Comment by Federico Grilli [ 10/Jan/18 ]

Another option would be to have an action dropdown preceded by an "apply to: " dropdown with options like "selection", "all". See attached screenshots


Comment by Federico Grilli [ 14/Jan/18 ]

After implementing the action dropdown option above and looking closer at how data are retrieved, I think this is more of a theoretical issue than an actual one. Besides, after trying the new UX patten, imho, it feels clunky.

Regarding performance: messages and tasks are usually filtered by type so, when dataProvider.fetch(..) is invoked, only a subset of data is loaded in memory.
One would need to pile up ten of thousand of items without never acting on them and then try to select them all from the All tasks/messages tab in order to possibly cause trouble on the server. This seems very unlikely to me and so far it has never happened in production (I realized we basically have the same issue in the 5.4.x and 5.5.x series where selecting all items is enabled).
Still, I agree it's better to be on the cautious side. My proposal therefore would be

  • make the select all checkbox configurable and enable it by default
  • make an item threshold configurable (e.g. 5000 items by default)
  • if a user tries to select all items AND the total item size is > threshold, emit a message saying something like "Dude, this would possibly cause a memory issue, please select less than '%threshold' items! If you feel this sucks, please contact your admin" (wording may need adjustment).
    In extreme cases, an admin can either increase the threshold or use a Groovy script to perform bulk operations w/o using the UI.

The advantage of all this, imo, would be that (in probably 99% of cases) users would keep on using a familiar and effective UX pattern.
Also, from Magnolia's perspective this solution seems easier to implement and maintain:
the dropdown solution would entail adding more methods to interfaces and deprecate others, also I still have to sort out how to enable/disable action availability as a Vaadin dropdown can't have items disabled.

UPDATE
-----------
Quickly discussed this solution with avongunten and got UX approval.

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