State machines for tickets via ACL

Jens Bothe17. Aug 2010 | ConsultingUse cases

Disclaimer:

The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

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.