State machines for tickets via ACL

Jens Bothe17. Aug 2010 | ConsultingUse cases

State machines for tickets via ACL

Some of you may already know OTRS::ITSM 2.0 and the brand-new Change Management which contains 2 state machines – one for the change itself and a second for the work orders.

Change state machine

Change state machine

Well, a customer knew them and asked to implement something similar for his ticket handling.

Idea

The OTRS contains a mechanism called Access Control Lists (ACL; see [ACL] for detailed discussion in the OTRS Admin Manual) which are in fact rule sets matching on certain ticket properties and allow or prevent other properties/actions/states.

An example says more than 100 words – ACL which only allows to move tickets with ticket priority 5 into a queue:

    # ticket acl
    $Self->{TicketAcl}->{'ACL-Name-2'} = {
        # match properties
        Properties => {
            # current ticket match properties
            Ticket => {
                Queue => ['Raw'],
                Priority => ['5 very high'],
            }
        },
        # return possible options (white list)
        Possible => {
            # possible ticket options (white list)
            Ticket => {
                Queue => ['Alert'],
            },
        },
    };

Theory

Together with the customer we defined 3 state machines and their transitions for Incident-, Problem- and RfC-tickets.

Some facts about the setup:

  • no Agent has the permission to “close” a ticket
  • the status “solved” is a of the type “pending auto”
  • after a “solved” ticket reached its pending time, it will be set to “closed” automatically
  • customers are not allowed to reopen a ticket (thus the grace period for ticket closing)

Some warning words about ACLs in the OTRS.
ACL don’t sum up! There is only 1 ACL defining the ticket/action/possible properties!

state machine - Incident

state machine - Incident

state machine - Problem

state machine - Problem

state machine - RfC

state machine - RfC

Practice

Defining the ACL follows a simple principle – first forbid anything, then define possible transitions.

Here’s the start of the Incident state machine:

12     ##########################################################################
13     # Statemachine - Incident
14     # by default - forbid everything
15
16     $Self->{TicketAcl}->{'ACL-ZZ-Incident-00'} = {
17         Properties => {
18             Ticket => {
19                 Type    => [ '[RegExp]^Incident', ],
20             },
21         },
22         Possible => { Ticket => { State => [ ], }, },
23     };
24
25     # new -> open
26     $Self->{TicketAcl}->{'ACL-ZZ-Incident-10'} = {
27         Properties => {
28             Ticket => {
29                 Type    => [ '[RegExp]^Incident', ],
30                 State   => [ 'new', ],
31             },
32         },
33         Possible => {
34             Ticket => {
35                 State => [ 'open', ],
36             },
37         },
38     };

So far, ACLs cannot be created using the SysConfig interface but must be entered manually into Kernel/Config.pm. Depending on the amount of ACL rulesets the Config.pm will become bloated and hard to read so I created a dedicated ACL.pm configuration file in Kernel/Config/Files. There is no special notation, just add the ACLs as needed and a single 1; at the end of the file.

Keep in mind

  • ACL have no effect for the user with the ID 1 (normally root@localhost)
    use a real user account for testing
  • turn on debugging in Kernel/System/Ticket.pm while testing
    111     # 0=off; 1=on;
    112     #$Self->{Debug} = $Param{Debug} || 0;
    113     $Self->{Debug} = 9;
  • run grep in a separate shell to see which ACL is really used
    tail -f var/log/otrs.log | grep –line-buffered “Workflow .* used”

Download

The complete ACL file can be downloaded here → TicketStateMachine-ACL.pm

The whole package including OmniGraffle, PNG and ACL can be downloaded here → state machines in ACL

Further reading

[ACL]
http://doc.otrs.org/2.4/en/html/c2177.html

PS

Please don’t discuss the state machines – they aren’t the real ones the customer has in use. Please adopt them to your needs.

#7
Jens Bothe at 09.07.2020, 11:43

Please check admin manual or contact sales@otrs.com for professional support

#6
EQUBAL at 29.03.2020, 14:33

hello otrs team As I know that ,I want to know about otrs tool communication system and admin console management integration . I am admin console 1st user. pl suggest me for all fundamental admin console setting as required for communication . Regards Equbal alam

#5
jordan at 03.10.2013, 02:55

is it normal that i cannot change the status on a change record ive created

#4
tto at 31.08.2010, 16:38

Hi Martin, don't know whether screenshots are a good idea (and besides it's not possible to add them to comments here). I could send you a sample configuration. However, the configuration for possible next states looks like this: processing,closed successful,closed unsuccessful processing,pending customer,closed successful,closed unsuccessful Together with minor modifications in the frontend modules it's possible to define a ticket-type depending default state especially for any ticket creation mask (AgentTicketPhone, AgentTicketEmail, CustomerTicketMessage). Another point is the ticket type depending followup-state which can also be configured. The automatic state actions are currently quite restricted to next state set or queue move. CU, Torsten

#3
martin at 24.08.2010, 15:53

Hi Torsten, really cool feedback. Can you describe it a little bit more, e. g. with screenshots? It's really interesting. -Martin

#2
tto at 19.08.2010, 08:25

Hi, ...a quite similar approach to Ticketstate-definition by using an ACL, is contained in Kix4OTRS, since version 3.0.x. It also offers some additional features like a few automatic state actions. The configuration for possible next states is done in the SysConfig - just search for TicketStateWorkflow. However, I'd prefer a less SysConfig-depending solution like in ITSMChangeManagement. We're open to discuss a possible implementation with the OTRS AG :). regrads, Torsten

#1
Tweets that mention State machines for tickets via ACL - OTRS Community Blog -- Topsy.com at 17.08.2010, 21:48

[...] This post was mentioned on Twitter by Christopher T. Kuhn and Jens Bothe, Daniel Ciaglia. Daniel Ciaglia said: How to implement state machines for tickets in #OTRS via ACL - http://bit.ly/bFs8si [...]

Your email address will not be published. Required fields are marked *