Berechtigungskonzept

Einführung

Aus der CURSOR-CRM Architektur ergeben sich verschiedene sicherheitsrelevante Aspekte:

• Die Geschäftsdaten liegen geschützt auf einem Datenbank-Server und sind im Regelfall nur über den Applikationsserver zugänglich. Lediglich ein (die Datenbank-Passwörter kennender) Datenbank-Administrator hätte die Möglichkeit, auch über einen SQL-Editor auf die Daten zuzugreifen.

• Dasselbe gilt auch für die in der Anwendung integrierten Anwendungsdokumente (z. B. Einzelbriefdokumente), so dass auch hier diese Dokumentdateien nicht über Netzwerkfreigaben sondern nur im Kontext der Applikation und damit unter Berücksichtigung des Berechtigungskonzeptes zugänglich sind.

• Zugriffsmöglichkeiten des Clients auf den zentralen Applikationsserver können über eine Firewall restriktiv konfiguriert werden. Die für den Applikationsserver hierzu frei zu schaltenden Ports werden im Rahmen der üblichen Installationsaktivitäten abgestimmt.

• Die Datenübertragung in einem internen Netzwerk wird über SSL-Zertifikate verschlüsselt. SSL-Zertifikate gibt es bspw. nicht nur für Mails oder Makros, sondern insbesondere auch für Applikations-/Webserver, wodurch der im Umfeld der CRM-Applikation stattfindende Datentransfer verschlüsselt wird.

• Auch bei einem Zugriff von außen (z. B. über Terminal-Server) besteht bspw. über VPN die Möglichkeit, den Datentransfer auch über das Internet zu tunneln und damit vor nicht authentifizierten Nutzern zu schützen.

• Für das Arbeiten mit der CRM-Applikation ist eine vorherige Authentifizierung am System erforderlich. Innerhalb der Applikation definierte Passwörter werden nur gemäß konfigurierbarer Richtlinien akzeptiert sowie darüber hinaus verschlüsselt innerhalb der Datenbank abgelegt.

• Das CURSOR-CRM besitzt eine eigene Benutzerverwaltung, mit der Möglichkeit der Vergabe unterschiedlicher Systemrechte für einzelne Benutzergruppen.

Der Zugriff auf Datensätze, Felder und einzelne Funktionen (wie z.B. Neuanlage, Löschen, Zuordnen von Datensätzen) wird in CURSOR-CRM über Berechtigungen geregelt. Um z.B. einen Datensatz lesen oder bearbeiten zu können, müssen Sie die entsprechenden Berechtigungen besitzen. Bis auf einige Ausnahmen (z.B. Zugriff auf Mitarbeiterdaten, administrative Funktionen) hat jeder Anwender grundsätzlich alle Rechte. Sie können diese Rechte entsprechend Ihren Anforderungen einschränken.

Wo Datensatz- und Feldrechte aufeinandertreffen, setzt sich das Recht mit der stärkeren Einschränkung durch. Darf ein Anwender beispielsweise ein Feld nicht lesen, bekommt er den Inhalt des Feldes auch dann nicht angezeigt, wenn er für den Datensatz Lese-Rechte hätte. Andererseits, hätte er bei diesem Datensatz nur ein 'Leserecht', so dürfte er das Feld auch dann nur lesen, auch wenn er bei diesem Feld das Feldrecht 'Bearbeiten' hätte.

Über Aktionsrechte können z.B. die Schaltflächen Neuanlage und Löschen sowie die Verknüpfung im Baum aktiviert bzw. deaktiviert werden.

Die folgende Abbildung soll veranschaulichen, wie sich Datensatz- und Feldzugriffsrechte beeinflussen. 

Berechtigungen können nicht nur für Datensätze und Funktionen, sondern auch für Suchen und Auswertungen verwendet werden. Die Berechtigungen werden anhand von Benutzergruppen und Rechtevorlagen abgebildet.

• Benutzergruppen bündeln Mitarbeiter

• Rechtevorlagen bündeln Gruppen

Beim Systemrecht SYS handelt sich hierbei um einen Typ, der vom Kunden nicht genutzt werden kann. Er ist systemintern und wird für das Feature Additive Standardrechte genutzt.

Benutzergruppen

Berechtigungen werden über Benutzergruppen vergeben. Dazu ist jeder Anwender mindestens einer Benutzergruppe zugeordnet. Neue Benutzergruppen legen Sie unter Administration / Gruppe an. Hier können Sie auch Benutzergruppen löschen oder sehen die der jeweiligen Benutzergruppe zugeordneten Mitarbeiter (im Baum).

In CURSOR-CRM/EVI sind im Lieferzustand folgende Berechtigungsgruppen vorgegeben:

In der Tabelle Bitright gibt es 130 Felder pro Recht, so dass die Gesamtanzahl der möglichen Rechtegruppen 10080 beträgt. Die gültigen Werte im Feld Bitright.Groups sind 0 bis 10079.

Konfigurationsgruppen

Mit Konfigurationsgruppen steuert man das Verhalten von Systemelementen. Hiermit kann die Darstellung einzelner Systemelemente für verschiedene Anwenderkreise beeinflusst werden. Die Konfigurationsgruppen finden Verwendung innerhalb der administrativen Bereiche Maskenkonfiguration, Feldeigenschaften, Masken und Suchen. Jedem Mitarbeiter-Datensatz wird bei der Neuanlage eine Konfigurationsgruppe zugewiesen, die beim Starten der Anwendung geprüft wird und die hinterlegte Konfiguration lädt. Die Maskenkonfiguration wird nun so konfiguriert, dass für einen definierten Anwenderkreis bestimmte Entitäten, Menü-Einträge oder Laschen im Unterfenster nicht zur Verfügung stehen. Ein klarer Nutzen dieser Optionen ist, dass je Anwenderkreis die Übersicht auf das jeweilige Tätigkeitsfeld innerhalb des CRM-Systems verbessert wird.

Die Benutzergruppen werden in Konfigurationsgruppen gekapselt.

Mitarbeiter

Im Hauptfenster Mitarbeiter (Lasche 'Konfiguration') ist jedem Mitarbeiter eine Benutzergruppe zugeordnet. Sie stellt die Hauptbenutzergruppe dar. Weitere Benutzergruppen können Sie einem Mitarbeiter über den Baum zuordnen.

Legt der Mitarbeiter einen neuen rechtebehafteten Datensatz an, wird dieser automatisch mit Zugriffsrechten belegt. Sofern nichts Anderes im Feld 'Rechtevorlage' eingetragen ist, wird dafür das DefaultTemplate verwendet. Soll nicht das DefaultTemplate verwendet werden, tragen Sie in das Feld 'Rechtevorlage' die gewünschte Vorlage ein.

