[MGNLUI-2840] (Potentially) long running actions should be configured to run asynchronously Created: 28/Apr/14  Updated: 06/Aug/15  Resolved: 23/May/14

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

Type: Improvement Priority: Critical
Reporter: Daniel Lipp Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2014-05-16 at 09.23.00.png     PNG File Screen Shot 2014-05-16 at 09.24.02.png     PNG File Screen Shot 2014-05-16 at 09.24.08.png     PNG File Screen Shot 2014-05-16 at 09.24.11.png     PNG File Screen Shot 2014-05-16 at 14.21.21.png     PNG File Screen Shot 2014-05-16 at 14.21.34.png     PNG File Screen Shot 2014-05-16 at 14.43.45.png    
Issue Links:
Cloners
is cloned by MGNLDAM-441 (Potentially) long running actions sh... Closed
Relates
relates to MGNLUI-3341 Avoid multiple asynchronous tasks and... Closed
relation
is related to MGNLUI-2783 User is blocked in his browser sessio... Closed
is related to MGNLSCH-44 Set status of the job (success/failur... Closed
is related to MGNLSCH-45 Improve and i18nize scheduler error m... Closed
is related to MGNLUI-2855 Ansynchonous action (activation) shou... Closed
is related to MGNLWORKFLOW-242 Enable workflow to run activation asy... 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   

With MGNLUI-2783 we introduced a way to run commands asynchronously. This should now be applied (on fresh installations as well as on updated ones) to:

  • recursive publication
  • deletion

as both of the actions involve versioning of content and can be time consuming



 Comments   
Comment by Mikaël Geljić [ 09/May/14 ]

Reverted on 5.3 — too many shortcomings for the user, activation statuses are no longer refreshed, deleted nodes still show up and only disappear after explicit tree view refresh. You should consider reverting on 5.2.x as well; async feature is in that's cool, but given the side-effects this has to be an explicit intentional setting, not the default.

Comment by Jan Haderka [ 11/May/14 ]

@mika w/o the feature effect is even worse. If you start long running action, it will kill the UI completely as it becomes unresponsive completely until such action finishes, which in case of deletion of whole tree or activation including subnodes on reasonably big tree might mean few to tens of minutes.

Comment by Jaroslav Simak [ 15/May/14 ]

Commits:
https://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=commit;h=d9d48910ccac27e9b13ece8b8da910516637a4da
http://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=commit;h=9b7410323e343e4e13ae3ec824b3e56ce1557541

Comment by Jaroslav Simak [ 15/May/14 ]

Forwardport to 5.3 will be part of integration.

Comment by Andreas Weder [ 15/May/14 ]

Cool stuff. It looks and feels quite professional. This will have quite a positive impact on usability for the affected cases.

I suggest the following wording.

Notification sent when the action takes longer:
<<
This action takes longer to complete.
You will be notified by the Pulse once it has finished.
>>

Message appearing in Pulse:
<<
"Publish w subpages" finished successfully.
The long-running action "Publish w subpages" you called in the Pages app on "/demo-project" has completed with success.
>>

If you can say more about the item, e.g. "on the page '/demo-project'", that would even be better.

I'm asking Antti to quickly review this.

Comment by Andreas Weder [ 16/May/14 ]

If we have two error messages (because we can't and probably shouldn't get rid of the "scheduler error"), I think that's fine with me. Let's show a more general warning that the action has failed, and which refers to the logs and the Scheduler error for more info.

Here's my suggestion after our discussion.

1.
We enrich the error reported by the scheduler. I think we should leave the technical character of the message, because that's what it is.
<<
Scheduler error
<main message, e.g. Can't execute command website-activate>
>>

But we show the main portions of the stack trace in addition to that. Can we show it in a separate field in the message details shown when I double-click the message. So there, we would have then:
<<
Scheduler error
Sender: superuser
Message text: <main message>
Exception: <stack trace or parts of it>

2.
The warning could then look like this.
<<
"Publish w subpages" failed.
The long-running action "Publish w subpages" you called in the Pages app on "/demo-project" failed with an error.
>>

And then on the message details page:
<<
"Publish w subpages" failed.
Sender: superuser
Message text: <same as above>
Comment:
This message doesn't contain additional information as to why exactly the action failed. Please consult any additional, more technical error (e.g. a "Scheduler error") reported in addition for possible reasons.
>>

Comment by Andreas Weder [ 16/May/14 ]

The new screenshots look great. I realized that I proposed to use "additional" twice plus one time "addition" within the same message!

Thus, please change the warning comment to this:
<<
Please consult any additionally reported, more technical error message (e.g. a "Scheduler error") for possible reasons as to why exactly the action has failed.
>>

Comment by Antti Hietala [ 16/May/14 ]

Language in the proposed messages is fine and can be implemented as such.

Possible improvements:

  • Use the term "complete" consistently instead of "finish".
  • Make the language friendlier. "takes longer" => "will take a while", "action you called" => "action you started"
  • When asking the user to look up a technical error message, say where to look (which log file).

This action will take a while to complete. You will be notified in Pulse once it has completed.

Info: "Publish incl. subpages" completed successfully. [MORE]
A long-running action "Publish incl. subpages" you started in the Pages app on item /demo-project2 completed successfully.

Sender: superuser
Message text: A long-running action "Publish incl. subpages" you started in the Pages app on item /demo-project2 failed with an error.
Comment: A more detailed error message may be available in <log file name>. Look for reasons why the action failed.

Comment by Daniel Lipp [ 21/May/14 ]

Introduces a circular dependency to ui-framework

Comment by Andreas Weder [ 22/May/14 ]

Ok, so for long-running actions triggered within workitems, I think we have to do some trickery. The concept for long-running actions is built for the new "tasks" tab in Pulse - for 5.2.x, this can't be applied.

Here's the current flow without asynchronous activiation:

  1. I select a page, click on a publish action. I get a notification informing me that a workflow has been started.
  2. A message is sent to Pulse reading that a new work item for this publication has been created. The message allows me to approve or reject the work item.
  3. Depending on the action I choose, I either get another Pulse message or not:
    1. If I approve, I get a notification that the work item has been approved. No other message is sent.
    2. If I reject, I get a notif, too, but I also get a message in Pulse reporting that the publication has been rejected.

Here's my suggestion for the new flow with asynchronous activation:

  1. I select a page, click on a publish action. I get a notification informing me that a workflow has been started.
  2. A message is sent to Pulse saying that a new work item for this publication has been created. The message allows me to approve or reject the work item.
  3. Depending on the action I choose:
    1. If I approve, I get a notification that the work item has been approved.
      1. If the activation runs synchronously, it blocks Pulse, until it's done. It would be nice then, if it also showed a notification that the publication has ended successfully.
      2. If the activation runs asynchronously, it shows the notification that the publication takes a while and that Pulse will notify you once it's completed.
        1. If the activation was successful, I get an info message in Pulse, informing me of success.
        2. If the activation failed, I get both the scheduler error message and a warning message in Pulse reporting that the publication has failed.
    2. If I reject, I get a notification that the work item has been rejected. I also get the message in Pulse reporting that the publication has been rejected.

Does that make sense? Can this be implemented?

I actually wouldn't mind, if:

  • (3.1.1) we only confirm that the publication ended successfully, if implementing that is straight forward. In case it's not, it would be fine if we only show the notif that the work item was approved - that would be no difference to how things work now without async actions.
  • (3.1.1) an activation here would never run synchronously, only asynchronously, iff we get the messaging right.
Comment by Andreas Weder [ 22/May/14 ]

As for the text of the mentioned Pulse messages for async actions triggered in workflow, here is my suggestion.

(3.1.2)

This action will take a while to complete. You will be notified in Pulse once it has completed.

(3.2.1)

Info: Publication has completed successfully. [MORE]
A publication on item /demo-project2 you started by approving a work item completed successfully.

(3.2.2)

Warning: Publication has failed. [MORE]
A publication on item /demo-project2 you started by approving a work item completed failed with an error.

Sender: superuser
Message text: A publication on item /demo-project2 you started by approving a work item failed with an error.
Comment: A more detailed error message may be available in <log file name>. Look for reasons why the action failed.

Comment by Jaroslav Simak [ 23/May/14 ]

Enabling of asynchronous actions and messages for workflow done in MGNLWORKFLOW-242.

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