Access Control Lists (ACL)

October 8, 2024

Table of Contents

Working with tickets can become a bewildering task. Many options are given to process, or close tickets, even if they are not needed in the current state of a ticket or due to the role of the current agent. Hiding unneeded entries cleans up the menu bar and gets it easier to work with, hiding values from dynamic fields or next queues lowers chance of human error.

OTRS uses access control lists (ACL) to restrict agents and customer users on ticket options, allowing only correct and meaningful activities with a ticket. OTRS administrators can easily generate ACLs in the graphical interface to prevent ticket closure until meeting specific requirements, prevent tickets from being moved to queues before adding the defined information and much more.

Use this screen to manage access control lists in the system. A fresh OTRS installation contains no access control lists by default. The access control lists management screen is available in the Access Control Lists (ACL) module of the Processes & Automation group.

Manage Access Control Lists

Note

When creating some access control lists, please keep in mind that they are executed alphabetically as displayed in the access control lists overview.

Warning

ACL restrictions will be ignored for the superuser account (UserID 1).

To create a new ACL:

Click on the Create New ACL button in the left sidebar.
Fill in the required fields.
Click on the Save button.
You will be redirected to Edit ACL screen to edit the ACL structure.

To edit an ACL:

Click on an ACL in the list of ACLs or you are already redirected here from Create New ACL screen.
Modify the fields and the ACL structure.
Click on the Save or Save and finish button.
Deploy all ACLs.

To delete an ACL:

Click on an ACL in the list of ACLs.
Set the Validity option to invalid or invalid-temporarily.
Click on the Save button. A new Delete Invalid ACL button will appear in the left sidebar.
Click on the Delete Invalid ACL button.
Click on the Delete button in the confirmation screen.
Deploy all ACLs.

Warning

ACLs are written into ZZZACL.pm file in Perl format. Without deploying, all ACLs are still in this cache file even if they are deleted or the Validity option is set to invalid or invalid-temporarily. Don’t forget to deploy all ACLs after modifications!

To deploy all ACLs:

Click on the Deploy ACLs button in the left sidebar.

Note

New or modified ACLs have to deploy in order to make affect the behavior of the system. Setting the Validity option to valid just indicates, which ACLs should be deployed.

To export all ACLs:

Click on the Export ACLs button in the left sidebar.
Choose a location in your computer to save the Export_ACL.yml file.

To import ACLs:

Click on the Browse… button in the left sidebar.
Select a previously exported .yml file.
Click on the Overwrite existing ACLs? checkbox, if you would like to overwrite the existing ACLs.
Click on the Import ACL configuration(s) button.
Deploy the imported ACLs with Deploy ACLs button.

Note

If several ACLs are added to the system, use the filter box to find a particular ACL by just typing the name to filter.

Warning

The maximum number of 80 valid ACLs should not be exceeded. Exceeding this limit may affect the system performance.

Warning

Changing the name of this object should be done with care, the check only provides verification for certain settings and ignores things where the name can’t be verified. Some examples are dashboard filters, access control lists (ACLs), and processes (sequence flow actions) to name a few. Documentation of your setup is key to surviving a name change.

Possible Data Loss

Warning

If a drop-down field has a value that is forbidden by ACL, the stored value in a ticket will be changed or removed after the form is submitted. This can cause possible data loss!

Here is an example to explain the possible problems:

A drop-down dynamic field is created with four possible values: BRONZE, SILVER, GOLD and VIP. Empty value also allowed. The agent can select BRONZE, SILVER and GOLD only. The VIP value can be set only by the generic agent. This is restricted by an ACL. The dynamic field is added to some ticket screens. In a screen the field is set as mandatory but in another screen the field is not mandatory and empty value is allowed.

The agent creates a new ticket. The agent can select only the allowed values, the VIP value is not displayed. SILVER is selected and the ticket is created.
The generic agent changes the value to VIP.
The agent opens a ticket action where the field is added as mandatory. Since the field is mandatory the agent has to select an other value instead of VIP which is not visible to the agent due to an ACL rule. The form is submitted and the dynamic field value is changed. This can be an unintended change.
The generic agent changes the value to VIP again.
The agent opens a ticket action where the field is added as optional. The field shows an empty value because the current VIP value is not visible to the agent. Since the field is not mandatory the agent does not change the value and leaves it empty. The form is submitted and the dynamic field value is changed to empty value. This can be a possible data loss.