Achten Sie darauf, dass Sie den Mitarbeitern Rechtevorlagen zuweisen, welche ihnen das Bearbeiten eines neu angelegten Datensatzes erlaubt. Andernfalls kann der Mitarbeiter nach dem Speichern den neuen Datensatz nicht mehr bearbeiten.

Rechte

Folgende Rechte können Gruppen erteilt werden:

Rechtevorlagen

Zur einfacheren Handhabung legen Sie Rechtevorlagen an, in welchen für die einzelnen Benutzergruppen Rechte definiert werden. Um später bei einem Datensatz oder Feld die Zugriffsrechte einzustellen, müssen Sie oder der Anwender dies nicht mehr jedes Mal für jede Benutzergruppe einzeln tun. Es reicht die Auswahl der passenden Vorlage. Passt in Einzelfällen keine Vorlage, wählen Sie eine Vorlage, welche mit Ihren Anforderungen weitestgehend übereinstimmt und passen diese an. Durch die Verwendung von Rechtevorlagen kann die Handhabung von rechtebehafteten Entitäten vereinfacht und die Performance der Anwendung verbessert werden.

Ein weiterer Vorteil der Rechtevorlagen ist die leichtere Verwaltung bei einer Umstrukturierung. Wurden Rechtevorlagen konsequent verwendet, so kann durch das Ändern der Berechtigungen der Vorlage direkt Einfluss auf die Berechtigungen der entsprechenden Daten genommen werden.

Es können nur Vorlagen ausgewählt werden, für die man selbst auch das Recht Rechte bearbeiten hat.

Tipp

Wenn eine bestimmte Kombination von Rechten öfter benötigt wird, sollten Sie dafür eine Vorlage erstellen.

Sie dürfen das DefaultTemplate ändern und ergänzen, aber NICHT löschen. Das DefaultTemplate wird u.a. verwendet, wenn bei einem Mitarbeiter keine andere Rechtevorlage (Hauptfenster Mitarbeiter) für die Neuanlage von Datensätzen eingetragen ist.

So legen Sie Rechtevorlagen an:

1. Wählen Sie im Hauptmenü Administration / Rechtevorlagen

2. Klicken Sie auf 

Neu

3. Tragen Sie eine selbsterklärende Bezeichnung für die Vorlage ein, welche später im Menü zum Schalter und auf der Seite Vorlagen der Rechteverwaltung angezeigt wird. Die Beschreibung kann z.B. Informationen über die vergebenen Rechte enthalten.

4. Stellen Sie ein, ob es ein Feldrecht (Haken) oder ein Datensatzrecht (kein Haken) sein soll.

5. Speichern Sie den neuen Datensatz.

6. Klicken Sie auf (Schalterleiste des Hauptfensters)

7. Definieren Sie in der Rechteverwaltung die Rechte für die einzelnen Benutzergruppen.

Rechteverwaltung

In der Rechteverwaltung zu einem Datensatz oder Feld können Sie nachlesen, welche Berechtigungen zu der ausgewählten Vorlage eingestellt sind und welche Einstellungen die übrigen Rechtevorlagen haben. Sie können eine andere Rechtevorlage auswählen oder die Einstellungen zu einer Vorlage für diesen Datensatz bzw. dieses Feld ändern.

Beispiel:

Über das Symbol

 können in den Aktivitäten und Dokumenten die Rechte auf Datensatzebene eingestellt werden.

Feldrechte können über die Feldeigenschaften gesetzt werden.

Auf der Lasche 'Vorlagen' sind die Rechtevorlagen aufgelistet bzw. die Vorlage kann dem aktuellen Datensatz oder Feld zugewiesen werden. Die aktive Vorlage ist markiert. Auf der Lasche 'Erweitert' werden Ihnen die dazugehörigen Einstellungen angezeigt.

Zu der markierten Gruppe werden die Einstellungen zu den Rechten angezeigt. Mit den Schaltern

 und 

können Sie Benutzergruppen zur Vorlage hinzufügen oder entfernen. Mit OK bestätigen Sie Ihre Einstellungen und verlassen die Rechteverwaltung.

Über den Dialog Rechteverwaltung können den einzelnen Gruppen Lese-, Schreib- und Managerechte zugeordnet werden. Managerechte und Schreibrechte setzen das Leserecht mit. Das letzte Managerecht kann nicht entzogen werden. Rechte auf Neuanlage, Löschen und Verknüpfen von Daten kann von der CURSOR Software AG in CURSOR-CRM/EVI eingestellt werden. Bei Feldrechten sind per Default Schreibzugriffe für alle Gruppen erlaubt. Die Satzrechte schränken die Feldrechte ein und umgekehrt (es gilt immer nur das niedrigere Recht).

Manuelle Berechtigungsvergabe

Die Konfiguration der Berechtigungen erfolgt im Standard über den vorhandenen Berechtigungsdialog. Die Darstellung der Gruppen inkl. der zugehörigen Berechtigungen wird als Tabelle angezeigt. Dadurch sind zum einen mehr Informationen auf einmal ersichtlich und zum anderen können Sie in der Tabelle die bekannten Funktionalitäten zum Sortieren und Einschränken (über den Spaltenfilter) nutzen.

Eine Systemeinstellung eingeführt kann konfiguriert werden, welche Lasche beim Öffnen des Dialogs angezeigt wird. Diese Einstellung kann folgende Werte haben:

• Nach Rechtekonfiguration: Abhängig von der aktuellen Rechtekonfiguration (Vorlage oder Gruppen-basiert) wird die erste oder zweite Lasche angezeigt.

• Vorlagen: Es wird immer die Lasche Vorlagen angezeigt.

• Erweitert: Es wird beim Öffnen immer die Lasche Erweitert angezeigt.

Im Auslieferungszustand steht diese Systemeinstellung auf 'Erweitert'.

Ändern von Berechtigungen

In der Tabelle können markierte Zeilen über den Schalter

Gruppe entfernen

 entfernt werden. Damit wird Mitgliedern dieser Gruppe die Leseberechtigung für diesen Satz entzogen. Eine dedizierte Rechtevergabe pro Gruppe (oder DOE) ist über die Häkchen in den jeweiligen Spalten möglich.

Unveränderliche Berechtigungen

Es sollen Berechtigungen konfiguriert werden, welche durch keinen Standardnutzer entfernt werden können:

• Alle lesen

• Techn. Admin schreiben

• Fachl. Admin vertrauliche Felder auswerten

