Osticket: RFC: Workflow and Change Management

[greezybacon]

I'm working on the idea of adding change management and workflow to osTicket and wanted to make a proposal to the community in hopes of encompassing greater ideas of how it should work. Your thoughts are welcome.

Motivation

The ticketing system is often used to track common tasks that need to be done consistently every time they are requested. Furthermore, often times, some approval mechanism is required, pursuant to documentation and regulation, to properly track changes made to systems.

Usually, when we are reviewing problems from some common tasks, we often suggest changes to our procedures to check and verify certain things, as well as add in new things which need to be done based on changes in the equipment we manage. It would be best if the ticketing system we use to request and track work could help ensure the work is performed correctly and consistently.

Major Additions

This mockup presentation proposes three major additions to the osTicket product to facilitate the addition of a workflow and change management process to osTicket:

• Ticket statuses should receive a _transition_ configuration which governs which statuses from which a ticket can transition to a new status. Additionally, conditions can be applied to govern when a status transition is possible. This builds off of the "required to close" feature of v1.10, but does not replace it.
• An approval field is added to facilitate and track approvals. This is implemented as a custom form field which could allow for multiple approvals on a single ticket and also allows for approvals on tasks.
• Task template sets (also "Canned Tasks") should be added to facilitate groups of tasks which can be added manually or programatically to tickets. The sets are intended to be attached to tickets exclusively, not as a list of tasks to be added to the task queue directly.

Ticket Status Transitions

The ticket status edit dialog receives a new tab, perhaps named "Transitions"

The transitions define which current states are acceptable from which the ticket can transition to the state being edited. For instance:

This status, "Closed" can be set if a ticket is currently "Open" or "On Hold". The transition to "Closed" is otherwise forbidden. Additionally and optionally, on the right of the dialog is a configuration to define what conditions must be met in order for a ticket to transition from "Open" to "Closed". The conditions can be left blank to allow the transition regardless of the current data in the ticket.

Additionally, an "All Statuses" wildcard can be used to define transitions valid from any status with optional conditions applied.

For instance, allow transitions from and status to "Closed" as long as a help topic is set.

_Transition conditions and inbound acceptable statuses are ignored when a ticket is initially opened or reopened._

A new thread event type, called "status" should be added to help in adding ticket and task workflow status change events to the thread. Currently, only "created", "reopened", and "closed" events are supported. These should be migrated to or complimented with a "status" change event to represent other changes in status. Such would facilitate automated activities such as emails when a more capable automation feature is implemented.

Approval Custom Field

To facilitate approvals, a new permission is added to the role permissions, named Approval -- Allow agent to approve and decline. The new field, when added to a form, can be configured to allow any role with this permission, or only a certain role, to approve the field. The field will usually be configured to be "Required for closure" to prevent closing of the ticket or task without approval.

Furthermore, the new ticket status transition tool can be used to prevent transitions to another status unless the approval field is approved. Using the custom queue feature suggested, a queue could be configured for managers which might display tickets or tasks which have an approval field with pending approval status.

Optionally, a default approval text can be configured so that, if certain wording is required for some policies or regulation, it can be provided as a default when approving via the web interface.

Using the role and permission model allows agents to be configured to only have approval rights if the ticket or task is routed to a prescribed department. Using the new role feature in v1.10, this allows agents to have approval rights for some departments and not for others.

The intention of the role selection in the field configuration is so that, if a single form required approval from multiple individuals, each field could be configured to require a different role. Normally, the _Any Role_ selection should be sufficient. Additionally, the list of roles in the drop down should be filtered to only display roles having the _Approval_ permission.

Approval Workflow

When viewing a ticket with a custom form with an approval field, if the agent viewing the ticket has the permission to approve it, a widget facilitating the approval process will be rendered with the custom data.

In addition to approving the request, an agent could decline the request or request some edit to the request before making an approval. The process continues from the selected action to another widget allowing for an approval / decline comment.