Be careful of unintended data change! The same situation can happen with dynamic fields, priorities, queues, states, types and any other drop-down fields that are forbidden by ACLs.

ACL Settings

The following settings are available when adding or editing this resource. The fields marked with an asterisk are mandatory.

Name *: The name of this resource. This field can only contain the following characters: a-z, A-Z, 0-9, +, -, *, /. The name will be displayed in the overview table.
Comment: Add additional information to this resource. It is recommended to always fill this field as a description of the resource with a full sentence for better clarity, because the comment will be also displayed in the overview table.
Description: Like comment, but longer text can be added here.
Stop after match: ACLs are evaluated in alphabetical order. This setting disables the evaluation of the subsequent ACLs.
Validity *: Set the validity of this resource. Each resource can be used in OTRS only, if this field is set to valid. Setting this field to invalid or invalid-temporarily will disable the use of the resource.

Edit ACL Structure

The ACL definition can be split into two big parts, Match settings and Change settings.

Match Settings

In the match settings the ACLs contain attributes that has to be met in order to use the ACL. If an ACL contains more than one attribute then all attributes have to be met. If the attributes defined in the ACL do not match with the attributes that are sent, then the ACL does not take any affect, but any other match ACL will.

Properties: This section contains matching options that can be changed on the fly. For example on a ticket creation time the data of the ticket changes dynamically as the agent sets the information. If an ACL is set to match a ticket attribute then only when the matching attribute is selected the ACL will be active and might reduce other ticket attributes, but as soon as another value is selected the ACL will not take any affect.
PropertiesDatabase: This section is similar to Properties but does not take changes in ticket attributes that are not saved into the database, this means that changing an attribute without submit will not make any effect. This section is not use for ticket creation screens (as tickets are not yet created in the database).

Change Settings

The change settings contain the rules to reduce the possible options for a ticket.

Possible: This section is used to reset the data to be reduce to only the elements that are set in this section.
PossibleAdd: This section is used to add missing elements that were reduced in other ACLs. This section is only used in together with other ACLs that have Possible or PossibleNot sections.
PossibleNot: This section is used to remove specific elements from the current data. It could be used stand alone or together with other ACLs with a Possible or PossibleAdd sections.

Modifiers

In order to make the development of ACLs easier and more powerful there is a set of so called modifiers for the attributes on each section. This modifiers are explained below:

[Not]: This modifier is used to negate a value, for example [Not]2 low. Talking about priorities will be the same as to have: 1 very low, 3 normal, 4 high, 5 very high.
[RegExp]: It is used to define a regular expression for matching several values, for example [RegExp]low. In this case talking about priorities is the same as 1 very low, 2 low.
[regexp]: It is very similar to [RegExp] but it is case insensitive.
[NotRegExp]: Negated regular expressions, for example [NotRegExp]low. Talking about priorities is the same as 3 normal, 4 high, 5 very high.
[Notregexp]: It is very similar to [NotRegExp] but it is case insensitive.

ACL Examples

Limit available queues based on current queue and priority

This example shows how to restrict the available queues to the Alert queue if the ticket is currently in the queue Raw and has the priority 5 very high.

In this example PropertiesDatabase is used. This means that the ticket must already be in the queue Raw and must have the priority 5 very high in order to apply this ACL.

This ACL is not applied if a user only selects the queue Raw and the priority 5 very high in a dialog. To achieve this, Properties has to be used.

Using this ACL, tickets that are in the Raw queue and have the priority 5 very high can only be moved to the Alert queue.

Limit available queues based on current queue and priority

---
- Comment: Limit available queues based on current queue and priority
  ConfigChange:
    Possible:
      Ticket:
        Queue:
        - Alert
  ConfigMatch:
    PropertiesDatabase:
      Ticket:
        Priority:
        - 5 very high
        Queue:
        - Raw
  Description: Restrict the available queues to the “Alert” queue if the ticket is
    currently in the queue “Raw” and has the priority “5 very high”.
  Name: 010 Example ACL

Make certain ticket type not selectable

This example shows how to make the ticket type Unclassified not selectable for users.

In this example, the match settings are empty. This means that the ACL is always applied because the filter is empty.

---
- Comment: Make certain ticket type not selectable
  ConfigChange:
    PossibleNot:
      Ticket:
        Type:
        - Unclassified
  ConfigMatch: ''
  Description: Make the ticket type “Unclassified” not selectable.
  Name: 020 Example ACL

