Benutzerverwaltung
Allgemeine Hinweise zur Benutzerverwaltung 
In einem Warenwirtschaftssystem, EPR- CRM- System werden diverse sensible Daten gespeichert. Diese Daten sollen meistens nur teilweise den Mitarbeiter zur Verfügung gestellt werden. Aus diesem Grund werden die Daten zur Ansicht oder zur Bearbeitung meistens auf Gruppenebene freigegeben. In iDempiere werden diese Freigabeebenen bzw. Gruppenebenen Rollen genannt.
Rolle steuert die Zugriffsrechte
Eine Rolle steuert die Zugriffsrechte auf Informationen und Zugriffe innerhalb von iDempiere.
In iDempiere sind vier grundlegende Rollentypen vorgesehen:
- Super User
- System Administrator
- Administrator......(auf Mandantenebene)
- Anwender / User.(auf Mandantenebene)
Folgende Nutzer (User) sind in der GardenWorld angelegt:
- SuperUser
Der SuperUser kann jede Rolle und Login einnehmen. Dies entspricht etwa dem ROOT auf einem Linux System. Es sollten möglichst wenige Personen mit Super User Rechten (Rollen) versehen werden. Der SuperUser arbeitet üblicherweise in der EDV-Abteilung. - System
Die Anmeldung als System ermöglicht die Änderung der Systemweiten Konfiguration, die Änderung und Anlage von Tabellen und Fenstern.Der System-Administrator legt üblicherweise Systemparameter fest und legt weitere Benutzer bzw. deren Rollen (Rechte) an.
Die Rechte des System-Administrators können nicht geändert werden. - GardenAdmin
Der GardenAdmin kann die Rolle der Verwaltung (Admin) oder die Rolle des Mitarbeiters (User) übernehmen.
In der Verwaltungsrolle (Admin) kann der GardenAdmin grundlegende Tabellen und Kategorien bearbeiten. Zusätzlich ist die Pflege und Erzeugung von Dokumenten und Fenster für den Mitarbeiter (User) möglich. - GardenUser
Der GardenUser kann nur die Rolle des Mitarbeiters (User) übernehmen.
Es ist dem GardenUser nicht gestattet Konfigurationstabellenzu verändern. Datensätze bearbeiten und hinzufügen ist jedoch eine der Hauptaufgaben des GardenUser.
In der Beispielfirma "GardenWorld" werden alle vier Anwender und die grundlegenden Rollen angewendet.
In iDempiere wird bereits bei der Anmeldung der Mandant, die Rolle, die Organisation und das Lager vorbelegt.
Je nach Benutzer sind nur bestimmte Kombinationen möglich.
Beispiele für dem Umgang mit Benutzereinstellungen
einfachste Methode - Zugriff für alle
Wenn ich wenige (oder nur einen) Benutzer habe und sich jeder mit dem Programm auskennt, kann jeder Benutzer der bei der Mandanteneinrichtung erzeugten Admin-Rolle zugewiesen werden. Wer möchte, kann dies auch ebenso mit der User-Rolle machen, so das die Benutzer noch etwas Auswahl haben. Mit der User-Rolle kann man eigentlich auf alle wichtigen Programmteile ohne grosse Einschränkungen zugreifen. Dafür gibt es dann ntürlich auch keine besondere Sicherheit an dieser Stelle.
einfache Methode - Menübaum anpassen
Manche mögen an der vorgenannten Methode nicht, das der angezeigte Menübaum sehr unübersichtlich ist und den Anwender mehr abschreckt als ihm seine Möglichkeiten aufzuzeigen. Um das zu ändern, kann man einen eigenen, neuen Menübaum definieren und jedem Benutzer einen eigenen Baum zuordnen. Diese Methode ist relativ einfach und komfortabel. Man sollte allerdings wissen, das sie eigentlich keinerlei Zugriffskontrolle bedeutet. Man kann - z.B. über Zoom-Methoden - immer noch auf sehr viele Fenster zugreifen.
Siehe auch Customize a new tree for special role im ADempiere-Wiki.
nur freigeben, was man braucht
Zugriffsrechte dienen nicht nur der Sicherheit vor Mißbrauch - sie haben auch den ganz praktischen Vorteil, das man nur die Teile des Menübaums sieht, die man auch haben will. Insbesondere für die Implementation eines Kundensystems kann es auch reizvoll sein, das man einen neuen Benutzer zuerst "auf Null stellt" und dann jedes einzelne Fenster, jeden Prozeß, etc. freigibt. Auf diese Art und Weise hat man eine sehr feine Kontrolle, was der Benutzer später machen soll. Allerdings ist diese Methode recht mühselig: Bei Entwicklung und Test des Systems muss man quasi immer mit einem eingeschränkten Account vorlieb nehmen und jedes Mal, wenn man an eine Grenze stößt, in einem parallel laufenden Fenster die entsprechende Funktion freigeben. Es sei darauf hingewiesen, das iDempiere sehr viele einzelne Funktionen hat und auf jede einzeln Rechte vergeben kann.
Bei dieser Methode ist sichergestellt, das der Benutzer auch nicht aus einem anderen Fenster heraus ein eigentlich nicht freigegebenes Fenster oder einen Prozeß startet.
zusätzliche Sperren
Über das Fenster "Rolle Datenzugriff" kann man den Zugriff noch weiter ausdehnen (bis hin zur totalen Paranoia). Die hier konfigurierten Sperren arbeiten nicht mit den Fenstern und Menüpunkten, die man im Menübaum offensichtlich sieht, sondern sie wirken auf Tabellen-, Feld- und sogar auf Datensatzebene. Das bedeutet, das man die Anzeige von Informationen aus bestimmten Tabellen komplett verbieten oder einschränken kann. Wendet man diese Funktionen übrigens intensiv an, ergibt sich früher oder später auch ein gewisser PErformanceverlust, da ja viel mehr geprüft werden muss (nicht nur einmal beim öffnen eines Fensters, sondern bei jeder Änderung der Anzeige im Fenster).
Konfiguration mit Masterrollen
Masterrollen dienen dazu, Rollendefinitionen zusammenzufassen. Siehe auch Subrole Feature im ADempiere Wiki. Hierzu empfiehlt sich ein dreistufiges System:
Masterrollen
Masterrollen sind die unterste (atomare) Ebene. Sie gliedern die Funktionen des Programms in kleinste Einheiten von Rechten, die man eigentlich immer zusammen braucht. So braucht z.B. ein Mitarbeiter im Telefonverkauf das Recht, ein Bestellungsfenster anzusehen, Bestellungen als Beleg abzuschliessen und vielleicht einen Bericht seiner eigenen Bestellungen anzusehen. All dies fassen wir zusammen in einer Rolle telefonverkauf. (Meine Konvention ist, das ich dieses Wort mit Absicht klein schreibe, um Masterrollen von Benutzerrollen direkt zu unterscheiden.) Am besten gibt es eine basis-Masterrolle, die z.B. das Ändern des Passwortes und andere grundlegende Dinge erlaubt (Zeiterfassung des Mitarbeiters, Chat, etc.). Die höchsten Masterrollen können z.B. administration und geschäftsführung sein - dabei hat jede Rolle Ihren eigenen Bereich und greift keine Rechte von anderen Bereichen auf. Die Geschäftsführung darf also z.B. Finanzberichte ansehen, aber nicht das Bestellungsfenster öffnen und auch keine Belegarten ändern. Letzteres darf dann die Rolle administration.
Benutzerrollen
Benutzerrollen fassen nun die Masterrollen zusammen. Für die Liste der eingebundenen Rollen gibt es eine Reihenfolge (die Datensätze haben eine Zeilennummer). Dabei ist es wichtig, das die höherwertigen Rollen zuerst stehen (also "administration" bekommt 10, "telefonverkauf" erst 120). Dadurch ist es möglich, für ein und dasselbe Fenster in niedrigeren Ebenen nur Lesezugriff und in höheren dann auch Schreibrechte zu gewähren. Die Benutzerrollen sind bei mir per Konvention großgeschrieben. Es gibt also eine Rolle Geschäftsführung, die die Masterrollen geschäftsführung, telefonverkauf, buchhaltung, 'stammdaten', statistik, basis, etc. zusammenfasst. Es ist möglich, einen "Administrator" zu definieren, der zwar die Stammdaten pflegen, außergewöhnliche Tabellen wie Gruppeneinteilungen etc. ändern kann und verschiedene Aufräum- und Pflegeprozesse starten kann, der aber keinen Zugang zu Geschäftsdaten wie Transaktionen oder Buchhaltungsdaten hat.
Es bietet sich an, während der Implementierung eine Entwicklerrolle zu definieren, die sämtliche Masterrollen enthält. Der Entwickler kann sich damit zwingen, ausschließlich mit dieser Rolle zu arbeiten. Auf diese Art ist sichergestellt, das jedes Recht, das er im Laufe seiner Entwicklung und Tests benutzt, irgendwann mal einer der Masterrollen zugewiesen worden ist.
Wem es schwerfällt, in einem Betrieb abstrakte Rollennamen zu vergeben, kann hierfür auch die Namen der Benutzer verwenden. So kann man in kleineren, flexiblen Firmen oft nicht genau definieren, das Herr Schmidt immer nur "Einkauf" macht. Selbstverständlich geht er auch ans Telefon, wenn das klingelt und außerdem ist er der einzige, der mit dem Bankprogramm umgehen kann. Also fassen wir die Rollen basis, einkauf, telefonverkauf, zahlungsverkehr zusammen in einer Rolle "Schmidt". Wahlweise kann man ihm noch Zugriff auf andere Rollen wie "Telefonverkauf" (die sonst die Rezeptionistin benutzt) aber auch auf mächtigere Rollen wie "Stammdaten" geben. Er ist dann gezwungen, für bestimmte Tätigkeiten bewusst umzuschalten. Während der Stammdatenpflege kann er dann aber ggf. keinen Einkauf und keinen Telefonverkauf machen.
Benutzer
Benutzer können nun auf verschiedene Benutzerrollen eingestellt werden. Ein Benutzer kann auf diese Weise aussuchen, in welchem Arbeitsbereich und wie gefährlich er heute arbeiten will. Es ist guter Stil, die Mitarbeiter einerseits anzuhalten, mit einer niedrigschwelligen Rolle zu arbeiten, damit sie nichts "aus Versehen" verstellen können. Andererseits kann man ihnen dennoch Zugang zu einer Art Administratorzugeng geben, damit sie dann aktiv entscheiden können, jetzt eben doch z.B. Stammdaten zu ändern. Der bewusste Wechsel der Rolle sorgt (hoffentlich) dafür, das der Benutzer ein Gefühl für die Gefährlichkeit seines Tuns bekommt und entsprechende Sorgfalt walten lässt.
