Skip to main content

Workflow

In LOBSTA, Workflow lets you define the Status Transitions and Field Permissions. This sections configures user´s ability to modify issue status and fields depending on their role and tracker of the issue.

Status Transitions​

Status Transitions defines the logic of changing issue status on trackers by the roles assigned. To start, select the desired role and tracker to be edited.

Interpretation​

Status Transitions

  • Only display statuses that are used by this tracker is ticked on by default.
  • The vertical axis is Current Status, meaning the status that is currently applied to an issue.
  • The horizontal axis is New status allowed, meaning the possible status a user can change to.
  • The intersection is a cell. Each cell answers the question: If I am in Y status, am I allowed to move to X status? If the cell is ticked, then YES, if empty then NO.
  • The intersection of the same Current Status and New status allowed creates a "step ladder".
  • Assuming issue statuses are open at the top/left and closed at the bottom/right:
    • Cells under the "step ladder" should be empty. These new statuses allowed should go before the current status and don´t have a logical progression.
    • Cells above the "step ladder" should be ticked. These new statuses allowed should go after the current status, and have a logical progression.
    • For example, in row In progress, it makes no sense for a progressed issue to be categorized as New after it is updated. Thus the cell of In progress with New should be not ticked.
tip

The order of Issue statuses does not matter for LOBSTA, but it matters for the user to understand the workflow.

You can specify additional transitions allowed when the user is the author or assignee from their corresponding dropdowns. The same logic applies as the previous example. Clicking on summary will display the tally of ticked cells for the corresponding role and trackers.

To make workflow simpler, you can copy the Status transitions from the desired role and tracker to the target tracker and role. Confirm by pressing copy.

Copy

Field Permissions​

Field permissions defines special permissions on fields of trackers by the roles assigned. These permissions are independent from the ones defined in roles and permissions

Similarly to Status transition, once you have chosen a role and tracker, the intersection of these is a cell that represents the property of the field. There are 3 possible options for each field:

  • read-only: Hides the selected field and cannot be edited by the role.
  • required: Makes the filling of the field mandatory by the role
  • Left blank for default behavior, which makes the field appear and be editable.

Interpretation​

Permissions

  • Vertical axis is the Standard Field and Custom field (if applicable), representing the available fields for the tracker.
  • Horizontal axis is the Issue Status, representing the status the user is in when they modify the field.
  • The intersection, a cell, is the field property for that issue status.
  • By clicking on a cell, you can define it as read-only or required, or leave blank for default behavior.
  • Project, Tracker, Subject, Priority, Private can only be set to read-only or left blank.
  • For example, when an issue is New all fields should be editable as to fill relevant information. When the issue becomes resolved, you only need to edit some fields, so you set the fields you do not want to be edited to read-only.
note

In case you want a standardized workflow for all trackers and roles, selecting all in both fields will accomplish this.

Last updated on