Dafür wird im Auslieferungszustand eine spezielle Rechtevorlage bereitgestellt. Die über diese Rechtevorlage konfigurierten Berechtigungen werden bei manuellen Änderungen an den Berechtigungen immer additiv mitgespeichert. Es gelten dabei die auf der Rechtevorlage konfigurierten Berechtigungen zum Zeitpunkt des Speicherns, d. h. nachträgliche Änderungen an der speziellen Rechtevorlage werden nicht nachgezogen, sondern gelten erst beim nächsten Speichern.

Der Anwender kann die Rechte im Berechtigungsdialog vollständig verändern, insbesondere kann er auch die Gruppe Alle lesen entfernen. Beim Speichern der Berechtigungen werden jedoch die im "Mastertemplate" definierten Berechtigungen additiv hinzugefügt. Damit wird sichergestellt, dass die Berechtigung Alle lesen durch den Benutzer nicht entfernt werden kann.

Dieser Mechanismus gilt nur, wenn der Anwender die Berechtigungen auf Gruppenebene bearbeitet (Lasche Erweitert im Berechtigungsdialog). Ändert er die Berechtigungen durch die Auswahl einer Rechtevorlage (1. Lasche im Berechtigungsdialog), greift dieser Automatismus explizit nicht, da die Rechtevorlagen nur durch Administratoren gepflegt werden können und diese daher die Verantwortung für die ordnungsgemäße Konfiguration sicherstellen müssen.

Hinzufügen von Berechtigungen

Über den Schalter 

können weitere Gruppen (oder bei HelVIS DOE’s) auf den aktuellen Datensatz berechtigt werden. Der Ablauf zum Hinzufügen ist dabei wie folgt:

1. Klicken des Buttons zum Hinzufügen

2. Es öffnet sich ein Suchfenster zur Ermittlung der hinzuzufügenden Gruppen. Dieses Suchfenster ist bzgl. der Bedienung und des Aufbaus identisch zu allen anderen Suchfenstern. Die Suche kann dabei sowohl nach der DOE-Nummer als auch nach einzelnen Mitarbeitern (z. B. über den Nachnamen) erfolgen.
   Nach dem Auslösen der Suche werden die den Suchkriterien entsprechenden Gruppen als Liste angezeigt.
   Anmerkung:
   Es öffnet sich das Suchfenster auf den Gruppen mit der Standardsuche für die Entität Gruppen.

3. Nach der Auswahl einer Gruppe aus der Ergebnisliste mit Doppelklick öffnet sich der Zuordnungsbrowser. Dieser zeigt auf der rechten Seite die bereits zugeordneten Gruppen an (inkl. der eben ausgewählten Gruppe). Auf der linken Seite sind die übrigen Gruppen aus dem Suchergebnis aufgeführt, sofern diese nicht sowieso schon berechtigt sind.
   Auch dieser Dialog ist ein Standardelement und wird u. a. beim Hinzufügen von Ansprechpartnern zu einer Aktivität verwendet.

4. Nach der Bestätigung des Dialogs werden die Änderungen im Berechtigungsdialog angezeigt, d. h. neu hinzugefügte Gruppen sind in der tabellarischen Ansicht vorhanden, entfernte Gruppen dementsprechend nicht mehr.

5. Nach dem Schließen des Berechtigungsdialogs sind die Änderungen wirksam.

Neu hinzugefügte Gruppen erhalten Standardberechtigungen (z. B. nur Lesen, aber nicht Schreiben). Die Einstellung dieser Standardberechtigung geschieht durch den Administrator auf Datenbankebene. Da eine Änderung dieser Standardberechtigung sehr selten erfolgen wird, wird dies als ausreichend angesehen.

Zusammenfassung:

• Die Umstellung auf eine tabellarische Darstellung der Gruppen und ihrer Berechtigungen erhöht die Übersichtlichkeit und erleichtert die Bedienung.

• Der HelVIS-Nutzer kann beim Hinzufügen von Gruppen sowohl über DOE-Bezeichnungen als auch über konkrete Mitarbeiter (über deren Namen) suchen.

• Durch die Wiederverwendung von bereits bekannten Elementen (Suchfenster, Zuordnungsbrowser) wird die Einarbeitungszeit minimiert.

• Die Vergabe von Standardberechtigungen für neu hinzugefügte Gruppen minimiert den Aufwand.

Bearbeitung von Berechtigungen in der Listenansicht

Sie haben folgende Aufrufmöglichkeiten für den Berechtigungsdialog aus Listenansichten heraus:

• Schalter im Hauptfenster

• Schalter in der Toolbar des Unterbereichs (z. B. Aktivitäten zu einem Geschäftspartner)

• Im Kontextmenü eines Unterbereichs

Die Vergabe der Rechte kann auch für mehrere Sätze in einem Schritt vergeben werden. Dies betrifft die Rechtevergabe in den folgenden Bereichen:

1. Feldrechte im Bereich Feldeigenschaften der Administratorkonsole

2. Aktionsrechte im Menü 'Administration/Rechtebehaftete Aktionen konfigurieren'

3. Datensatzrechte in der Listenansicht des Hauptfensters oder des Unterbereichs

Wird der Berechtigungsdialog aus einer Listenansicht heraus aufgerufen, wird standardmäßig die erste Lasche des Dialogs angezeigt, auf welchem die verfügbaren Rechtevorlagen aufgelistet sind. Im Gegensatz zum Öffnen des Berechtigungsdialogs aus einem einzelnen Datensatz heraus, bei dem entsprechend der aktuell für diesen Datensatz konfigurierten Berechtigungen auf die erste Lasche (Rechtevorlage ist aktiv) oder auf die zweite Lasche (manuelle Berechtigungen) gewechselt wird, ist bei der Bearbeitung von mehreren Sätzen nicht ersichtlich, wie deren aktuelle Berechtigungskonfiguration ist.

Das hier beschriebene Verhalten gilt nur, wenn in der Listenansicht mindestens 2 Datensätze markiert sind. Ist nur genau ein Datensatz markiert, entspricht das Verhalten dem Öffnen des Berechtigungsdialogs aus der Detailansicht heraus, d. h. es wird die aktuelle Konfiguration des Datensatzes angezeigt.

Ist der Dialog geöffnet, kann der Anwender wie gewohnt die Berechtigungen konfigurieren, indem er eine Rechtevorlage auswählt oder einzelne Gruppen explizit berechtigt (Lasche Erweitert). Wird der Dialog mit Ok geschlossen, wird die soeben erstellte Berechtigungskonfiguration für alle markierten Sätze in der Listenansicht angewendet.

