Source string Read only

type: Content of: <section><section><title>
10/100
Context English State
$Self->{TicketAcl}->{'201-ACL-Process'} = {
# match properties
Properties => {
User => {
Group_rw => [ 'MyGroup' ],
},
},
Possible => {
Process => ['P1', 'P2', 'P3'],
},
PossibleNot => {
Process => ['P4'],
},
};
$Self->{TicketAcl}->{'202-ACL-Process'} = {
# match properties
Properties => {
User => {
Role => [ 'MyRole' ],
},
},
Possible => {
Process => ['P1', 'P2', 'P3'],
},
PossibleNot => {
Process => ['P4'],
},
};
Import Ready2Adopt process
Import
On the <emphasis>AdminProcessManagement</emphasis> screen you can find an <emphasis>Ready2Adopt Processes</emphasis> widget, where you can find best practice Ready2Adopt processes. Currently, there is only an <emphasis>Application for leave</emphasis> process available, but you can find additional Ready2Adopt processes in the <emphasis role="bold">OTRS Business Solution™</emphasis>.
Import Ready2Adopt Processes widget
<graphic fileref="screenshots/customization/pm-process-widget.png" scalefit="1" width="100%" contentdepth="100%"></graphic>
Select process from the drop-down menu and click on the <emphasis>Import Ready2Adopt process</emphasis> button. After the process is imported, don't forget to deploy changes.
Localization of the OTRS Front End
Procedures for localization for the OTRS framework, steps to be followed to create a new language translation, as well as procedures for translation customizations, can be found in the <ulink url="https://doc.otrs.com/doc/manual/developer/6.0/en/html/translate.html">Translating OTRS</ulink> chapter from the developer manual.
From OTRS 2.0 on, Access Control Lists (ACLs) can be used to control access to tickets, modules, queues, etc., or to influence actions on tickets (closing, moving, etc.) in certain situations. ACLs can be used to supplement the existing permission system of <link linkend="adminarea-roles">roles</link> and <link linkend="adminarea-groups">groups</link>. Using ACLs, rudimentary work-flows within the system can be mapped, based on ticket attributes.
In a general way ACLs are used to reduce the possible options for a ticket based on a defined set of rules.
ACLs can be directly entered into the <filename>Kernel/Config.pm</filename> file. However this is not any more recommended as OTRS comes now with a GUI <link linkend="adminarea-groups">Access Control Lists</link> in the Admin panel that allows to save the ACLs in the Database as the first step and then deploy them into a file when they are ready.
This chapter has some ACL examples which will walk you through the process of defining ACL definitions, and a reference of all possible important ACL settings.
The default user 'root@localhost' is not affected by the Ticket ACLs
Definition
The ACL definition can be split into two big parts, 'Matching' and 'Change'. In the matching sections the ACLs contains attributes that has to be met in order to use the ACL. If the attributes defined in the ACL does not match with the attributes that are sent, then the ACL does not take any affect, but any other match ACL will. The change sections contains the rules to reduce the possible options for a ticket.
Matching Sections
<literal>Properties</literal>
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.
<literal>PropertiesDatabase</literal>
This section is similar to <literal>Properties</literal> 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 Sections
<literal>Possible</literal>
Possible section resets the data to be reduce to only the elements that are set in this section.
<literal>PossibleAdd</literal>
Elements in PossibleAdd section add missing elements that were reduced in other ACLs. PossibleAdd is only used in together with other ACLs that have Possible or PossibleNot sections.
<literal>PossibleNot</literal>
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.
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:
Modifiers
ComponentTranslation
This translation Translated OTRS 6/Administration Manual Definition
The following string has the same context and source.
Translated OTRS 6/ITSM Configuration Management Definition

Loading…

User avatar None

New source string

OTRS 6 / Administration ManualEnglish

New source string a year ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
type: Content of: <section><section><title>
Flags
read-only
Source string location
en/content/customization/acl.xml:41
String age
a year ago
Source string age
a year ago
Translation file
i18n/doc-admin.pot, string 771