OTOBO Znuny ACL

Listy kontroli dostępu (ACL) w OTOBO stanowią podstawę solidnego zarządzania uprawnieniami. W tym podtemacie nauczysz się:

Koncepcje i wartość biznesowa: Dlaczego ACL są niezbędne.
Przegląd architektury: Jak wewnętrznie zbudowany jest podsystem ACL.
Match vs. Action: Podstawowa struktura ACL.
Konfiguracje systemowe: Ważne ustawienia SysConfig dotyczące ACL.

1. Koncepcje i wartość biznesowa

ACL definiują, jakie akcje agenci i klienci mogą wykonywać w systemie biletów – automatycznie i kontekstowo.

Bezpieczeństwo: Chroń wrażliwe funkcje (np. zamykanie biletów) przed nieautoryzowanym użyciem.
Użyteczność: Dynamicznie ukrywaj nieistotne przyciski lub menu, aby nie przeciążać użytkownika.
Automatyzacja: Kontroluj przepływ biletów (priorytetyzacja, eskalacja, przypisanie) bezpośrednio za pomocą reguł ACL, bez dodatkowego kodu.
Utrzymanie: Eksportuj, importuj i wersjonuj ACL centralnie – idealne dla środowisk z wieloma instancjami.

1.1 ACL oparte na rolach i kryteriach

Oparte na rolach: Przypisanie na podstawie ról lub grup agentów (np. Admin vs. Agent wsparcia).
Oparte na kryteriach: Kontrola za pomocą atrybutów biletów (Kolejka, Status, Priorytet, Pola dynamiczne, CustomerID).

Połączenie obu podejść umożliwia precyzyjne reguły, np.: „Tylko starsi agenci przenoszą bilety z priorytetem > 3 do kolejki deweloperskiej.”

2. Przegląd architektury

Podsystem ACL OTOBO jest rozłożony na kilka kluczowych komponentów:

Komponent	Zadanie
Kernel::System::ACL::DB::ACL	Backend Perl: Przechowuje i ładuje ACL z bazy danych
Kernel::System::YAML	Serializuje `config_match` i `config_change` jako tekst YAML
Kernel::System::Cache	Buforuje zapytania ACL z TTL (SysConfig: `ACL::CacheTTL`)
Tabela acl_sync	Rejestruje, które ACL są nowe lub zmienione (sync_state), aby wyzwolić wdrożenia
ZZZACL.pm	Wygenerowany plik Perl, który podczas wdrażania udostępnia wszystkie zweryfikowane ACL w modułach
biletów

perl

# Przykład: Serializacja YAML przed wstawieniem do bazy danych
my $YAML = $Kernel::OM->Get('Kernel::System::YAML');
my $ConfigMatchYAML  = $YAML->Dump(Data => $Param{ConfigMatch});
my $ConfigChangeYAML = $YAML->Dump(Data => $Param{ConfigChange});
$DBObject->Do(
    SQL  => 'INSERT INTO acl (..., config_match, config_change, ...) VALUES (?, ?, ?, ...)',
    Bind => [\$ConfigMatchYAML, \$ConfigChangeYAML, ...],
);

Uwaga: Superużytkownik (UserID 1) automatycznie ignoruje wszystkie ACL – aby się nie zablokować.

3. Podstawowa struktura ACL: Match vs. Action

Sekcja	Zadanie
Match	Definiuje warunki: sprawdza atrybuty biletów (Properties) lub wartości bazy danych (PropertiesDatabase).
Action	Określa, które elementy interfejsu użytkownika (przyciski, pola) są ukrywane lub pokazywane (Possible, PossibleAdd, PossibleNot) lub jakie akcje są wykonywane (zmiana statusu/kolejki).

Przykładowe opcje Match:

Queue, Status, Priority
DynamicField_<Name>, CustomerUser, Owner
Frontend::Module (AgentTicketZoom, CustomerTicketCreate)

Przykładowe opcje Action:

Possible: Dozwolone (biała lista), np. zezwalaj tylko na określone kolejki lub statusy
PossibleAdd: Dodaj dodatkowe wartości z ograniczonego wyboru
PossibleNot: Usuń określone przyciski (np. AgentTicketClose) z interfejsu użytkownika

4. Ważne ustawienia SysConfig

Wspomniane wyżej kluczowe elementy są konfigurowane za pomocą SysConfig:

Klucz	Opis	Przykładowa wartość
`ACL::CacheTTL`	Czas życia pamięci podręcznej w sekundach (backend)	`3600`
`ACLKeysLevel1MatchTicket`	Dozwolone pierwsze poziomy dla Match (Properties, PropertiesDatabase)	`Properties, PropertiesDatabase`
`ACLKeysLevel1ChangeTicket`	Dozwolone pierwsze poziomy dla Change (Possible, PossibleAdd, PossibleNot)	`Possible, PossibleAdd, PossibleNot`
`ACLKeysLevel2::PropertiesTicket`	Dozwolone klucze Match (Queue, State, DynamicField, itp.)	`Queue, State, CustomerUser, ...`
`ACLKeysLevel2::PossibleTicket`	Dozwolone klucze Change (Form, FormStd, Action, Process, Ticket)	`Form, FormStd, Action, ...`
`ACLKeysLevel3::Actions###DefaultTicket`	Lista wszystkich możliwych akcji w interfejsie użytkownika (AgentTicketClose, AgentTicketEmail, ...)	(patrz lista)