Um zu verhindern, dass Änderungen an mehreren Datensätzen in der Listenansicht "aus Versehen" durchgeführt werden, wird die Verfügbarkeit des Schalters zum Aufruf des Berechtigungsdialogs über ein Aktionsrecht Berechtigungsdialog in Listenansicht konfigurierbar gemacht. Damit kann auf Gruppenebene definiert werden, für welche Anwender diese Funktionalität verfügbar ist. Aus dem gleichen Grund ist in Listenansichten das Dropdownmenü des Schalters, mit dem direkt eine Rechtevorlage ausgewählt werden kann, nicht verfügbar. Damit soll erreicht werden, dass der Anwender in Listenansichten immer den Weg über den Berechtigungsdialog gehen muss, um versehentliche Änderungen zu verhindern. Grundsätzlich gilt weiterhin, dass der Schalter prinzipiell nur verfügbar ist (sowohl in Detail- als auch in der Listenansicht und im Unterbereich), wenn für die jeweils angezeigte Entität die Berechtigungsprüfung aktiviert ist.

Im Auslieferungszustand ist dieses Aktionsrecht aktiviert, d. h. der Schalter zum Öffnen des Berechtigungsdialogs ist in Listenansichten (Hauptfensterliste und Unterbereich) verfügbar. Diese Konfiguration kann bei Bedarf durch den Administrator geändert werden.

Bei der Mehrfachmarkierung in Listenansichten kann der Fall auftreten, dass der Benutzer nicht für alle markierten Sätze das Recht hat, die Berechtigungen zu verändern. In diesem Fall wird der Anwender über einen Dialog über diesen Umstand informiert. In diesem Dialog sind alle in der Listenansicht markierten Sätze aufgeführt. Die Sätze ohne das Recht, die Berechtigungen zu verändern, sind rot hinterlegt. In diesem Dialog hat der Anwender die Möglichkeit, die Option Berechtigungen ändern zu wählen. Danach öffnet sich der Berechtigungsdialog und es werden nur die Berechtigungen für die Sätze geändert, für welche der Anwender das notwendige Manage-Recht besitzt (d. h. alle nicht rot hinterlegten Sätze). Mit der Option Abbrechen schließt sich dieser Dialog und es erfolgt keine weitere Aktion.

Schreibgeschützte Ansicht der Berechtigungen

Um sich einen Überblick der aktuell vergebenen Berechtigungen verschaffen zu können, soll es ermöglicht werden, den Berechtigungsdialog schreibgeschützt anzuzeigen. Dafür werden folgende Erweiterungen im Standard vorgenommen:

• Der Schalter zum Öffnen des Berechtigungsdialogs ist immer verfügbar, wenn für die entsprechende Entität die Berechtigungsprüfung aktiviert ist.

• Hat der aktuelle Anwender nicht die Berechtigung, die Rechte für den aktuellen Datensatz zu verändern (Manage-Recht), öffnet sich der Berechtigungsdialog schreibgeschützt, d. h. die Liste mit der Darstellung der aktuellen Berechtigungen ist schreibgeschützt und die Buttons zum Hinzufügen und Entfernen von Berechtigungsgruppen sind nicht auswählbar.

Besitzt der Anwender das Manage-Recht für den aktuellen Datensatz, kann er im Berechtigungsdialog die Berechtigung wie gehabt verändern.

Feldrechte

Über das Kontextmenü (Rechtsklick) auf jedem Feld einer jeden Entität können die Rechte auf Felder eingestellt werden. Hierzu muss der Menüpunkt Feldeigenschaften bearbeiten gewählt werden. Über die Schaltfläche

Berechtigungen

wird die Rechteverwaltung geöffnet. Alternativ kann die Einstellung auch über die Feldeigenschaften in der Administratorkonsole eingestellt werden. Administratoren erhalten mit dem Recht Rechte bearbeiten die Berechtigung, Feldrechte in den Feldeigenschaften ändern zu dürfen.

Feldrechte steuern den Zugriff für Benutzergruppen auf ein Feld. Feldrechte können über die Rechteverwaltung (Lasche Vorlagen) eine Rechtevorlage zugewiesen bekommen. Bei diesen Vorlagen muss dann das Attribut "Feldrecht" aktiviert sein. Alternativ kann man auch über die Lasche Erweitert den einzelnen Gruppen direkt die Rechte zugewiesen.

Besitzt ein Anwender kein Schreibrecht auf einem Feld, so wird dieses Feld ausgegraut dargestellt, der Inhalt kann gelesen werden. Besitzt ein Anwender kein Leserecht auf einem Feld, so wird dieses Feld ausgegraut dargestellt, der Inhalt ist leer. In diesem Fall kann auch über die Suche keine Einschränkung auf dem Feld vorgenommen werden.

Aktionsrechte

Aktionsrechte stellen eine weitere Gruppe von Rechten dar. Sie werden ausschließlich auf dem Client geprüft. Hierbei werden die Schreibberechtigungen geprüft.

