LSPS documentation logo
LSPS Documentation
To-Do Management

To manage To-Dos generated by the LSPS Server and to open their details use the To-Do List view.

The view contains the following To-Do details:

  • ID: unique to-do identifier
  • Model Instance ID: identifier of the model instance the to-do was generated by
  • Name: title of the to-do as displayed in the to-do list of a front-end application
  • Status: current to-do execution status (a to-do can be Alive, Accomplished, or Interrupted; Alive to-dos are highlighted)

    Note: If its parent model instance is suspended, a to-do is also in the suspended status; however, this is not a to-do status by itself.

  • Started: date and time when to-do was generated
  • Finished: date and time when to-do was submitted or its parent humanoid task finished
  • Initial Performers: set of roles or persons, who are entitled to perform the to-do as defined for the model instance at its instantiation
  • Locked By: person who has locked the to-do

You can copy the table rows to the clipboard by selecting them and pressing Ctrl + C and export and import XML to-do states.

to-dolist.png
To-Do List view
You can view further To-Do details as well as perform actions on the to-do from its detail view: To open a to-do detail view, double-click a to-do entry in the To-do List view.

You can do the following when managing to-dos:

  • Delegate to reversibly assign a to-do to other users
  • Escalate to escalate the to-do so the underlying process processes the escalation signal
  • Cancel rejection to overrule a reject from a user
  • Reset allows a front-end admin user to reset to-dos
  • Reassign to assign an alive to-do to other users, who become its initial performers

The accessibility of the actions can be restricted by user security rights.

For explanation of the concepts behind the actions, refer to To-Dos.

Important: The to-do management mechanism are provided as a base for custom to-do management features and are in no way to be considered production-ready.

To-Do Detail View

A To-Do Detail view contains detailed information about a particular to-do and allows you to perform further actions available for the to-do, such as delegation, undo delegation, and cancel rejection.

To open a to-do detail view, click a to-do entry in the To-do List view.

A to-do detail view contains two areas:

  • To-do Details: general information about the to-do
    • To-do ID: unique to-do ID
    • Model instance ID: ID of the owning model instance
    • External link: external link to the to-do
    • To-do title: title of the to-do
    • Task name: name of the task, which generated the to-do (its parent module, process definition, and task name)
    • Task status: execution status of the human task
    • Issued: date and time when the to-do was generated
    • Finished: date and time when the to-do was submitted or the respective human task finished (contains Not finished value, if the to-do is alive)
    • Interruption reason: reason why the to-do was finished (for example, timeout expired, cancel intermediate event was triggered, to-do was submitted, etc.)
    • To-do notes: notes added by front-end application users who had the to-do allocated or are processing it
  • Assignment:
    • Locked by: the person who has locked the to-do
    • Initial performers: set of roles (or persons), who are entitled to perform the to-do as defined in the parent model

      Note: This set does not include substitutes or delegates, who may have the to-do assigned by initial performers.

    • Assignees: list of the current set of roles or persons that can perform a to-do, notes on rejection (indicated by red person icon), and the current delegation level

From the view toolbar in the upper right corner of a to-do detail view, you can perform allocation related actions (for more information refer to Escalation, and Delegation.

todoDetailView.png
To-Do Detail view of a rejected To-Do

Searching for Orphaned To-Dos

An orphaned to-do is a to-do, which cannot be seen by any front-end application user, possibly as a result of such actions as escalation, delegation, etc: If a to-do was rejected by all assigned persons, or delegated to persons with insufficient security rights.

You can search for such to-dos from the To-Do List view: the view toolbar, click Filter , and check Orphaned to-dos only.

Delegating To-Dos

You can delegate a to-do from the Management perspective: Click the Delegate ( ) button in the toolbar of the To-Do Detail view and define the delegates. Delegates and the current delegation level are then displayed in the Assignees area of the respective to-do detail view.

To undo delegation, click the Undo Delegate button in the toolbar of the To-Do Detail view.

Escalating To-Dos

Escalation sends an escalation Signal to the server while keeping the to-do locked.

Important: The underlying Model is expected to catch and process it as appropriate with a Signal Catch Intermediate Event or Signal Start Event: The LSPS Server does not handled this Escalation signal by default.

To send such an escalation signal from a to-do from the Management perspective, click the Escalate ( ) button in the toolbar of the To-Do Detail view or select the to-dos in the To-Do List and click Escalate.

Note that this escalation mechanism is not related to the Escalation of the GO-BPMN Modeling Language.

Cancelling Rejection

Rejection allows a front-end user to reject a to-do: when they do so, they are excluded from its assignees. You can cancel the rejection, so if the to-do is not locked by other users, it will reappear in their to-do list.

In the Assignees box of a to-do detail view, Assignees, who have previously rejected the to-do, are indicated by a red assignee icon. The rejection reason provided by the assignee is shown next to their icon and name. You can cancel the rejection and reallocate the to-do to the assignee from the To-Do Detail view.

cancellingRejection.png

Resetting a Locked To-Do

Click the to-do reset button at the top of the to-do detail to reset a to-do. Reset erases the data in a saved to-do but the to-do remains locked. This feature is useful if the data used by the saved to-do have changed.

Reassign a To-Do

Click the to-do reassign button at the top of the to-do detail and define the roles and persons who should become new initial performers.

Exporting and Importing To-Dos

If you want to modify runtime data of a to-do that is not persisted in the database, you can do so directly in the raw XML of the model instance. Note that if you modify data that is persisted in the database, the data is changed only in the XML and remains unchanged in the database.

Note that the To-Do import and export features are subject to the security right Todo:Write_All

To export or import the model instance XML with the to-do data, do the following:

  1. Open the To-Do List view.
  2. Right-click the to-do and select Export To-Do State or Import To-Do State respectively.

Important: Importing a corrupted XML can cause the system to fail to work with the to-do.