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

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 - Problem

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