Aktion	ID	Beschreibung
Erstelle <Entität>	create.element.permission.<Entität>	Steuert, ob die Neuanlage von Entitäten möglich ist.
Lösche <Entität>	remove.element.permission.<Entität>	Steuert, ob das Löschen einer Entität möglich ist.
Verknüpfe <Entität1> und <Entität2>	link.element.permission.<Name der Verknüpfung>	Steuert, ob das Verknüpfen von Entitäten möglich ist.
Markierte Einträge in der Tabelle bearbeiten	edit.selected.rows.permission	Steuert, ob der Benutzer mehre Datensätze in der Liste über den Menüpunkt "Markierte Einträge bearbeiten" bearbeiten kann.
Satzrechte bearbeiten	manage.entry.rights	Steuert, ob der Benutzer Satzrechte bearbeiten kann.
Satzrechte in der Liste bearbeiten	change.right.list.permission	Steuert, ob die Berechtigungen mehrere Datensätze in der Liste geändert werden können.
Änderungshistorie zeigen	show.change.history.permission	Steuert, ob der Benutzer die Feldänderungshistorie anzeigen kann.
Anzeige aktiver Benutzer	show.active.users.permission	Steuert, ob der Menüpunkt "Aktive Benutzer" angezeigt wird.
Verhindere Geschäftspartner Neuanlage mit neuer Person	avoid.customer.creation.with.new.person.permission	Steuert, dass die Geschäftspartner Neuanlage auf einer neuen Person möglich ist.
Hinzufügen von Stellvertreter administrieren	admin.adddeputy.permission	Steuert, ob der Benutzer Stellvertreter andere Benutzer bearbeiten kann.
Alle Benutzersuchen laden	admin.all.searches.permission	Konfiguriert, ob der Benutzer alle Benutzersuchen in der Suchmaske bzw. Suchverwaltung laden kann.
Suchergebnisgrenze ändern	admin.search.topcountchange.permission	Steuert, ob der Benutzer in der Suchmaske die Anzahl der Ergebnisse bearbeiten kann.
Abweichende max. Suchergebnisgrenze	admin.search.topcount.permission	Steuert, welcher Benutzer mehr wie 10.000 Ergebnisse laden kann, wenn dies im Server konfiguriert ist (Stichwort: DEFAULT_MAX_ROW_NO)
Suchen administrieren	admin.search.permission	Steuert, ob der Benutzer Systemsuchen bearbeiten kann. In der Admin-Konsole wird die Sichtbarkeit des Knotens "Verwaltung Suchbehälter" gesteuert.
Suchen und Auswertungen administrieren (Suchmaske)	admin.search.report.permission	Steuert, ob der Benutzer Suchen bearbeiten kann.
Suchen löschen	delete.search.permission	Steuert, ob der Benutzer Suchen löschen kann.
SQL-Statements administrieren	edit.dbfunction.permission	Steuert, ob der Benutzer in Suchen die Funktionen "SQL Ausdruck" und "SQL Ausdruck (Where-Part) auswählen kann. Bestehende Suchen mit SQL Ausdrücken können immer ausgeführt werden.
Datenexport ausführen	data.export.permission	Steuert, ob Suchergebnisse in der Liste nach Excel exportiert werden können.
Massendatenexport ausführen	massdata.export.permission	Steuert, ob der Benutzer in der Suchmaske Massendaten exportieren kann.
Massendatenexport administrieren	admin.massdataExport.permission	Steuert im Administrationsmenü die Sichtbarkeit des Punkten "Datenexporte".
XML-Import über Verzeichnisüberwachung	client.xml.import.permission	Steuert, ob der XML Import über die Verzeichnisüberwachung im Rich Client möglich ist. (siehe configuration.bat -> XML_IMPORT_DIR)
Eigene Desktop/Interactive Charts konfigurieren	configure.own.desktop.permission	Steuert, ob der Benutzer einen benutzerspezifischen Desktop konfigurieren kann.
Desktop/Interactive Charts administrieren	admin.desktop.permission	Steuert, ob der Benutzer den systemweiten Desktop konfigurieren kann.
Systemkonfiguration bearbeiten	modify.system.configuration	Steuert, ob der Benutzer Systemkonfigurationen ändern kann. Systemeinstellungen Standardsuchen von Entitäten Systemweite Speicherung der Sortierung und Spaltenreihenfolge in Listen.
Dubletten-Bereinigung	doublet.check.permission	Steuert, ob der Menüpunkt Dublettenbereinigung angezeigt wird.
Hinweistexte Zuordnungsbrowser bearbeiten	rowmodelmerger.message.permission	Steuert, ob der Benutzer Hinweistexte beim Verknüpfen von Entitäten bearbeiten kann.
CURSOR-BPM	bpmn.suite.persmission	Steuert, ob der Benutzer CURSOR-BPM öffnen kann.
Admin-Konsole öffnen	open.admin.console.permission	Steuert, ob der Benutzer die Admin-Konsole öffnen kann.
Schlüssel administrieren	edit.keys.permission	Steuert, ob in der Admin-Konsole die Schlüsselpflege angezeigt und Schlüssel bzw. Schlüsselbereiche bearbeitet werden können.
Anmeldung in allen Schichten	logonToEachLayer.permission	Steuert welche Benutzer sich in der CURSOR (C0) und Partnerschicht (C1) anmelden können.
Customizing exportieren/importieren	customizing.transport.permission	Steuert, ob der Benutzer Customizing Pakete exportieren/importieren kann.
Customizing Pakete entsperren	unlock.packages.permission	Legt fest, welche Benutzergruppe exportierte und noch nicht angenommene Customizing Pakete wieder entsperren kann.
Module administrieren	admin.modules.persmission	In der Admin-Konsole wird die Sichtbarkeit des Knotens "Modulverwaltung" gesteuert.
Konfiguration administrieren	admin.configuration.permission	Steuert die Sichtbarkeit der folgenden Einträge im Administrationsmenü: Gruppen und Rechtevorlagen Geometadata Schlüsselwertabhängige Bereiche E-Mail-Konfiguration Mehrwertsteuergültigkeit Web Service Logging Datenüberleitung Dubletten-Bereinigung Auftragswarteschlange Benachrichtigung SAP-Konfiguration und SAP-Mapping Ticket Klassifizierung, Ticket-Merkmale und Ticket-Begründung Beschwerdemanagement System-Cache leeren In der Admin-Konsole wird die Sichtbarkeit der folgende Knoten gesteuert: Juhuuu!, Import Suchfelder-Reihenfolge und Such-Verzeichnis Kachelverwaltung Import Internationalisierung Telefonie-Konfiguration und Telefonie-Inbound-Dialog Timer Gesperrte Daten WSContainer
Customizing2 administrieren	admin.customizing2.permission	Steuert die Sichtbarkeit der folgenden Bereiche in der Anwendung: Feldeigenschaften Bezeichnung ändern Felder anzeigen In der Admin-Konsole wird die Sichtbarkeit der folgende Knoten gesteuert: Feldeigenschaften Entitätenkonfiguration bearbeiten Verknüpfung von Entitäten Entitäten Skript-Bibliothek Konfigurationsgruppen verwalten Erweiterte Einstellungen (Anwendungsvariablen) Globale Variablen Import Internationalisierung Import/Export von Modulen Moduleinstellungen
Skripte administrieren	admin.script.permission	Steuert, ob der Benutzer Maskenskripte bearbeiten kann.
Alte Maskenskript-Historie löschen	maskscript.history.remove.permission	Steuert, ob der Administrator ältere Einträge in der Maskenskript-Historie löschen kann.
Aktionsbox administrieren	change.action.box.permission	Steuert, ob der Benutzer die Aktionsbox konfigurieren kann.
Aufruf administrieren	admin.invocation.permission	Steuert, ob der Benutzer Externe Aufrufe konfigurieren kann.
Mail Konfiguration administrieren	mail.configuration.permission	Steuert, ob der Menüpunkt E-Mail-Konfiguration angezeigt wird.
Workflows administrieren	admin.workflow.permission	Steuert, ob der Benutzer Workflows bearbeiten kann.
Rechtebehaftete Aktionen ändern	update.rights.actions.permission	Steuert, ob die Rechtebehafteten Aktionen angezeigt und geändert werden können.
Masken administrieren	admin.mask.permission	Steuert im Administrationsmenü den Menüpunkt "GUI Builder" In der Admin-Konsole wird die Sichtbarkeit der folgende Knoten gesteuert: Masken bearbeiten Maskenkonfiguration bearbeiten Konfiguration Schnellerfassungsmaske (Web Client) Konfiguration App-Maske
Dokumente administrieren	admin.document.permission	In der Admin-Konsole wird die Sichtbarkeit der folgende Knoten gesteuert: Verwaltung Dokumentvorlagen Import/Export Dokumentvorlagen Verwaltung Dokumentobjekte Import/Export Dokumentobjekte Dokumente entsperren Speicherverwaltung Dokumente
Auswertung administrieren	admin.report.permission	In der Admin-Konsole wird die Sichtbarkeit des Knotens "JasperReports" gesteuert.
Migration administrieren	admin.migration.permission	Diese Berechtigung wird benötigt, um Patches einzuspielen. In der Admin-Konsole wird die Sichtbarkeit der folgende Knoten gesteuert: Telefonnummern-Aufsplittung Aktivitätenmigration Passwörter Spezielle SQL Statements System-Initialisierung
CTI administrieren	csta.permission	Steuert, ob der Menüeintrag "CTI Verwaltung" angezeigt wird. In der Admin-Konsole werden damit den Knoten "Telefonie-Konfiguration" und "Telefonie-Inbound-Dialog" gesteuert.
Dialog für SQL Statements zeigen	sql.statements.permission	Steuert, ob SQL Statements für Customizing Pakete bearbeitet werden können. In der Admin-Konsole wird die Sichtbarkeit des Knotens "SQL Statements" gesteuert.
Web Services administrieren	web.services.permission	Steuert, ob in der Admin-Konsole Web Services angezeigt und bearbeitet werden können.

