Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
The Pulse is Magnolia's message hub. Users communicate with each other and the system using the Pulse. Messages in the Pulse provide users with relevant runtime information about the system.
Pulse user interface
The Pulse has two tabs:
- Tasks are typically related to a publishing workflow. Tasks have a status and an assignee. Users can go to the Pulse to see who owns a task and perform actions on it.
- Messages are system and app messages. Messages are displayed in the app where they currently work. They are persisted for reading later in the Pulse.
The select-all checkbox
The select-all checkbox in the Pulse is enabled by default and configurable:
Magnolia 5.6.2+: If the actual number of messages/tasks stored in the system is causing performance issues, admins can configure a threshold for the maximum number of selected items or completely disable the select-all checkbox. The configuration is possible under
optional default is true
Disables the select-all function if set to
optional default is 1000
Defines the maximum number of items to be selected.
If the total number of items is greater than the configured threshold, an error message will be displayed to the user after clicking the select-all checkbox.
Messages are displayed to the user in apps using banners. Unlike alerts and notifications, messages are persisted in the repository and can be read later in the Pulse. The system stores a separate copy of the message for each user in the
There are three types of messages:
- Info: Informs the user about a change in situation.
Warning: Warns the user that the system has detected a condition that requires their attention.
- Error: Reports severe problems that have occurred, typically system errors.
In the Messages tab:
- New messages are marked with a tick in the New column and the new message count displays in a badge .
- Open a message by double-clicking it.
- Group messages by checking the Group by type box in All Messages.
- Filter messages by going to the Info tab which shows only info messages or Problems tab which shows warnings and errors.
- Sort messages by clicking the column title.
- Delete messages using the Delete action. Delete multiple messages by checking their boxes first.
Here's are the banners the user sees in the app they are working in.
- Error: Displays at the top of the screen beneath the trinity icons.
- Warning: Displays at the bottom on the screen.
- Info: Displays at the bottom of the screen.
Tasks make collaboration better. They have a clear status and an assignee. Users can go to the Pulse to see who owns a task and perform actions on it. Magnolia uses human tasks in the publishing workflow. 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.
Unlike messages, tasks 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.
Tasks have five states:
- New: New tasks waiting to be assigned to a user..
- Assigned: 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.
Please note that a task may also be Archived . Such a task is not shown in the ALL TASKS tab of the Pulse at all (5.5.4+) or shown with the "–" (dash) marker in the Status column (pre-5.5.4). An
Archived 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
. See Default roles, groups and users for more about permissions assigned to each user.
- Eric, a content editor, publishes a page. The task is sent to the publisher group. All members of the group can see the task. Peter, a content publisher, or any other member of the group, can assign the task to themselves.
- 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.
- When Peter opens the task, a number of actions are available:
- If publication is approved and succeeds, 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.