Arctyk ITSM ticket workflow¶

Arctyk’s ticketing system was refactored to mirror the workflow practices found in Jira. The core idea is that a ticket belongs to a status (e.g., New, In Progress, Resolved) and each status belongs to a broader status‑category (todo, in‑progress, done). The category is derived automatically from the status and is used to group statuses logically. The tickets/constants.py module defines the system‑level categories (todo, in_progress and done) and the allowed statuses (e.g., STATUS_NEW, STATUS_IN_PROGRESS, STATUS_RESOLVED, STATUS_CLOSED) and maps each status to its category via STATUS_TO_CATEGORYgithub.com.

Workflow transitions¶

Category‑based UI actions¶

A list of workflow transitions is defined to determine which statuses a ticket can move to from its current category. These transitions also supply labels and styles used in the UI. For example, tickets in the todo category (statuses like new or open) can transition to in‑progress with the label Start Progress; tickets in in‑progress can transition to resolved or back to open; tickets in done can be reopened github.com. These definitions power the buttons shown on the ticket detail screen and ensure only valid transitions are presented.

Status‑to‑status transitions¶

At a lower level, the tickets/workflows.py file defines a more explicit mapping of allowed status‑to‑status transitions. The TICKET_STATUS_TRANSITIONS dictionary shows the permitted next statuses for each state: e.g., from todo you may move a ticket to in progress, waiting or closed; from in progress you may go to waiting, resolved or closed; once a ticket is closed there are no further transitions github.com. The helper is_valid_transition returns True if the new status is the same as the old one or is in the allowed set github.com.

Enforcement in forms and models¶

Both the user interface and the backend enforce the workflow rules:

• Form‐level guard: When a user edits a ticket, the TicketForm’s clean_status method runs. It checks the current ticket’s status category and uses WORKFLOW_TRANSITIONS to validate the requested change. If the new status belongs to a category not listed as a valid next step, a ValidationError is raised github.com. This prevents users from choosing invalid transitions in the UI.
• Model‑level enforcement: The Ticket model overrides save() to ensure that even if someone tries to bypass the form, the workflow rules are enforced. When saving an existing ticket whose status is changing, it finds the previous status, looks up the allowed transitions for that status’s category, and raises a ValidationError if the new status isn’t allowed github.com. The save() method also derives the status_category from the chosen status on every save github.com.
• Available transitions for UI: The model exposes a get_available_transitions() method which computes the valid next statuses for a ticket by mapping its current status to its category and looking up WORKFLOW_TRANSITIONSgithub.com. Templates and front‑end scripts call this method to populate dropdowns or buttons with the allowed moves.

Workflow example¶

A ticket typically starts in the New or Open status (category todo). From there, a user can start work on it, which moves it to In Progress (category in‑progress). While in progress you may resolve the issue or move it back to Open (if blocked). Once a ticket is marked as Resolved, another user can Close it (category done), or reopen it if more work is required. Closed tickets are terminal and cannot transition further github.com.

Alignment with Jira¶

Jira organizes issue states into high‑level categories (To Do, In Progress, Done) and defines allowed transitions between statuses. Arctyk follows this pattern by:

• Storing a status and deriving its status_category automatically github.com.
• Defining sets of allowed transitions between categories and statuses for UI actions and enforcing them in forms and models github.com github.com.
• Providing labels like “Start Progress,” “Resolve,” and “Reopen” for transitions to guide usersgithub.com.

This modular approach means the workflow can be extended (e.g., adding new statuses) by updating the constants and transition dictionaries without rewriting view logic. It ensures tickets move through a predictable lifecycle—from new, through in‑progress work, to resolution and closure—while allowing administrators to tailor the workflow to their organization’s needs.

TICKET_STATUS_TRANSITIONS = {

    "todo": {"in_progress", "waiting", "closed"},

    "in_progress": {"waiting", "resolved", "closed"},

    "waiting": {"in_progress", "resolved"},

    "resolved": {"closed", "in_progress"},

    "closed": set(),  # terminal

}




def is_valid_transition(old_status, new_status):

    if old_status == new_status:

        return True

    return new_status in TICKET_STATUS_TRANSITIONS.get(old_status, set())