Praktisches Beispiel zur Veranschaulichung: Aktionsrecht für Daten-Export

Über den Menüpunkt Administration / Rechtebehaftete Aktionen konfigurieren ist es möglich, administrative Aufgaben zu managen. Mit diesem Konzept wurde Administratoren ein Tool zur Verfügung gestellt, mit dem andere Power-User (z.B. Abteilungsleiter) mit Administrationsrechten ausgestattet werden können und diese auch selbst (im Rahmen ihnen eingeräumten Rechten) managen können. Auf diese Weise können komplexe Strukturen und Befugnisse im Unternehmen abgebildet werden.

Es gibt u.a. ein Recht 'Datenexport', mit dem gesteuert wird, ob der Anwender das Recht hat, Daten mit den Aktionen 'Einträge nach Excel' oder 'Einträge kopieren' in eine andere Anwendung zu übertragen. Die Aktionen stehen im Kontextmenü der Liste, im Menü der Suchmaske und in der Toolbar im Subdatenbereich zur Verfügung. Im Standard hat jeder Benutzer das Recht die Daten zu kopieren.

Das Recht 'Datenexport' kann unter Administration / Rechtebehaftete Aktionen konfigurieren bearbeitet werden. Wenn einem Anwender die Rechte entzogen werden, werden die Menüpunkte nicht gezeigt.

Nach der Neuanmeldung sind die Schalter im Kontextmenü des Benutzers nicht mehr sichtbar.

Datensatzrechte

Zum Einstellen der Zugriffsrechte auf einen Datensatz muss dieser im Hauptfenster in der Formularansicht angezeigt oder in der Listenansicht markiert sein. Um eine Rechtevorlage auszuwählen, klappen Sie das Menü zum Schalter

auf und markieren die gewünschte Vorlage. Wenn Sie auf den Schalter klicken, gelangen Sie in die Rechteverwaltung.

Neuanlage von Datensätzen

Nur die Hauptgruppe des angemeldeten Benutzers erhält immer Managerechte auf dem neu angelegten Datensatz.

Ist eine Rechtevorlage ausgewählt, ist diese im Menü zum Schalter durch einen Haken markiert. Beim Öffnen der Rechteverwaltung wird Ihnen die Seite Vorlagen angezeigt. Sind die Rechte einer Vorlage abgeändert worden, ist im Menü zum Schalter keine der Vorlagen markiert. Beim Öffnen der Rechteverwaltung gelangen Sie sofort auf die Seite Erweitert, wo Sie die Einstellungen zu den einzelnen Benutzergruppen sehen.

Aktivierung von Datensatzrechten

Im Standard Auslieferungsstand von CURSOR-CRM sind auf den Entitäten Dokumente und Aktivitäten Datensatzrechte aktiviert. Werden auf anderen Entitäten ebenfalls Datensatzrechte benötigt, können diese über die Administratorkonsole Knoten Entitätenkonfiguration bearbeiten aktiviert werden.

Rechteaktivierung für Entitäten hat für bestehendes Rechtekonzept weitgehende Folgen. Es ist möglich, dass die Scharfstellung dieser Funktionalität bisherige Zugriffsrechte ändert und nicht alle Felder (Datensätze) für die Anwender sichtbar oder editierbar sind. In solchen Fällen ist Rücksprache mit der CURSOR Software AG notwendig.

Protokollierung des Exports von Daten

Es soll nachvollziehbar sein, wer wann welche Ergebnisse nach Excel exportiert hat. Der Zugriff auf diese Informationen ist eingeschränkt möglich sein. Der Betriebsrat möchte beispielsweise wissen, wer welche Daten nach Excel exportiert. In Excel könnten diese Daten leicht weiterverarbeitet werden können.

Aktivierung der Protokollierung

Zur Aktivierung der Protokollierung sind folgende Schritte notwendig:

1. Aktivierung des Systemparameters 'Tabellenexport protokollieren' im Bereich Integration der Systemeinstellungen.

2. Individuelle Konfiguration des log4j-Einstellungen im Applikationsserver.

Als category muss der Bezeichner TableDataExport verwendet werden. Der zugehörige Appender kann in eine beliebige Datei umgeleitet werden. Diese Datei kann beispielsweise in einem Verzeichnis abgelegt werden, auf das nur der Applikationsserver und ausgewählte Anwendergruppen, z.B. der Betriebsrat Schreib- bzw. Lesezugriff haben.

Konfiguration der serverseitigen Log-Methode

Im Falle des Applikationsservers JBoss sieht die individuelle Konfiguration der log4j-Einstellungen wie folgt aus. Clientseitig kann nun über den UtilitiesController die Methode logMessage(nachricht, aufrufer) aufgerufen werden, um von einem bestimmten Aufrufer aus in eine separate Datei in einem separaten Ordner etwas zu loggen. Dazu muss der Applikationsserver entsprechend konfiguriert werden:

Beispiel für JBoss 6.2

Neue Einträge in JBoss-Datei standalone-cursor.xml:

<!-- =============== -->
<!-- My log protocol -->
<!-- =============== -->
<size-rotating-file-handler name="EXCELEXPORT" autoflush="true">
 
    <encoding value="UTF-16"/>
    <formatter>
        <pattern-formatter pattern="%d %-5p [%c] %m%n"/>
    </formatter>
    <file relative-to="jboss.server.log.dir" path="/MyDir/Export.log"/>
    <rotate-size value="20m"/>
    <max-backup-index value="10"/>
    <append value="true"/>