Note that you still may find tickets with the ticket type Unclassified. This is for example the case of incoming emails which are converted into tickets.

Ticket closing not possible for certain ticket type

This example shows how to prevent tickets with the ticket type Unclassified from being closed.

---
- Comment: Ticket closing not possible for cerain ticket type
  ConfigChange:
    PossibleNot:
      Endpoint:
      - AgentFrontend::Ticket::Action::Close
      Ticket:
        State:
        - '[RegExp]close'
  ConfigMatch:
    PropertiesDatabase:
      Ticket:
        Type:
        - Unclassified
  Description: Prevent tickets with the ticket type "Unclassified" from being closed.
  Name: 030 Example ACL

This example ACL can be used in combination with the previously described example ACL.

Note

Pay attention to the order of the ACLs. The previously described example ACL must be executed before the ACL described here.

Using regular expressions

This example shows how to use regular expressions for matching tickets and for filtering the available selection options.

With this ACL, only services that contain Hardware in their name are displayed in agent interface (and if configured as well in the external interface) if the ticket is stored in a queue whose name starts with HW, or if a queue whose name starts with HW is selected in a user dialog.

---
- Comment: Using regular expressions
  ConfigChange:
    Possible:
      Ticket:
        Service:
        - '[RegExp]Hardware'
  ConfigMatch:
    Properties:
      Ticket:
        Queue:
        - '[RegExp]^HW'
  Description: Use regular expressions for matching tickets and for filtering the
    available selection options.
  Name: 040 Example ACL

Restrict one dynamic field based on another dynamic field

This example shows how to restrict the selectable values of the dynamic field CarModel to Polo, Golf and Passat, if a user has selected the value VW in the dynamic field CarManufacturer in the same user dialog.

Make sure that you use the name of the dynamic field in format DynamicField_Name and make sure that you use the data keys of the possible values and not the data values shown to the user. Both is specified in the definition of the dynamic field.

Restrict one dynamic field based on another dynamic field

---
- Comment: Restrict one dynamic field based on another dynamic field
  ConfigChange:
    Possible:
      Ticket:
        DynamicField_CarModel:
        - Polo
        - Passat
        - Golf
  ConfigMatch:
    Properties:
      DynamicField:
        DynamicField_CarManufacturer:
        - VW
  Description: Restrict the selectable values of the dynamic field “CarModel” to “Polo”,
    “Golf” and “Passat”, if a user has selected the value “VW” in the dynamic field
    “CarManufacturer” in the same user dialog.
  Name: 050 Example ACL

In the Match settings the Ticket object can be used as an alternative to the DynamicField object.

---
- Comment: Restrict one dynamic field based on another dynamic field
  ConfigChange:
    Possible:
      Ticket:
        DynamicField_CarModel:
        - Polo
        - Passat
        - Golf
  ConfigMatch:
    Properties:
      Ticket:
        DynamicField_CarManufacturer:
        - VW
  Description: Restrict the selectable values of the dynamic field “CarModel” to “Polo”,
    “Golf” and “Passat”, if a user has selected the value “VW” in the dynamic field
    “CarManufacturer” in the same user dialog.
  Name: 051 Example ACL

Restrict one dynamic field based on another dynamic field in an action

The previous example can be extended by the restriction that it should only apply to the ticket action Change Free Fields. For this purpose, the condition that the FreeText endpoint must be affected, has to be added in the Match settings.

---
- Comment: Restrict one dynamic field based on another dynamic field in an action
  ConfigChange:
    Possible:
      Ticket:
        DynamicField_CarModel:
        - Polo
        - Passat
        - Golf
  ConfigMatch:
    Properties:
      Frontend:
        Endpoint:
        - AgentFrontend::Ticket::Action::FreeText
      Ticket:
        DynamicField_CarManufacturer:
        - VW
  Description: Restrict the selectable values of the dynamic field “CarModel” to “Polo”,
    “Golf” and “Passat”, if a user has selected the value “VW” in the dynamic field
    “CarManufacturer” in the “Free Fields” action.
  Name: 052 Example ACL

Disallow a process for a customer ID

This ACL prevents the usage of a certain process for all customer users assigned to a certain customer ID (otrs.com in this example).

Since customer users only use the external interface, the ACL is applied there.