Once approved, the ticket receives an event in its thread marking the approval and the approval field in the custom data. The approval comments are added as an internal note. Agents with approval rights should have the opportunity to continue to make changes to the approval status, by selecting a new status and providing a new comment. The initial state of the field is Pending, and the pending state can be used again if a request is _Unapproved_.

Other agents will see the field rendered with the current state without the ability to change the state of the approval field.

Task Templates

A new management page should be added to allow the definition of tasks which will be added as a set to tickets later. This is useful for providing that a certain workflow is consistently performed every time the work is performed. It builds off of the task feature allowing for sets of tasks to be grouped together, optionally defining associated data and dependencies.

Navigating to one of the task template sets reveals the tasks defined for the set. This navigation is similar to the navigation used for the email template sets, where email templates are organized into groups. To edit or view a template, the administrator navigates through the template set page.

The task workflow should be changed to include a new state, called "pending". The new state is used to represent parked tasks which have not yet been started. The current "open" state is used to represent tasks which have been started.

The page layout shows the tasks defined in the set and also shows the interdependence between various tasks. In this example, each tasks is dependent on the previous one. The idea is that, when the set is added to a ticket, work can begin immediately on the first task; however the other tasks, dependent on the previous, remain in a new state, called "pending". They cannot be "opened" until the previous task is completed.

Navigating to one of the tasks allows for defining the details of the task itself, including its dependencies and associated data (custom forms).

Another suggested new option is the ability to define a floating due date. It is defined as a number of hours or days from a reference time. Initially there are three options for the reference time:

• _From the start of this task_ - the due date will be defined as _x_ hours from when the task is started. This is different from when the task is added to the ticket, because it might not be started immediately based on its dependent tasks' completions.
• _From the start of task set_ - the due date will be defined as _x_ hours from when the first task in this task set is started. This would be useful if a group of tasks should all be completed within a certain time frame.
• _From the start of the ticket_ - the due date will be defined as _x_ hours from the creation date of the referenced ticket. This would be useful for maintaining a certain response time from when the ticket was submitted.

Forms can be (optionally) added by default to the new task when it is created, and the task can cite one or more dependent tasks which must be completed before this task can be started.

When viewing a task which is associated with a template set, the other tasks in the set should be shown in the task view. Such will allow much easier navigation between the tasks. Also, the task titles should reference the associated ticket and the there should be a link on the page to allow navigation to the associated ticket.

Perhaps an arrow could be used to indicate the current task being viewed, which would help establish the context of where the current task fits with the overall progress of the set. Also, notice how the create time is not the same as the start time. The task workflow should be changed, so that initial emails and other automation performed when a task is started should be deferred from the task creation. In this way, when one task is closed, it can signal the start of dependent tasks and therefore signal initial emails and such.

Tasks are also available when viewing the ticket itself.

A new permission should be added to the role, perhaps named Task Template -- Allow adding, removing, and modifying template tasks under the _Ticket_ role permissions. Such would allow agents to add and remove adhoc tasks, but restrict access to add or remove the task template sets added to a ticket. Again, this helps ensure consistent work flows for similar tickets.

To this cause, the help topic should be modified to allow the automated addition of a task template set to a ticket when the ticket is created, based on the selected help topic.

When viewing a ticket, a task template set can also be added to the ticket manually (provided the agent has permission). The _Add New Task_ button could be outfitted with a drop-down menu providing access to add a set of tasks.

The addition of the template set is performed via a popup dialog.

If there is already at least one task attached to the ticket, the dialog will provide an option to select a task as an initial dependency. If set, the first task in the set will not be started until the referenced task is completed.

Goals

Again, the goal of this feature is to implement a documented approval in the ticket life cycle and to allow simple definitions of ticket work flows which assist in facilitate consistent work for repeated activities managed by the ticketing system.

The mockups presented here are for reference and imagination only. They certainly do not constrain how the feature should look, work, or otherwise integrate with the current product.