</size-rotating-file-handler>
  
<!-- ================ -->
<!-- Specify category -->
<!-- ================ -->
<logger category="TableDataExport" use-parent-handlers="false">
    <level name="INFO"/>
    <handlers>
        <handler name="EXCELEXPORT"/>
    </handlers>
</logger>

In diesem Beispiel würde im JBoss im Ordner log\MyDir in die Datei Export.log alles vom Aufrufer TableDataExport geloggte geschrieben werden.

Erläuterung der Protokollierung

Die Protokollierung wird bei folgenden Aktionen durchgeführt:

• Excel-Export aus einer Tabellenansicht der Anwendung

• Kopieren von Daten aus einer Tabellenansicht der Anwendung in die Zwischenablage

• Ausführung der bidirektionalen Excel-Integration

• Ausführung des Dienstreiseexports (Excel)

• Erzeugung einer Steuerdatei im Zuge der Serienbrieferstellung

Was wird protokolliert?

• Anmeldekürzel Betriebssystem

• Anmeldekürzel der CRM-Anwendung

• Zeitpunkt des Exports

• Anzahl der exportierten Datensätze

• Quelle des Exports: (wo wurde der Export gestartet? Zwecks Identifizierung der exportierten Felder)

• Exportierte Felder

Beispiel anhand eines Auszugs aus der Protokolldatei:

2009-10-12 14:54:57,895 INFO
Angemeldet am Betriebssystem als mas
Angemeldet an INHOUSE als MAS
Zeitpunkt des Export: 12.10.2009 14:54:57
Anzahl der exportierten Datensätze: 3
Quelle des Exports: Hauptfenster Dokumente
Exportierte Felder: Betreff, Art, Dateiname, Typ, Kategorie, Erstellungsdatum

Spezielle Rechtekonfiguration

Die Berechtigungsvergabe für einen Datensatz erfolgt bei seiner Neuanlage.
Hierbei gelten verschiedene Regeln, die hierarchisch abgearbeitet werden.

• Als erstes wird die die Konfiguration "Satzrechte über definierte Felder" ausgewertet. Ist hier die Übernahme einer Rechtevorlage konfiguriert, so wird diese verwendet. Sind spezielle Rechte konfiguriert, so wird diese Konfiguration ausgewertet und weiter gearbeitet.

• Danach wird die Konfiguration "Rechtevorbelegung aus übergeordneter Entität" ausgewertet. Wird hier die Übernahme einer Rechtevorlage konfiguriert, so wird diese verwendet, eine evtl. zuvor individuelle Konfiguration wird verworfen. Sind spezielle Rechte konfiguriert, so wird diese Konfiguration ausgewertet, mit dem Ergebnis der vorherigen Konfiguration zusammengeführt und weiter gearbeitet.

• Als nächstes wird die initiale Rechtevergabe abgearbeitet (siehe "Spezielle Konfigurationen der initialen Rechtevergabe"). Sind zuvor spezielle Rechte konfiguriert, so werden diese in die Konfiguration der initialen Rechtevergabe eingearbeitet.

Wird in den Konfigurationen ein Fehler gefunden, so wird ein entsprechender Fehler zur Laufzeit geloggt und die fehlerhafte Konfiguration ignoriert.

Satzrechte über definierte Felder

Satzrechte lassen sich auch über definierte Felder beim Speichern des Datensatzes setzen. Hierbei ist zu beachten, dass sich durch diese Konfiguration der Speichervorgang verlangsamt. Es ist auch möglich, dass der Benutzer eine Fehlermeldung erhält, sollte er sich hierbei selbst die Berechtigung entziehen.

Die Konfiguration "Satzrechte über definierte Felder" greift nicht nur bei der Neuanlage eines Datensatzes. Die Rechte werden bei der Änderung eines der referenzierten Mitarbeiter- bzw. Gruppenfelder neu berechnet. Hierbei ist dann entscheidend, ob das Flag "additiv" gesetzt ist. Ist es auf "true" gesetzt, werden nur Gruppen hinzugefügt. Ist es jedoch auf "false" gesetzt, so werden die Rechte anhand der Konfiguration neu berechnet.

Übernahme der Rechtevorlage aus einem referenzierten Nachschlagefeld

In diesem einfachen Fall wird ein Nachschlagefeld auf eine Entität hinterlegt. Die Rechtevorlage wird bei einer Änderung des Wertes dieses Nachschlagefeldes in den aktuellen Datensatz übernommen.

Im Fall der Mitarbeiter-Entität kann noch die Einstellung useDefaultTemplateFromEmployee genutzt werden, um zu unterscheiden, ob die Rechtevorlage des Mitarbeiterdatensatzes direkt oder die im Feld Rechtevorlage des Mitarbeiters hinterlegte Rechtevorlage zu nutzen.

Die Konfiguration erfolgt über die Admin-Konsole im Bereich "Erweiterte Einstellungen (Anwendungsvariablen)":

Felder, die auf diese Weise konfiguriert sind, sollten als Pflichtfelder konfiguriert werden, die keinen Leerschlüssel erlauben, da der Leerschlüssel nicht als Rechtevorlage zulässig ist und zu einem Fehler führt.

Rechtevorlage über das Feld "Delegiert von" und von dort aus dem Feld Rechtevolage des referenzierten Mitarbeiters lesen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RightFromFieldHelper inheritedTemplateFromField="DelegatedBy.Activity" useDefaultTemplateFromEmployee="true"/> 

Rechtevorlage über das Feld "Aktivität mit" direkt aus dem Ansprechpartnerdatensatz übernehmen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RightFromFieldHelper inheritedTemplateFromField="DefaultContactPerson.Activity"/> 

Erzeugen einer speziellen Rechtevorlage aus referenzierten Mitarbeiter- oder Gruppenfeldern und zusätzlicher fester Gruppen

Die Konfiguration erfolgt ebenfalls über die Admin-Konsole im Bereich "Erweiterte Einstellungen (Anwendungsvariablen)":

Als Wert wird eine XML Struktur definiert, die Mitarbeiter-Nachschlagefelder oder direkt Gruppen-Nachschlagefelder enthalten. Die Berechtigungen für die so ermittelten Gruppen werden direkt in dem Element hinterlegt.

Über das Flag "additiv" lässt sich einstellen, ob nur Gruppen hinzugefügt werden oder die alte Berechtigung ersetzt wird.

Die Struktur kann auch direkt feste Gruppen-Primärschlüssel enthalten.

