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
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.
The post State machines for tickets via ACL appeared first on The OTRS Blog.