Wskazówka: Dostosuj ACLKeysLevel*, aby interfejs ACL zawierał tylko istotne wpisy.

Ocena, Stop-on-Match i wydajność

Ocena ACL (Access Control Lists) określa, które reguły są stosowane podczas ładowania biletu lub wykonywania akcji w systemie biletów. Efektywna konfiguracja tych procesów oraz ukierunkowana optymalizacja wydajności są kluczowe dla zapewnienia płynnego i skalowalnego interfejsu agenta.

Cykl oceny

Za każdym razem, gdy agent otwiera bilet lub wykonuje akcję (np. kliknięcie przycisku), OTOBO przechodzi przez listę wszystkich aktywnych ACL uporządkowanych według ich klucza sortowania (nazwa lub ID). Poniższy proces pokazuje proces sprawdzania i wykonywania:

Match (ConfigMatch): Tutaj sprawdzane są kryteria takie jak kolejka, status, priorytet lub pola dynamiczne.
Change (ConfigChange): Określa, które elementy interfejsu użytkownika są usuwane lub dodawane (Possible, PossibleAdd, PossibleNot) lub jakie automatyczne akcje są wykonywane (zmiana kolejki/statusu).
StopAfterMatch: Ustawione na 1, przetwarzanie zatrzymuje się po pierwszej pasującej ACL.

Zapamiętaj: Poprawnie ustawione StopAfterMatch zapobiega niepożądanym zmianom wywoływanym przez kolejne ACL.

Strategie Stop-on-Match

Opcja	Efekt
StopAfterMatch=1	Gdy tylko ACL pasuje, żadna kolejna nie jest sprawdzana – idealne dla reguł wyłącznych.
StopAfterMatch=0	Wszystkie ACL są sprawdzane – konieczne, gdy wiele ACL ma działać niezależnie od siebie.

Wskazówka: Prefiksy numeryczne (np. 100-, 200-) w nazwie ACL kontrolują naturalne sortowanie, a tym samym priorytet krytycznie ważnych reguł.

Optymalizacja wydajności

Duży zestaw ACL może wydłużyć czas ładowania formularzy biletów. Te środki pomagają zwiększyć wydajność:

Dostosuj CacheTTL: W SysConfig w ACL::CacheTTL (np. 3600 s) określasz, jak długo załadowane definicje ACL pozostają w pamięci podręcznej.
Aktywuj pamięć podręczną Preselection: Moduł TicketACL::ACLPreselection wstępnie wypełnia wybrane opcje, oszczędzając powtarzające się sprawdzania.
Redukcja reguł: Usuń przestarzałe lub zduplikowane ACL i grupuj podobne reguły.
Optymalizuj sekwencję: Umieść często pasujące ACL na początku listy.
Pola indeksowane: Używaj indeksów bazy danych dla pól dynamicznych i innych często odpytywanych właściwości.

xml


<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Czas życia pamięci podręcznej dla backendów DB-ACL w sekundach.</Description>
</Setting>

Konserwacja i najlepsze praktyki

Praktyka	Korzyść
Eksport YAML	Wersjonuj ACL w Git, aby śledzić zmiany.
Dokumentacja	Twórz dziennik zmian z datami, autorem i celem ACL.
Przegląd reguł	Regularne przeglądy w zespole zapobiegają nakładaniu się reguł.
Środowisko testowe	Weryfikuj nowe ACL za pomocą kontrolowanych biletów testowych.
Debugowanie logów	Aktywuj logi debugowania (`TicketACL::Debug::Enabled`) dla szczegółowych informacji.

Konfiguracja debugowania

xml


<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>Aktywuj debugowanie ACL</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filtr dla wyjść debugowania według ID biletu.</Description>
</Setting>

Dzięki tym ukierunkowanym strategiom zapewnisz, że Twoja infrastruktura ACL w OTOBO będzie zarówno wydajna, jak i łatwa w utrzymaniu – nawet w dużych, rozproszonych środowiskach.

Przykłady praktyczne, zarządzanie i referencje

W tej końcowej części artykułu pokażemy, jak ACL są praktycznie wykorzystywane w OTOBO na konkretnych scenariuszach. Następnie omówimy najlepsze praktyki zarządzania i podamy dalsze odniesienia.

Przykłady praktyczne

1. Automatyczna priorytetyzacja do kolejki "Alarm"

Cel: Bilety o priorytecie 5 (bardzo wysoki) natychmiast przenieść do kolejki Alarm i powiadomić agentów.

yaml

- Name: "100-Auto-Alarm"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    Properties:
      Priority:
        ID: [ 5 ]
  ConfigChange:
    PossibleNot:
      Form:
        - ticketCreateQuickClose
    PossibleAdd:
      Form:
        - ticketCreateNotifyOwner
    Action:
      Queue: "Alarm"