---
- Comment: Disallow a process for a customer ID
  ConfigChange:
    PossibleNot:
      Process:
      - Process-81b2ff5db648afa3e765785ff0193320
  ConfigMatch:
    Properties:
      CustomerUser:
        UserCustomerID:
        - otrs.com
  Description: Prevents the use of a certain process for all customer users assigned
    to a certain customer ID.
  Name: 060 Example ACL

Disallow the ticket actions close and move for a certain process

This ACL example shows how to stop the ticket actions Move Ticket and Close Ticket from displaying when a specific process is selected.

---
- Comment: Disallow the ticket actions close and move for a certain process
  ConfigChange:
    PossibleNot:
      Endpoint:
      - AgentFrontend::Ticket::Action::Move
      - AgentFrontend::Ticket::Action::Close
  ConfigMatch:
    PropertiesDatabase:
      Process:
        ProcessEntityID:
        - Process-81b2ff5db648afa3e765785ff0193320
  Description: Stop the ticket actions “Move Ticket” and “Close Ticket” from displaying
    when a specific process is selected.
  Name: 070 Example ACL

Hide user task activity dialogs in a process based on the agent role

Let’s assume that a process contains a user task activity that has two user task activity dialogs assigned to it and that these user task activity dialogs shall be executed only by agents who have a specific role.

The goal is to display the correct user task activity dialogs only to the agents who have the correct role.

User task activity dialog	Agent role
Approval from Sales	Head of Sales
Approval from Marketing	Head of Marketing

For this purpose three ACLs are required.

Note

Process and user task activity dialogs are referenced by ID.

The first ACL prevents the display of all user task activity dialogs within this user task activity.

Hide user task activity dialogs in a process based on the agent role

---
- Comment: Hide user task activity dialogs in a process based on the agent role
  ConfigChange:
    PossibleNot:
      ActivityDialog:
      - '[RegExp]^ActivityDialog-'
  ConfigMatch:
    PropertiesDatabase:
      Process:
        ActivityEntityID:
        - Activity-919fb73ed4b14087d5085f6e7f13d57d
  Description: Prevents the display of all user task activity dialogs within this
    user task activity.
  Name: 080 Example ACL

By means of the next ACL it is achieved that all agents who have the role Head of Sales get the user task activity dialog Approval from Sales displayed.

---
- Comment: Hide user task activity dialogs in a process based on the agent role
  ConfigChange:
    PossibleAdd:
      ActivityDialog:
      - ActivityDialog-8ff3a399b5939d1a11e87ad35f72f576
  ConfigMatch:
    PropertiesDatabase:
      User:
        Role:
        - Head of Sales
  Description: All agents who have the role "Head of Sales" get the user task activity
    dialog "Approval from Sales" displayed.
  Name: 081 Example ACL

By means of the last ACL it is achieved that all agents who have the role Head of Marketing get the user task activity dialog Approval from Marketing displayed.

---
- Comment: Hide user task activity dialogs in a process based on the agent role
  ConfigChange:
    PossibleAdd:
      ActivityDialog:
      - ActivityDialog-18d1bce51750be6e3adee3b5d59a94d7
  ConfigMatch:
    PropertiesDatabase:
      User:
        Role:
        - Head of Marketing
  Description: All agents who have the role "Head of Marketing" get the user task
    activity dialog "Approval from Marketing" displayed.
  Name: 082 Example ACL

Note

Pay attention to the order of the ACLs. The ACL described first in this example must be executed before the last two ACLs.

Pitfalls using properties

If ticket attributes are used in both Match settings and Change settings at the same time, a logical problem occurs when using Properties, which may prevent ticket actions from being used in a proper way.

In this example you can see in the Match settings the queue Raw and the priority 5 very high and in the Change settings the queue Alert is possible.

---
- Comment: Pitfalls Using Properties
  ConfigChange:
    Possible:
      Ticket:
        Queue:
        - Alert
  ConfigMatch:
    Properties:
      Ticket:
        Queue:
        - Raw
  Description: If ticket attributes are used in both Match settings and Change settings
    at the same time, a logical problem occurs.
  Name: 090 Pitfalls

If you deploy this ACL and then run the Move Ticket ticket action in a ticket, you will see that you cannot click the Send button if you select the Raw queue because the change setting will be applied immediately (due to Properties) and this will result in your selection being deleted because the Raw queue is no longer a valid selection.

Typically this logical problem can be avoided by using PropertiesDatabase instead of Properties. Please compare with the very first given example.

ACL Reference

