Two-step approval for document change tickets

sosyoscom

Hi,

I am evaluating osTicket for internal document change requests.

The idea is to use a ticket whenever someone wants to update a procedure, work instruction or controlled form.

The ticket would contain fields such as:

document name and ID
current revision
proposed revision
reason for the change
affected teams or processes
document owner
reviewer
final approver
planned effective date

I saw that custom forms can hold these fields and that the Help Desk Audit plugin can record field edits, status changes and agent activity.

What I am trying to understand is whether osTicket can enforce a simple two-step approval process without custom development.

The workflow would be:

The document owner opens the change request.
A reviewer checks the proposed changes.
A different person gives final approval.
Only an authorized role can set the ticket to Approved.
The ticket cannot be closed until the approval fields are completed.
The audit history shows who reviewed and approved the request and when.

The requester should not be able to approve their own change.

Would this be possible with custom forms, custom ticket statuses, roles, queues and the Audit plugin, or would it require a separate plugin?

I work with ISO management system documentation and maintain isochecklist.com. I have some background information on document revision and approval notes (isochecklist[dot]com/clause-7-support). The page is mine and only explains the document-control requirement behind the question. It is not osTicket documentation.

I am not using this in production yet. I would like to test the simplest setup before adding custom code.

Has anyone built a similar approval flow with the current osTicket version?

KevinTheJedi

sosyoscom

Just a quick note, we don’t allow external links like that for many reasons; mainly security reasons. So I converted it to plain-text.

You can add/edit any custom field and make it non-editable for users so they can’t update it. You can also limit the view/creation abilities for fields so users can’t see them at all; internal only. You can do the same configurations for Agents. That said, any Agent with access to the Ticket with a role that allows edit permissions will be able to update the field. You can create a view-only role (or a role that doesn’t contain edit privileges) for the non-approvers so they can’t edit the field but they wouldn’t be able to update any field on that Ticket.

If that doesn’t work for you you’d need to customize the code. When modifying the codebase you are always on your own as you are deviating from core. The code is open source and publicly available on Github. Github has a great search tool and even a code tree/glossary that aids in navigating the code. You will proceed at your own risk.

Cheers.