Hilfe, ich kann keine Tickets sehen!

[mkarg]

Wir haben OTRS so eingestellt, dass jede Abteilung eine Gruppe ist, und dank der Zuordnungen Agent<-->Gruppe<-->Rolle die Mitarbeiter in der Folge je nach Abteilungszugehörigkeit unterschiedliche Rechte besitzt (z. B. alle Mitarbeiter in Abteilung A bieten First Level Support und können daher Tickets nur anlegen, alle Mitarbeiter in Abteilung B bieten Second Level Support und können daher Tickets auch bearbeiten und abschließen). Wir haben für Abteilung A (= Gruppe) eine Queue angelegt, in welcher diese Abteilung neue Tickets erfasst. Soweit so gut. Dummerweise kann man in OTRS aber an einer Queue nur EINE Gruppe hinterlegen, sodass momentan nur eine Abteilung die Tickets in dieser Gruppe sehen kann -- die anderen Abteilungen sehen diese aufgrund anderer Gruppenzugehörigkeit nicht, trotz "höherer" Rechte über deren zugeordnete Rolle.

Wie schaffen wir es, dass auch die Mitarbeiter aus den anderen Abteilungen (= Gruppen) die Tickets in der Queue sehen können?

...oder verstehen wir das Gruppenmodell falsch...?

[jojo]

Das Modell sieht so aus:


Agent -> Rolle

Gruppe 1
Rolle <
Gruppe 2


Gruppe - Queue

[mkarg]

Das Modell sieht so aus:


Agent -> Rolle

Gruppe 1
Rolle <
Gruppe 2


Gruppe - Queue

Wenn ich Dich richtig verstehe, müssen also alle Gruppen in der gleichen Rolle sein? Das widerspricht doch aber dem Rollenprinzip: Die einen sollen nur aufnehmen, die anderen nur abarbeiten?!

[mkarg]

Das Modell sieht so aus:


Agent -> Rolle

Gruppe 1
Rolle <
Gruppe 2


Gruppe - Queue

Wenn ich Dich richtig verstehe, müssen also alle Gruppen in der gleichen Rolle sein? Das widerspricht doch aber dem Rollenprinzip: Die einen sollen nur aufnehmen, die anderen nur abarbeiten?!

...oder habe ich da Modell von OTRS falsch verstanden? Ich dachte, Gruppen sind Abteilungen und Rollen sind Rechtemengen. Wodurch die Zuordnung von Gruppen zu Rollen doch eigentlich exakt das ermöglichen sollte, was ich vor habe... oder wo liegt mein Denkfehler?

[jojo]

Die Gruppe ist ein Berechtigungscontainer und repräsentiert z.B. eine Queue oder ein Oberflächenobjekt.

Eine Rolle ist die Menge von Berechtigungen auf Gruppen

[mkarg]

Die Gruppe ist ein Berechtigungscontainer und repräsentiert z.B. eine Queue oder ein Oberflächenobjekt. Eine Rolle ist die Menge von Berechtigungen auf Gruppen

Ich will und kann Dir da natürlich nicht widersprechen, aber Deine Aussage verwirrt mich total! Denn zum einen steht in der Gruppen-Verwaltung...

Erstellen Sie neue Gruppen, um unterschiedliche Berechtigungen für verschiedene Agentengruppen zu realisieren (z. B. Einkauf, Produktion, Verkauf, ...).

...(was klar Gruppen = Abteilungen identifiziert) und zum anderen stellt sich mir dann die Frage, wie man denn dann das von mir beschriebene Szenario (Agent arbeitet in Abteilung, Abteilung erfüllt Funktion, für Funktion werden Rechte benötigt) umsetzen können soll?

Wenn ich Dich richtig verstehe, muss ich also die Abteilungen als Rollen einrichten, die Funktionen kann ich gar nicht modellieren, und die Rollen bleiben zum Schluss sinnentleert übrig?

Totale Konfusion?!

[jojo]

Agent A bekommt z.B. Rolle 1 die ihm Zugriff einen bestimmten Zugriff auf Gruppen gibt:

rw auf Gruppe 1
ro, note, create auf Gruppe 2

Agent B hat Rolle 2 die ihm z.B. gibt:
ro, note auf Gruppe 1
rw auf Gruppe 2


Die Rolle ist die "Tätigkeitsbeschreibung", die Gruppe die Berechtigung. In kleinen Systemen (und das war bis zur 2.0 ausschliesslich so) vergibst Du direkt die Berechtigung auf die Gruppen für jeden Agent, in größeren über die Rolle

[mkarg]

Agent A bekommt z.B. Rolle 1 die ihm Zugriff einen bestimmten Zugriff auf Gruppen gibt:

