This documentation is still in progress. We are working hard to update all our screenshots to the new Magnolia 6 style. Please bear with us.

Page tree
Skip to end of metadata
Go to start of metadata

The Tasks app is where tasks related to publishing workflows are collected. Users can go to the app to see who owns a task and perform actions on it. To open the app, click Tasks in the top-right corner:

The task counter shows the total number of all workflow tasks less the archived ones.

The green dot appears next to the counter if there are new tasks registered in the workflow.

^^ MGNLUI-4898 - Getting issue details... STATUS but for 6.1 will change to whatever  MGNLUI-4936 - Getting issue details... STATUS comes up with.

Tasks

Tasks make collaboration better. Magnolia uses human tasks in the publishing workflow. For example, when an editor publishes a page, the system creates an approval task and sends it to the publishers group.  Under the hood we use the jBPM workflow engine's user task feature. See also Custom tasks and User tasks in Magnolia workflow documentation. Tasks are a single persisted entry shared by different users and groups. Given appropriate access rights, one or more users can see the same task and its state.

are not persisted for each user. Tasks are a single persisted entry shared by different users and groups, so all can see the same task and its state.

A task can have one of six states:

  • Created: New tasks waiting to be assigned to a user.
  • inProgress: Tasks assigned to a user.
  • Resolved: Tasks that have been resolved successfully.
  • Failed: Tasks that were approved but did not run successfully.
  • Scheduled: Tasks scheduled for later publication.
  • Archived:  Such a task is not shown in the All tasks tab. However, an a rchived task is still stored in the repository and may be re-opened if necessary.

Example: tasks in the publishing workflow

This is how workflow tasks work in the Travel demo. See Default roles, groups and users for more about permissions assigned to each user.

  1. Eric, a content editor, publishes a page. The task is sent to the publisher group.
  2. All members of the group can see the new task.
  3. Peter, a content publisher, or any other member of the publisher group, assigns the task to himself. The task moves from the New to the Assigned tab. Other publishers, for example superuser, can see the task, who it is assigned to, and re-assign it to themselves.
  4. When Peter opens the task by clicking the Preview task action in the Action bar, he can:
    • Approve & publish: Publishes the page.
    • Reject: Opens a comment dialog and then sends a message to the editor (Eric).
    • Preview page: Opens the page in preview mode in the Pages app.
    • Show changes: Opens the page in diff view in the Pages app.
  5. Peter approves the request and the task moves to the Resolved tab:

     If it is approved, but fails for technical reasons for example, it moves to the Failed tab, where it can be retried.