Zum Inhalt

Benutzer, Gruppen & Berechtigungen

„Wer darf was" regeln in KCForms drei Bausteine: Benutzer, Gruppen und Berechtigungen. Gepflegt werden sie unter System-Administration → Benutzer & Zugang mit den Einträgen Benutzerverwaltung, Gruppenverwaltung und Berechtigungen.

Wie die Anmeldung selbst funktioniert (DB-, Skript-, OIDC-Login …), steht unter Anmeldung; wer ein bestimmtes Formular öffnen darf, unter Zugriff auf Formulare.

Das Modell

flowchart LR
    B[Benutzer] -- Mitglied in --> G[Gruppe]
    G -- hat --> P[Berechtigung]
    G -. "ergibt ROLE_&lt;Gruppe&gt;" .-> A((Rechte beim<br/>Anmelden))
    P -. "ergibt PERM_&lt;Code&gt;" .-> A
Baustein Was es ist Gepflegt unter
Benutzer eine Person mit Anmeldename, Name, E-Mail, Sprache und ggf. Personnummer (für die Anmeldung per BankID) Benutzerverwaltung
Gruppe ein benannter Zusammenschluss von Benutzern, z. B. Buchhaltung Gruppenverwaltung
Berechtigung ein Code wie DATEV_EXPORT, der einer Gruppe zugeordnet wird Berechtigungen

Berechtigungen hängen immer an Gruppen, nicht direkt an Benutzern. Beim Anmelden bekommt ein Benutzer für jede seiner Gruppen die Rolle ROLE_<Gruppe> und für jede Berechtigung dieser Gruppen PERM_<Code>.

Administrator = Mitglied der Gruppe ADMIN

Die Gruppe ADMIN ergibt die Rolle ROLE_ADMIN. Sie öffnet die gesamte System-Administration, den Formular-Editor und alle Admin-Schnittstellen und hat automatisch alle Berechtigungen. Einzelne Verwaltungsaufgaben lassen sich ohne Admin-Rolle über Berechtigungen vergeben.

Gruppen

Gruppen bündeln Benutzer, damit Rechte nicht je Person gepflegt werden müssen. Sie wirken an mehreren Stellen:

  • als Träger von Berechtigungen,
  • im Formular-Zugriff (Stufe Bestimmte Gruppen),
  • in Workflows als Empfänger einer Stufe (Gruppen-Sammelpostfach),
  • in Skripten und Bedingungen über ctx.user.roles.

Berechtigungen

Eine Berechtigung ist ein frei wählbarer Code (Großbuchstaben, Ziffern, Unterstrich, z. B. SAP_ACCESS) mit Beschreibung. Sie wirkt erst dort, wo sie geprüft wird — im Formular-Zugriff (Stufe Bestimmte Berechtigungen), in Skripten oder in Bedingungen.

Berechtigungen mit eingebauter Wirkung

Diese Codes prüft KCForms selbst. Wer sie hat, sieht im Zahnrad-Menü und in der System-Administration genau die passenden Bereiche — ohne Mitglied der Gruppe ADMIN zu sein.