rw auf Gruppe 1
ro, note, create auf Gruppe 2

Agent B hat Rolle 2 die ihm z.B. gibt:
ro, note auf Gruppe 1
rw auf Gruppe 2


Die Rolle ist die "Tätigkeitsbeschreibung", die Gruppe die Berechtigung. In kleinen Systemen (und das war bis zur 2.0 ausschliesslich so) vergibst Du direkt die Berechtigung auf die Gruppen für jeden Agent, in größeren über die Rolle

Das ist mir schon klar, aber wie kann ich denn dann modellieren, dass Tätigkeitsbeschreibungen an Abteilungen hängen und nicht an einzelnen Agents?

[jojo]

über die Rolle, die Rolle ist die Tätigkeitsbeschreibung.

Es werden keine direkten Berechtigungen Agent - Gruppe vergeben, wenn Du mit Rollen arbeitest

[mkarg]

über die Rolle, die Rolle ist die Tätigkeitsbeschreibung. Es werden keine direkten Berechtigungen Agent - Gruppe vergeben, wenn Du mit Rollen arbeitest

Du scheinst nicht zu verstehen wo mein Problem liegt: Ich habe "Abteilungen" als OTRS-Gruppen definiert und "Funktionen" als OTRS-Rollen, aber wie Du schreibst ist das falsch. Also wie kann ich sagen "Agent A arbeitet in Abteilung X und diese Abteilung darf Tickets nur öffnen; Agent B arbeitet in Abteilung Y und diese Abteilung darf Tickets editieren"? Soll ich also Deiner Meinung nach das ganze umdrehen ("Abteilungen" als Rollen modellieren und "Oraganisatorische Funktionen" als Gruppen)...?!

[jojo]

Die Gruppen sind reine Berechtigungscontainer: Gruppe = Queue

[mkarg]

Die Gruppen sind reine Berechtigungscontainer: Gruppe = Queue

Ja das habe ich inzwischen kapiert, aber meine Frage war ja zuletzt, wie bilde ich Abteilungen ab und wie bilde ich organisatorische Funktionen ab? Letztere können ja von mehreren Abteilungen ausgeführt werden und sind nicht zwingend eine 1:1-Beziehung in der echten Welt. Wenn ich Dich richtige verstehe, müssten wir Abteilungen als Rollen modellieren, und könnten somit die organisatorischen Funktionen gar nicht modellieren, oder wir müssten umgekehrt organisatorische Funktionen als Rollen modellieren und hätten dann keine Möglichkeit Mitarbeiter zu Abteilungen zuzuordnen... Erkennst Du unser Dilemma?

[jojo]

Abteilungen interessieren im OTRS nicht, nur die Tätigkeitsbeschreibung / Funktion

[mkarg]

Abteilungen interessieren im OTRS nicht, nur die Tätigkeitsbeschreibung / Funktion

Ja das habe ich nun schon kapiert dass OTRS die Abteilungen nicht interessieren, aber unsere Orga-Abteilung halt schon, weil die eben sagen "Jeder in dieser Abteilung hat diese Funktion" und nicht an zig Agents die ganzen Funktionen einzeln drankleben wollen.

[jojo]

die Funktion ist die Rolle, d.h. jeder Mitarbeiter der Abteilung bekommt die Rolle.

[mkarg]

die Funktion ist die Rolle, d.h. jeder Mitarbeiter der Abteilung bekommt die Rolle.

Ja das ist schon klar, hast Du ja bereits erläutert, aber in letzter Konsequenz heisst das, unsere Organisatoren müssen jedem Mitarbeiter die notwendigen Rollen einzeln zuordnen, weil OTRS halt keine Abteilungen kennt, richtig?

[jojo]

ja, oder (wenn LDAP zur Authentifizierung genutzt wird) macht man ein LDAP Gruppen zu OTRS Rollen Matching

[mkarg]

ja, oder (wenn LDAP zur Authentifizierung genutzt wird) macht man ein LDAP Gruppen zu OTRS Rollen Matching

Oh das hört sich gut an, denn exakt danach habe ich hier im Forum schonmal gefragt (wir benutzen sowieso LDAP-Auth für Agents), leider hat keine gewusst wo steht wie das geht... Hast Du zufällig einen Link zu einer Anleitung zu dem Thema?

[jojo]

Gehört zum AuthSyncModule und nennt sich AuthSyncModule::LDAP::UserSyncRolesDefinition (steht natürlich in der Defaults.pm)

[mkarg]

Gehört zum AuthSyncModule und nennt sich AuthSyncModule::LDAP::UserSyncRolesDefinition (steht natürlich in der Defaults.pm)

...aha... und vermutlich weiss jeder was das bedeutet nur ich mal wieder nicht...