Feel free to elaborate on and compare your view of ticket work flows with respect to how closely these ideas fit with your workflow needs.

[jdelhome3578]

Could you include #2806 into this?

[Chefkeks]

Sounds pretty good, the goal is surely be achieved with the described / shown improvements.

Need to re-read again in 2016 (and not from my mobile phone...) to give some more detailed feedback/response and share some of my ideas with the ticket lifecycle/workflow.

Cheers,
Michael

[jdelhome3578]

I like the task stuff you could be on your way to project management and I would love to see that implementation. In it we have some many projects with so many people it can be hard to keep it all straight.

[kest874]

I also like the idea of canned tasks tied to a help topic:

HR requests a new user to be added, takes are then created, 1. create account, 2. setup equipment, 3 etc

Canned tasks could autoassign to a particular agent via a setting.

[greezybacon]

@kest874 as mocked-up, the assignee can be appointed in the manager for the canned task. It can be any agent or team. Maybe would be nice to allow same as ticket which might be useful in some cases

[balojs]

+1

[bwhatley87]

+1

[nathanzeng]

@greezybacon This is amazing! Could you please let me know if there have any new updates for this new feature?

[greezybacon]

I have one feature implemented in #2901. Any feedback is welcome

[nathanzeng]

Thanks @greezybacon.That's awesome! I'm so excited to test this feature.

[DrGreenBean]

+1 Registered just so I can give feed back on this.
Phase 2 jobc ards... lol

[balojs]

@greezybacon is a great idea

[dotcade]

@greezybacon Has any progress been made on this? This is fantastic.

[greezybacon]

@dotcade I have canned tasks implemented in #2901. The other features mentioned here I haven't started yet.

[Rujinraj]

@dotcade can it will be implemented in new version v1.10.2 ?

[Rujinraj]

@greezybacon can it will be implemented in new version v1.10.2 ?

[ntozier]

Q: can it will be implemented in new version v1.10.2 ?
A: No.
1.10.2 will be a security update and will not include new features.
It will also not be in 1.11 which will introduce new features.
It should be included in the Task revamp which will take place after 2.0 is released. No we do not have a release date for that.

As a side note please do not post what are essentially duplicate posts.

[F3000]

This feature could be grade for travel approvals .
An employee can create a new ticket with all relevant documents for his travel .

And his manager can approve the ticket /travel easily .

Thanks for the approach ;)

[geo782]

Approval Custom Field is a great idea. Except Required Role, I would also suggest to have another field in its options, to select/multiselect specific agents that can approve ticket. That way :
it checks if user's role has approval permission OR if user can approve only this specific field although he doesnt have permission from his role to approve. With that combination, you add approval custom fields to different forms and you can have better control of approvals depending on the topic/department that the ticket belongs.

George :)

[Jeegby]

has this change management implemented?

[JediKev]

@Jeegby

No, if it was, you'd see a reference in the thread and this "Issue" (Feature Request) would be marked as Closed.

Cheers.

[Jeegby]

Thanks for the reply @JediKev.
Would OsTicket have a work around for a change management system?

[JediKev]

@Jeegby

Currently I do not know of any workarounds. I do believe this is being broken down into sections though, starting with the introduction of Canned Tasks and Automation mockups/ideas:

Canned Tasks

• https://github.com/osTicket/osTicket/pull/2901

Automation

• https://github.com/osTicket/osTicket/issues/5197

Cheers.

[recentcoin]

Will there ever be any business logic in this? For example, if Susy owns Application X which lives on Hardware Item 47, If Todd needs to flash the firmware on Hardware Item 47, the ticket would go to Suzy to set a maintenance window for the change.

[andrea7504]

Which is the roadmap of the tk workflow and change management?

[JediKev]

@andrea7504

We do not have a "roadmap" for this at this time. We are currently focusing on a complete rewrite of the code base which we call osTicket v2.0. You can follow the public roadmap here:

• https://github.com/osTicket/roadmap

Cheers.