Properties, keys and values that can be used in ACLs are highly depend on the OTRS installation. For example the possibilities can be extended by installing extension modules, as well as it can be depend on the customer user mapping set in Config.pm. Therefore it is not possible to provide a full ACL reference, that contains all settings.

For properties, keys and values that can be used in ACLs, see the following example ACL in YAML format. The example ACL is complete for a default OTRS installation. The ellipsis denotes any options available from installed features or customer user mappings.

---
- ChangeBy: root@localhost
  ChangeTime: 2020-04-15 16:46:23
  Comment: ACL Reference.
  ConfigMatch:
    Properties:
      # Match properties (current values from the form).
      CustomerUser:
        UserLogin:
        - some login
        UserCustomerID:
        - some customer ID
        Group_rw:
        - some group
      DynamicField:
        # Names must be in DynamicField_<field_name> format.
        # Values for dynamic fields must always be the untranslated internal
        #   data keys specified in the dynamic field definition and not the
        #   data values shown to the user.
        # Using the key is also mandatory for dynamic field of type database
        #   and dynamic field of type web service.
        DynamicField_Field1:
        - some value
        DynamicField_OtherField:
        - some value
        DynamicField_TicketFreeText2:
        - some value
        # more dynamic fields
      Frontend:
        Endpoint:
        - AgentFrontend::PersonalPreferences
        - AgentFrontend::ProcessTicketNextStep
        - AgentFrontend::Ticket::Action::Close
        - AgentFrontend::Ticket::Action::Customer
        - AgentFrontend::Ticket::Action::EmailOutbound
        - AgentFrontend::Ticket::Action::FreeText
        - AgentFrontend::Ticket::Action::Link
        - AgentFrontend::Ticket::Action::Lock
        - AgentFrontend::Ticket::Action::Merge
        - AgentFrontend::Ticket::Action::Move
        - AgentFrontend::Ticket::Action::Note
        - AgentFrontend::Ticket::Action::Owner
        - AgentFrontend::Ticket::Action::Pending
        - AgentFrontend::Ticket::Action::PhoneCallInbound
        - AgentFrontend::Ticket::Action::PhoneCallOutbound
        - AgentFrontend::Ticket::Action::Print
        - AgentFrontend::Ticket::Action::Priority
        - AgentFrontend::Ticket::Action::Process
        - AgentFrontend::Ticket::Action::Redirect
        - AgentFrontend::Ticket::Action::Responsible
        - AgentFrontend::Ticket::Action::SmsOutbound
        - AgentFrontend::Ticket::Action::TicketHistory
        - AgentFrontend::Ticket::Action::Unlock
        - AgentFrontend::Ticket::Action::Unwatch
        - AgentFrontend::Ticket::Action::Watch
        - AgentFrontend::Ticket::InlineEditing::Property::CustomerUserID
        - AgentFrontend::Ticket::InlineEditing::Property::Lock
        - AgentFrontend::Ticket::InlineEditing::Property::Owner
        - AgentFrontend::Ticket::InlineEditing::Property::Priority
        - AgentFrontend::Ticket::InlineEditing::Property::Queue
        - AgentFrontend::Ticket::InlineEditing::Property::Responsible
        - AgentFrontend::Ticket::InlineEditing::Property::Service
        - AgentFrontend::Ticket::InlineEditing::Property::State
        - AgentFrontend::Ticket::InlineEditing::Property::Type
        - AgentFrontend::Ticket::InlineEditing::Property::Watch
        - AgentFrontend::TicketArticle::Action::CopyLink
        - AgentFrontend::TicketArticle::Action::Forward
        - AgentFrontend::TicketArticle::Action::MarkAsImportant
        - AgentFrontend::TicketArticle::Action::MessageLog
        - AgentFrontend::TicketArticle::Action::Plain
        - AgentFrontend::TicketArticle::Action::Print
        - AgentFrontend::TicketArticle::Action::Redirect
        - AgentFrontend::TicketArticle::Action::Reply
        - AgentFrontend::TicketArticle::Action::ReplyAll
        - AgentFrontend::TicketArticle::Action::ReplyToNote
        - AgentFrontend::TicketArticle::Action::ReplyViaSms
        - AgentFrontend::TicketArticle::Action::Split
        - AgentFrontend::TicketArticle::Action::UnmarkAsImportant
        - AgentFrontend::TicketCreate::Email
        - AgentFrontend::TicketCreate::Phone
        - AgentFrontend::TicketCreate::Process
        - AgentFrontend::TicketCreate::SMS
        - AgentFrontend::TicketDetailView
        - AgentFrontend::TicketDetailView::Property
        - AgentFrontend::TicketList::Bulk
        - AgentFrontend::TicketList::Filters
        - ...
        - ExternalFrontend::PersonalPreferences
        - ExternalFrontend::ProcessTicketCreate
        - ExternalFrontend::ProcessTicketNextStep
        - ExternalFrontend::Ticket::ExportList     # used for technical purpose, not for ACLs
        - ExternalFrontend::Ticket::List           # used for technical purpose, not for ACLs
        - ExternalFrontend::Ticket::Print
        - ExternalFrontend::TicketCreate
        - ExternalFrontend::TicketDetailView
        - ...
      Owner:
        UserLogin:
        - some login
        Group_rw:
        - some group
        Role:
        - admin
        # more owner attributes
      Priority:
        ID:
        - some ID
        Name:
        - some name
        # more priority attributes
      Process:
        ProcessEntityID:
        # the process that the current ticket is part of
        - Process-9c378d7cc59f0fce4cee7bb9995ee3eb
        ActivityEntityID:
        # the current activity of the ticket
        - Activity-f8b2fdebe54eeb7b147a5f8e1da5e35c
        ActivityDialogEntityID:
        # the current activity dialog that the agent/customer is using
        - ActivityDialog-aff0ae05fe6803f38de8fff6cf33b7ce
      Queue:
        Name:
        - Raw
        QueueID:
        - some ID
        GroupID:
        - some ID
        Email:
        - some email
        RealName:
        - OTRS System
        # more queue attributes
      Responsible:
        UserLogin:
        - some login
        Group_rw:
        - some group
        Role:
        - admin
        # more responsible attributes
      Service:
        ServiceID:
        - some ID
        Name:
        - some name
        ParentID:
        - some ID
        # more service attributes
      SLA:
        SLAID:
        - some ID
        Name:
        - some name
        Calendar:
        - some calendar
        # more SLA attributes
      State:
        ID:
        - some ID
        Name:
        - some name
        TypeName:
        - some state type name
        TypeID:
        - some state type ID
        # more state attributes
      Ticket:
        Queue:
        - Raw
        State:
        - new
        - open
        Priority:
        - some priority
        Lock:
        - lock
        CustomerID:
        - some ID
        CustomerUserID:
        - some ID
        Owner:
        - some owner
        DynamicField_Field1:
        - some value
        DynamicField_MyField:
        - some value
        # more ticket attributes
      Type:
        ID:
        - some ID
        Name:
        - some name
        # more type attributes
      User:
        UserLogin:
        - some_login
        Group_rw:
        - some group
        Role:
        - admin
    PropertiesDatabase:
      # Match properties (existing values from the database).
      # Please note that Frontend is not in the database, but in the framework.
      # See section "Properties", the same configuration can be used here.
  ConfigChange:
    Possible:
      # Reset possible options (white list).
      Action:
      # Possible action options (white list).
      - ...
      ActivityDialog:
      # Limit the number of possible activity dialogs the agent/customer can use in a process ticket.
      - ActivityDialog-aff0ae05fe6803f38de8fff6cf33b7ce
      - ActivityDialog-429d61180a593414789a8087cc4b3c6f
      - ...
      Endpoint:
      # Limit the functions on agent interface.
      - AgentFrontend::PersonalPreferences
      - AgentFrontend::ProcessTicketNextStep
      - AgentFrontend::Ticket::Action::Close
      - AgentFrontend::Ticket::Action::Customer
      - AgentFrontend::Ticket::Action::EmailOutbound
      - AgentFrontend::Ticket::Action::FreeText
      - AgentFrontend::Ticket::Action::Link
      - AgentFrontend::Ticket::Action::Lock
      - AgentFrontend::Ticket::Action::Merge
      - AgentFrontend::Ticket::Action::Move
      - AgentFrontend::Ticket::Action::Note
      - AgentFrontend::Ticket::Action::Owner
      - AgentFrontend::Ticket::Action::Pending
      - AgentFrontend::Ticket::Action::PhoneCallInbound
      - AgentFrontend::Ticket::Action::PhoneCallOutbound
      - AgentFrontend::Ticket::Action::Print
      - AgentFrontend::Ticket::Action::Priority
      - AgentFrontend::Ticket::Action::Process
      - AgentFrontend::Ticket::Action::Redirect
      - AgentFrontend::Ticket::Action::Responsible
      - AgentFrontend::Ticket::Action::SmsOutbound
      - AgentFrontend::Ticket::Action::TicketHistory
      - AgentFrontend::Ticket::Action::Unlock
      - AgentFrontend::Ticket::Action::Unwatch
      - AgentFrontend::Ticket::Action::Watch
      - AgentFrontend::Ticket::InlineEditing::Property::CustomerUserID
      - AgentFrontend::Ticket::InlineEditing::Property::Lock
      - AgentFrontend::Ticket::InlineEditing::Property::Owner
      - AgentFrontend::Ticket::InlineEditing::Property::Priority
      - AgentFrontend::Ticket::InlineEditing::Property::Queue
      - AgentFrontend::Ticket::InlineEditing::Property::Responsible
      - AgentFrontend::Ticket::InlineEditing::Property::Service
      - AgentFrontend::Ticket::InlineEditing::Property::State
      - AgentFrontend::Ticket::InlineEditing::Property::Type
      - AgentFrontend::Ticket::InlineEditing::Property::Watch
      - AgentFrontend::TicketArticle::Action::CopyLink
      - AgentFrontend::TicketArticle::Action::Forward
      - AgentFrontend::TicketArticle::Action::MarkAsImportant
      - AgentFrontend::TicketArticle::Action::MessageLog
      - AgentFrontend::TicketArticle::Action::Plain
      - AgentFrontend::TicketArticle::Action::Print
      - AgentFrontend::TicketArticle::Action::Redirect
      - AgentFrontend::TicketArticle::Action::Reply
      - AgentFrontend::TicketArticle::Action::ReplyAll
      - AgentFrontend::TicketArticle::Action::ReplyToNote
      - AgentFrontend::TicketArticle::Action::ReplyViaSms
      - AgentFrontend::TicketArticle::Action::Split
      - AgentFrontend::TicketArticle::Action::UnmarkAsImportant
      - AgentFrontend::TicketCreate::Email
      - AgentFrontend::TicketCreate::Phone
      - AgentFrontend::TicketCreate::Process
      - AgentFrontend::TicketCreate::SMS
      - AgentFrontend::TicketDetailView
      - AgentFrontend::TicketDetailView::Property
      - AgentFrontend::TicketList::Bulk
      - AgentFrontend::TicketList::Filters
      - ...
      # Limit the functions on external interface.
      - ExternalFrontend::PersonalPreferences
      - ExternalFrontend::ProcessTicketCreate
      - ExternalFrontend::ProcessTicketNextStep
      - ExternalFrontend::Ticket::ExportList     # used for technical purpose, not for ACLs
      - ExternalFrontend::Ticket::List           # used for technical purpose, not for ACLs
      - ExternalFrontend::Ticket::Print
      - ExternalFrontend::TicketCreate
      - ExternalFrontend::TicketDetailView
      - ...
      Form:
      # This holds the configuration for the visibility of dynamic fields.
      - list of dynamic field names
      Process:
      # Limit the number of possible processes that can be started.
      - Process-9c378d7cc59f0fce4cee7bb9995ee3eb
      - Process-12345678901234567890123456789012
      - ...
      Ticket:
      # Possible ticket options (white list).
        DynamicField_Field1:
        - some value
        DynamicField_MyField:
        - some value
        # more dynamic fields
        NewOwner:
        # For ticket action screens, where the Owner is already set.
        - some owner
        OldOwner:
        # For ticket action screens, where the Owner is already set.
        - some owner
        Owner:
        # For ticket create screens, because Owner is not set yet.
        - some owner
        Priority:
        - 5 very high
        Queue:
        - Raw
        - some other queue
        Service:
        - some service
        ServiceID:
        - some service ID
        SLA:
        - some SLA
        SLAID:
        - some SLA ID
        State:
        - some state
        StateID:
        - some state ID
        # more ticket attributes
    PossibleAdd:
       # Add options (white list).
       # See section "Possible", the same configuration can be used here.
    PossibleNot:
       # Remove options (black list).
       # See section "Possible", the same configuration can be used here.
  CreateBy: root@localhost
  CreateTime: 2020-04-15 16:46:23
  Description: This is the long description of the ACL to explain its usage.
  ID: 1
  Name: 200-ACL-Reference
  StopAfterMatch: 0
  ValidID: 3

Facebook X LinkedIn