[MGNLUI-3341] Avoid multiple asynchronous tasks and pulse messages when deleting multiple items at once Created: 19/Dec/14  Updated: 18/Aug/15  Resolved: 08/Apr/15

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

Type: Improvement Priority: Major
Reporter: Lars Fischer Assignee: Mikaël Geljić
Resolution: Workaround exists Votes: 1
Labels: assets_app, asynch-issue, support, usability, uzh
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2014-12-19 at 10.24.45.png    
Issue Links:
Relates
relates to MGNLUI-2840 (Potentially) long running actions sh... Closed
relation
is related to MGNLUI-3398 Redesign action capabilities: multi-i... Closed
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)
Date of First Response:

 Description   

When selecting multiple assets for deleting, an asynchronous tasks is created for every single asset instead of one task for all assets.

This causes multiple problems:

  • UI is blocked
  • a message is generated in pulse for every asset deleted


 Comments   
Comment by Christoph Meier [ 09/Jan/15 ]

A proper solution of this issue requires API changes* and further investigation by the architecture cell.
As a workaround for our customers we recommend to change the "delete" action to synchronous again. This action usually doesn't take a long time and performs well when executed synchronous.

*)
AbstractCommandAction (which "schedules" asynchronous tasks) always handles only one item. Our API currently doesn't allow to take care for a list of items; see AbstractCommandAction#executeOnItem.
When you look at AbstractMultiItemAction#execute: It iterates the items list, there calling executeOnItem(item) for each item.

Comment by Zdenek Skodik [ 03/Feb/15 ]

A proper solution of this issue requires API changes* and further investigation by the architecture cell.

If we can't make this for a minor release, how about to at least introduce some boolean property for the action definition one could configure as whether rather not to disable the success message being sent at all? This might be a quickfix we could distribute with next minor, as otherwise enterprise environments with plenty of users will be overspammed by those messages making Pulse kind of useless. Adding back to changelog to see if we can find some near-horizon solution.

Comment by Mikaël Geljić [ 11/Feb/15 ]

FYI @Zdenek, there is already a notifyUser flag on the CommandActionDefinition which does exactly what you suggested. And it was there ever since those async actions were implemented.

Comment by Christoph Meier [ 18/Feb/15 ]

Commits are on branch "MGNLUI-3341-5.3.x" (see http://goo.gl/McqSP6).

Comment by Christoph Meier [ 11/Mar/15 ]

Ensured thread safety operations and minimized code within SystemContext.

Comment by Christoph Meier [ 08/Apr/15 ]

We've decided not to fix this issue at the moment since this would have been rather a "patch". Instead we wait for a redesign for mutli-item, command-based async actions.
(See follow-up ticket MGNLUI-3398)

Meanwhile we recommend to disable notification for the concerned actions
notifyUser=false

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