Podstawowe ustawienia Podstawowe dane ACL i ustawienie Match

Ustawienia Action Zmiana ACL: zmiana kolejki i dodanie przycisku

2. Ochrona przed eskalacją dla biletów o priorytecie "bardzo wysoki"

Cel: Zapobiec zamykaniu biletów z priorytetem bazy danych 5.

yaml

- Name: "101-No-Close-High"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    PropertiesDatabase:
      Priority:
        Name: [ "5" ]
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketClose

Ochrona przed eskalacją Zmiana ACL: ukryj przycisk Close

3. Ograniczenie interfejsu użytkownika na kolejkę

Cel: W kolejce Support status rozwiązany nie powinien być dostępny.

yaml

- Name: "102-Hide-Resolved-Support"
  ValidID: 1
  ConfigMatch:
    Properties:
      Queue:
        Name: [ "Support" ]
  ConfigChange:
    PossibleNot:
      FormStd:
        - State::resolved

Usuń status Zmiana ACL: usuń opcję statusu

4. Ograniczenie procesu klienta

Cel: Klienci nie mogą przenosić własnych biletów do innych kolejek.

yaml

- Name: "103-Cust-No-Reassign"
  ValidID: 1
  ConfigMatch:
    Properties:
      Frontend:
        Action:
          - CustomerTicketZoomReply
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketMove

Ogranicz proces klienta Zmiana ACL: ukryj przycisk Move dla klienta

5. Eskalacja czasowa po 48 godzinach

Cel: Bilety otwarte dłużej niż 48 godzin są automatycznie przypisywane do starszych agentów.

yaml

- Name: "104-Escalate-48h"
  ValidID: 1
  ConfigMatch:
    Properties:
      Ticket:
        CreateTimeOlderThan: 48h
  ConfigChange:
    Action:
      Owner: "Senior-Agenten"

Uwaga: Ten scenariusz może wymagać rozszerzenia o kryteria dopasowania oparte na czasie.

Zarządzanie i dokumentacja

Działanie	Opis
Konwencja nazewnictwa	Prefiksy numeryczne (np. `100-`, `200-`) dla sortowania i przejrzystości.
Changelog	Rejestruj `Name`, `Comment`, `ChangeTime` i `ChangeBy` dla każdej zmiany ACL.
Proces przeglądu	Przeprowadzaj regularne przeglądy, aby unikać nakładania się i konfliktów.
Wersjonowanie	Eksportuj ACL jako YAML i wersjonuj w Git lub narzędziu do dokumentacji.
Testowanie	Weryfikuj ACL w środowisku testowym za pomocą specyficznych biletów testowych.

Dalsze referencje

Referencja ACL (YAML): Kernel/Config/Files/ZZZACL.pm (generowane)
Klucze SysConfig ACL: Terminy poziomu 1-3 do precyzyjnej kontroli (Core::Ticket::ACL)
Dokumentacja DynamicField: Integracja pól dynamicznych w ACL

Dzięki tym praktycznym przykładom i zaleceniom dotyczącym zarządzania będziesz teraz wyposażony w narzędzia do bezpiecznego, wydajnego i przejrzystego działania ACL w OTOBO.

OTOBO Znuny ACL ​

1. Koncepcje i wartość biznesowa ​

1.1 ACL oparte na rolach i kryteriach ​

2. Przegląd architektury ​

3. Podstawowa struktura ACL: Match vs. Action ​

4. Ważne ustawienia SysConfig ​

Ocena, Stop-on-Match i wydajność ​

Cykl oceny ​

Strategie Stop-on-Match ​

Optymalizacja wydajności ​

Konserwacja i najlepsze praktyki ​

Konfiguracja debugowania ​

Przykłady praktyczne, zarządzanie i referencje ​

Przykłady praktyczne ​

1. Automatyczna priorytetyzacja do kolejki "Alarm" ​

2. Ochrona przed eskalacją dla biletów o priorytecie "bardzo wysoki" ​

3. Ograniczenie interfejsu użytkownika na kolejkę ​

4. Ograniczenie procesu klienta ​

5. Eskalacja czasowa po 48 godzinach ​

Zarządzanie i dokumentacja ​

Dalsze referencje ​

OTOBO Znuny ACL

1. Koncepcje i wartość biznesowa

1.1 ACL oparte na rolach i kryteriach

2. Przegląd architektury

3. Podstawowa struktura ACL: Match vs. Action

4. Ważne ustawienia SysConfig

Ocena, Stop-on-Match i wydajność

Cykl oceny

Strategie Stop-on-Match

Optymalizacja wydajności

Konserwacja i najlepsze praktyki

Konfiguracja debugowania

Przykłady praktyczne, zarządzanie i referencje

Przykłady praktyczne

1. Automatyczna priorytetyzacja do kolejki "Alarm"

2. Ochrona przed eskalacją dla biletów o priorytecie "bardzo wysoki"

3. Ograniczenie interfejsu użytkownika na kolejkę

4. Ograniczenie procesu klienta

5. Eskalacja czasowa po 48 godzinach

Zarządzanie i dokumentacja

Dalsze referencje