Berechtigung Wirkung
PROPERTIES Properties pflegen („KeyUser").
FORM_STUDIO den Formular-Editor nutzen und die Formular-Bausteine pflegen (Baukasten, Druckvorlagen, Section-Repository, Skript- und Datei-Bibliotheken); dazu im Editor Web-Links erzeugen und den Formular-Zugriff einstellen. Gleichwertig mit Administrator, siehe unten.
DB_TABLE_BROWSE im Formular-Editor Tabellen und Spalten der KCForms-Datenbank auswählen und die Lookup-Vorschau nutzen — im Tabellen-/Spalten-Modus. Vorschauen mit freiem SQL, WHERE-Bedingung oder Skript sowie Sitzungstabellen und Spalten mit Passwörtern oder Tokens bleiben Administratoren vorbehalten. Ohne dieses Recht trägt man Tabellennamen von Hand ein.
SCRIPT_CONSOLE die Skript-Konsole nutzen. Gleichwertig mit Administrator, siehe unten.
RECORD_VIEW_ALL Datensätze anderer Benutzer ansehen: in der Liste „Alle“, beim Öffnen (dann schreibgeschützt), im Änderungsprotokoll, im Druck und bei den Anlagen. Ändern und Löschen bleibt beim Eigentümer.
REPORT_EXPORT Listen als CSV oder Excel exportieren. Ohne dieses Recht fehlen die Export-Knöpfe in der Liste.
USER_MANAGE Benutzerverwaltung: Benutzer anlegen, ändern, löschen, Passwort setzen, Gruppen zuordnen.
GROUP_MANAGE Gruppenverwaltung: Gruppen anlegen, ändern, löschen.
PERMISSION_MANAGE Berechtigungen anlegen und Gruppen zuordnen.
SYSTEM_CONFIG System-Einstellungen und E-Mail-Konfiguration.
RETENTION_MANAGE Bereich Aufbewahrung (Gallring): Löschprotokoll einsehen und exportieren, fällige Löschungen freigeben, Datensätze sperren, Lauf starten. Die Frist je Formular stellt weiterhin der Formular-Editor ein.

Grenzen und Schlüsselrechte

  • Konten von Administratoren und die Gruppe ADMIN selbst bleiben Administratoren vorbehalten: Mit USER_MANAGE oder GROUP_MANAGE kann niemand sich oder anderen Admin-Rechte verschaffen.
  • Nur weitergeben, was man selbst hat: Wer nicht Administrator ist, kann einem Benutzer nur Gruppen geben, deren Berechtigungen er selbst besitzt, und einer Gruppe nur eigene Berechtigungen zuordnen. Entfernen geht immer.
  • SYSTEM_CONFIG umfasst nur die allgemeinen Einstellungen und die Oberfläche. Anmeldung, OIDC, BankID, Ad-hoc-Anmeldung und die Freigabeliste für HTTP-Ziele bleiben Administratoren vorbehalten.
  • Der SQL-Client (DB-Client) und der Transport zu anderen Systemen bleiben Administratoren vorbehalten.

FORM_STUDIO und SCRIPT_CONSOLE sind Administrator-Rechte

Mit beiden Rechten schreibt bzw. startet man Server-Skripte, die jede Tabelle der Datenbank lesen und ändern dürfen. Damit kann sich ein Inhaber selbst in die Gruppe ADMIN eintragen, Passwörter zurücksetzen oder Daten anderer Benutzer ändern. Das ist kein Fehler, sondern die Natur eines Formular-Editors mit Skripten: Wer Server-Code schreiben darf, hat die Kontrolle über den Server.

Für den Betrieb heißt das:

  • Beide Rechte nur Personen geben, denen du auch die Gruppe ADMIN geben würdest.
  • Konten mit diesen Rechten schützt KCForms wie Administrator-Konten. Mit USER_MANAGE kann niemand ihr Passwort setzen, sie ändern, ihnen Gruppen nehmen oder sie löschen — sonst könnte man sich als ein solches Konto anmelden und auf diesem Umweg selbst Administrator werden.
  • Für Personen, die nur Formulare gestalten, aber keine Skripte schreiben sollen, gibt es derzeit kein eigenes, schwächeres Recht.

Beispiel-Berechtigungen

Die übrigen mitgelieferten Codes (SAP_ACCESS, SAP_FI_POST, DATEV_EXPORT, HR_DATA_EDIT, LDAP_USER_CREATE, FORM_APPROVE) sind Beispiele — so steht es auch in ihrer Beschreibung. KCForms prüft sie nicht selbst; sie wirken erst, wenn du sie in einer Zugriffsregel, einem Skript oder einer Bedingung abfragst. Eigene Codes legst du genauso an.

In Skripten und Bedingungen

ctx.user trägt Gruppen und Berechtigungen des angemeldeten Benutzers — ohne die Präfixe ROLE_ und PERM_:

Pfad Inhalt Beispiel
ctx.user.roles Gruppen ["ADMIN", "Buchhaltung"]
ctx.user.permissions Berechtigungen ["DATEV_EXPORT", "SAP_ACCESS"] 
// onValidate
if (ctx.user.permissions.indexOf("HR_DATA_EDIT") < 0) {
  ctx.addError(null, "Nur die Personalabteilung darf diesen Antrag stellen.");
}

Dieselben Werte stehen in Sichtbarkeits- und Pflichtbedingungen bereit; der Regel-Baukasten hat dafür eigene Bausteine (Gruppe / Berechtigung) — siehe Regeln.

Benutzer aus LDAP

Benutzer und Gruppen lassen sich aus einem Verzeichnis übernehmen — per Anmelde-Skript bei jeder Anmeldung (siehe Anmeldung) oder regelmäßig per LDAP-Benutzer-Export. Damit Rollen greifen, muss der Gruppenname im Verzeichnis dem Namen der KCForms-Gruppe entsprechen (oder im Skript umgesetzt werden).

Siehe auch