In der im Beispiel hinterlegten Rechtevorlage wird über das Feld "Delegiert an" der referenzierte Mitarbeiter gelesen und dessen Hauptgruppe, die im Mitarbeiter im Feld "Benutzergruppe" hinterlegt ist, Vollzugriff gewährt.
Die Gruppe im Feld "Delegiert an Gruppe" erhält ebenfalls Vollzugriff.
Die Gruppe USER erhält immer Lese-Rechte.

Hinterlegen einer selbstkonfigurierenden Rechtevorlage

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RightFromFieldHelper additiv="true"> 
    <EmployeeField fieldName="DelegatedTo.Activity" manage="true" readdoe="true" write="true" read="true"/>     
	<GroupField fieldName="DelegatedGrpKey.Activity" manage="true" readdoe="true" write="true" read="true"/>     
	<Group pk="USER" manage="false" readdoe="false" write="false" read="true"/>
</RightFromFieldHelper>

Spezielle Konfigurationen der initialen Rechtevergabe

Die im Mitarbeiter hinterlegte Rechtevorlage kann über die Systemeinträge des Propertymappers übersteuert werden:

Die Konfiguration erfolgt über die Admin-Konsole im Bereich "Erweiterte Einstellungen (Anwendungsvariablen)":

Hierbei können folgende ID’s verwendet werden:

• Es kann pro Tabelle eine Rechtevorlage hinterlegt werden. Ist dieser Eintrag konfiguriert, greift er als erstes.

  • ID: ACRIGHTTEMPLATE 
    Eigenschaft: [interner Tabellenname]

• ACRIGHTTEMPLATE 
  Für alle Business-Tabellen kann eine Rechtevorlage hinterlegt werden.

• REPRIGHTTEMP
  Beim Speichern eines Reports wird die so hinterlegte Rechtevorlage verwendet.

• SEARCHRIGHTTEMPLATE 
  Beim Speichern einer Suche in der C2 Schicht wird die so hinterlegte Rechtevorlage verwendet.

• RIGHTTEMPLATE 
  Dieser Eintrag greift falls keine Rechtevorlage für den Mitarbeiter konfiguriert ist (der Leerschlüssel ist in das Feld Rechtevorlage im Mitarbeiterhauptfenster eingetragen, dies ist nicht empfohlen).

Aus historischen Gründen kann noch im PropertyMapper für die RIGHTTEMPLATE-ID  der Wert „NOTEMPLATE“ eingetragen werden. Ist dies der Fall, so erfolgt die Vorbelegung der Berechtigung in einem neuen Datensatz über die Systemeinträge des Propertymappers Diese Einstellung kann nur per SQL vorgenommen werden. Es handelt sich hierbei um eine nicht mehr empfohlene Vorgehensweise.

Die Vorbelegung der Rechtevorlagen wird mit den gleichen Systemeinträgen des Propertymappers gesetzt und könnte so modifiziert werden.

Als weitere Option gibt es noch im Propertymapper

• propertyMapper DEFAULTRIGHTTOADD true/false
  Aktiviert das Template "Additive Standardrechte" (pk: DEFAULTRIGHTTOADD) 
  Ist der Eintrag aktiviert, so wird die Konfiguration "Additive Standardrechte" zu jedem neu angelegten Rechtedatensatz hinzugefügt. Diese Einstellung wirkt sich explizit nicht auf neu erstellte Vorlagen aus. 
  Sie greift ausschließlich bei individuellen Rechten, auch wenn diese über die folgenden Konfigurationen erstellt werden

  • RightFromField (wenn keine Rechtevorlage übernommen wird)

  • InheritedRight (wenn keine Rechtevorlage übernommen wird)

• DefaultRightAddGroup Eine Liste von Rechten kann hier hinterlegt werden. Diese werden für alle zu berechtigenden Gruppen gesetzt, wenn sie in der Rechteverwaltung hinzugefügt werden (Standard ist das Leserecht). 

Vererbte Rechte

Voraussetzung hierfür ist, dass die Entität, die die Rechte erben möchte über eine 1:n Relation zu einer rechtebehafteten Entität verknüpft und selbst nicht rechtebehaftet ist.
Zur Laufzeit werden dann die Berechtigungen der übergeordneten Entität ausgewertet. 

In der Admin-Konsole kann unter "Entitätskonfiguration bearbeiten" diese Konfiguration vorgenommen werden.

Rechtevorbelegung aus übergeordneter Entität

Wird eine rechtebehaftete Entität unterhalb einer bestehenden rechtebehafteten Entität angelegt und ist für diese Relation, die Vorbelegung der Rechte eingeschaltet, so bekommt der neue Satz die Rechte aus denen des darüber liegenden Satzes abgeleitet.

Übernahme der Rechtevorlage aus der übergeordneten Entität

Die Konfiguration erfolgt über die Admin-Konsole im Bereich "Erweiterte Einstellungen (Anwendungsvariablen)":

Im gezeigten Screenshot wird in der Eigenschaft der Name der zu berechtigenden Entität Note (Notizen) über die Relation rQuNo (n:m Relation zwischen Angebot und Notiz) hinterlegt. Bei der Neuanlage einer Notiz unterhalb eines Angebots, wird nun die Rechtevorlage, die im Angebot genutzt wird, in die Notiz übernommen.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InheritedRightsHelper inheritedMasterTemplate="true"/>

Erzeugen einer speziellen Rechtevorlage aus der übergeordneten Entität und zusätzlicher fester Gruppen

Die initiale Rechtevergabe kann die Werte auch aus einer übergeordneten Entität mit einem Mapping der einzelnen Rechte und dem Hinzufügen fester Gruppen erhalten.

Die Konfiguration erfolgt über die Admin-Konsole im Bereich "Erweiterte Einstellungen (Anwendungsvariablen)":

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<InheritedRightsHelper>
     <Read manage="false" readdoe="false" write="true" read="true"/>
     <Write manage="true" readdoe="false" write="true" read="true"/>
     <Group pk="USER" manage="false" readdoe="false" write="false" read="true"/>
     <Group pk="ADMIN" manage="true" readdoe="false" write="false" read="true"/>
</InheritedRightsHelper>

Die Konfiguration in diesem Beispiel übernimmt die Rechte aus dem übergeordneten Datensatz, wobei alle, die auf dem Quelldatensatz

• das Leserecht hatten nun auf dem neuen Datensatz über Lese- und Schreibrechte verfügen.

• das Schreibrecht hatten nun auf dem neuen Datensatz über Lese-, Schreib- und "Rechte verwalten"-Rechte verfügen.

• auf dem neuen Datensatz verfügen die Mitglieder der USER-Gruppe über Leserechte

• auf dem neuen Datensatz verfügen die Mitglieder der ADMIN-Gruppe über Lese- und "Rechte verwalten"-Rechte