Default Gruppen umbenennen?

[ferrosti]

Ich möchte die Standard Gruppen umbenennen. Leider ist das vor allem bei der "admin" Gruppe ziemlich dämlich. Eine Umbenennung nach "OTRS_Administratoren" zog unter anderem nach sich, dass die zugehörigen User keinen Zugriff mehr auf die Admin Funktionen haben.
Sind die Gruppennamen hart im Quelltext eincodiert? In der "groups" Tabelle wird nur über IDs gearbeitet. Deshalb verstehe ich nicht ganz, warum eine Umbenennung solche Auswirkungen aufweist.
Bei den anderen Standard Gruppen habe ich es noch nicht ausprobiert.

Für eine Lösung wäre ich euch dankbar!

[jojo]

Die Gruppen umzubenennen ist eigentlich Blödsinn, da sie nach aussen nicht auftauchen und rein OTRS intern benutzt werden.

In der SysConfig wird auf den Namen verwiesen

[ferrosti]

Tu es doch nicht gleich als Blödsinn ab, nur weil es sonst keiner macht...
Wenn es später viele verschiedene Admin Gruppen geben soll, dann macht eine deutlichere Benennung durchaus Sinn.
Ich werde mir das morgen auf der Arbeit nochmal anschauen und mal sehen, was ich da mit der SysConfig noch machen kann.

[jojo]

selbst dann macht es keinen Sinn, die admin Gruppe umzubenennen.

Weitere Hinzufügen und zu Teiladmins zu machen ist ja durchaus ein gängiger Weg. Aber die Dafault Gruppe admin, stats, ggf. faq und faq_admin sollten nicht geändert werden, da man sich damit nur unnötig Arbeit macht und sich dadurch auch Konfigurationsfehler einschleichen können.

[ferrosti]

Vielleicht müsste ich das dann über Rollen lösen, k.A. Da gibt das Handbuch leider nicht so viel her.
Mein "Problem" ist, dass ich verschiedene Admin Gruppen anlegen möchte. Diese sind unter anderem für Großrechner, Windows, Linux etc. Damit möchte ich später eine genauere Aufgaben- und Kompetenzteilung innerhalb des Systems erreichen. Für die Entwickler soll dann das selbe in Grün erfolgen.

Vielleicht hast Du da ja eine bessere Idee.

Dein Vorschlag ist für die Verwendeung der Gruppen rein auf OTRS durchaus angebracht. Für die Übersichtlichkeit in meinem Szenarioo hätte ich in den Gruppen lieber eine einheitliche Namensgebung, z.B.:
- Admin_OTRS
- Admin_Windows
- Admin_Linux
- Admin_pSeries

Vielleicht liegt mein Denkfehler ja auch ganz wo anders...

[Andre Bauer]

Das bringt sowieso nicht viel, da ein Admin z.B. immer auch die Textbausteine der anderen Admins ändern oder löschen kann.
Richtig abgrenzen kannst Du das also nicht.

[ferrosti]

Ich glaube wir reden immer noch aneinander vorbei...
Die von mir genannten Admin Gruppen sollen alle 2nd bis 3rd Level Support machen und im OTRS gar nicht herumpfuschen und dort auch keine Admin Funktionen bekommen.
Ich glaube dafür eigenen sich Rollen dann doch besser als Gruppen... aber ich bin ja immer noch am einlesen und einarbeiten. Hört das eigentlich irgendwann auf?

[jojo]

Empfohlenen Vorgehensweise:

- Gruppen für die Berechtigungen auf Queues (und ggf. Module) anlegen
- Berechtigungsmatrix für verschiedene Usergruppen erstellen
- Rollen erstellen
- Berechtigungsmatrix über die Rollen - Gruppen Zuordnung abbilden
- Rollen den Agenten zuweisen
- Zuweisung Agent-Gruppe leer lassen

[A_W]

Meines Befindens nach gibt es da einige solcher Schwachstellen im DB Design,
wo statt verfügbarer primary keys Referenzen durch descriptive Textfelder
gemacht werden.

Ärgerlich ist das z.B. bei Customer_ID, die als Textfeld nicht etwa eine
menschliche Person, sondern eine company meint. OK, das muss man
sich also merken, treffender wäre Company_ID gewesen.

Aber zurück zu Customer_ID; eine einmal gewählte ID und in den
Masken (leider auch) später änderbare ID hat trennende Wirkungen, die
so sicher eben nicht beabsichtigt sind.
Diese Technik der Verlinkung empfinde ich als krank.

Siehe auch http://otrs-forum.de/viewtopic.php?f=25&t=1512
und http://bugs.otrs.org/show_bug.cgi?id=2376

Andreas.