Rollen und Berechtigungen: Einrichtung und täglicher Einsatz

Systemrollen als Startwerte und was sie bereits freigeben

Beim ersten Öffnen des Reiters schreibt Home Builder Software die mitgelieferten Rollen für diese Firma: Administrator, Bauleitung, Büro und Rechnungswesen, Einkauf und Vergabe, Lohnbuchhaltung sowie Baustelle, jede mit eigener Farbe. Sie existieren, damit niemand ein Rechtemodell entwerfen muss, bevor der zweite Kollege eingeladen wird. Die Bauleitung verwaltet Projekte und kauft ein, das Büro schreibt Rechnungen, der Einkauf vergibt und bestellt und liest die Finanzzahlen samt Ausgangsrechnungen mit, ohne selbst eine schreiben zu können, die Lohnbuchhaltung gibt Stunden frei, die Baustelle erfasst vor Ort.

Systemrollen lassen sich umbenennen, umfärben und neu zuschneiden, aber nicht löschen, und die Administratorrolle behält die vollständige Rechteliste, gleich welche Kästchen das Formular abschickt. Das ist Absicht: Eine Firma, die ihre eigene Administratorrolle leert, sperrt sich ohne Rückweg aus den Einstellungen aus. Jede Karte zeigt Rollennamen, technischen Schlüssel und die Zahl der aktuell hinterlegten Berechtigungen, sodass ein falscher Zuschnitt auffällt, bevor jemand darauf sitzt.

Eigene Rolle aus Name, Farbe und Berechtigungsschlüsseln bauen

Rolle anlegen fragt einen Namen mit bis zu 120 Zeichen, eine Farbe als sechsstelligen Hex-Wert und die Kästchen der Berechtigungen ab. Den technischen Schlüssel leitet die Anwendung aus dem Namen ab und macht ihn automatisch eindeutig, sodass zwei Rollen namens Polier nicht kollidieren. Angenommen werden ausschließlich die 17 bekannten Schlüssel, alles andere weist die Prüfung ab. Eine Änderung wirkt bereits in derselben Antwort, weil der Rechte-Zwischenspeicher der Anfrage beim Speichern verworfen wird.

Beim Ankreuzen lohnt der Blick auf die Paare. Ein Verwaltungsrecht schließt sein Ansichtsrecht immer ein: records.write deckt records.view ab, finance.manage deckt finance.view ab, workforce.manage deckt workforce.view ab, und sowohl projects.manage als auch site.write decken projects.view ab. Es genügt daher, die schreibende Hälfte zu setzen. Einkauf und Lohn sind eigene Schlüssel, weil Material bestellen und eine Ausgangsrechnung schreiben zwei verschiedene Aufgaben sind und die Lohnabrechnung nicht darüber entscheidet, wer wo arbeitet.

Rolle zuweisen und einen Mitarbeiter auf Projekte begrenzen

Die Zuweisung ist ein Dialog je Person, erreichbar über das Zuweisungsraster in diesem Reiter oder über Rolle ändern in der Nutzerliste. Mehr ist im Tagesgeschäft nicht zu tun: ein Kollege, eine Rolle, ein Speichern. Die eigene Rolle ändert niemand, und die Administratorrolle vergibt oder entzieht nur ein Administrator, damit aus dem Recht, Einstellungen zu pflegen, nicht stillschweigend die Herrschaft über den Mandanten wird. Den letzten Administrator umzustellen wird abgewiesen.

Über der Rolle liegt die Projekteinschränkung, die auf der Kontaktkarte einer Person unter Projektzugriff ändern gepflegt wird. Eingeschaltet und mit Baustellen bestückt begrenzt sie das Konto genau darauf; eingeschaltet und leer gelassen bleibt die Person ohne jeden projektgebundenen Datensatz, was für eine externe Buchhaltung nützlich und für einen Polier überraschend ist. Firmenweite Datensätze ohne Projektbezug bleiben sichtbar, soweit die Rolle sie ohnehin erlaubt.

Serverseitige Prüfung hinter den ausgeblendeten Schaltflächen

Drei Schichten erledigen die Arbeit. Modulrouten und die JSON-API tragen je Route eine geforderte Berechtigung; eine zentrale Schicht ordnet danach jede benannte Schreibroute der angemeldeten Anwendung dem nötigen Schlüssel zu; und die Controller prüfen weiterhin Besitz, Firma, Statusübergänge und bei Bedarf ein strengeres Recht. Die Oberfläche kürzt Navigation, Meldungen und Aktionen zusätzlich passend zur Rolle, was Bequemlichkeit ist und nicht die Sicherheitsgrenze.

Den Projektzugriff setzt ein globaler Abfrage-Scope auf Projekte und alle daran hängenden Objekte durch, sodass eine nicht freigegebene Baustelle in Listen, Detailadressen, Suche, Beziehungen und API gleichermaßen als nicht vorhanden antwortet. Das ist einer ausdrücklichen Ablehnung vorgezogen, weil eine Ablehnung die Existenz des Projekts bestätigen und seine Nummer verraten würde. Rollenänderungen erscheinen als role.created, role.updated, role.deleted und user.role.updated mit handelnder Person.

Welches Recht welches Modul in Bau, Einkauf, Finanzen und Lohn öffnet

Die Baustellenerfassung hängt an site.write: Tagesberichte, Mängel, Rückfragen, Dokumenten-Uploads und Prüfbefunde. Akquise und Stammdaten hängen an records.write: Leads, Kunden, Kalkulationen, Angebote, Bemusterungen, Serviceanfragen, Betriebsmittel, Vorlagen, Protokolle sowie Mailversand, Mailzuordnung und der Kontaktimport. Die Projektarbeit hängt an projects.manage: Projekte, Projektvorlagen, Terminplan, Arbeitskalender, Nachunternehmer und Nachträge. Ein Polier erhält damit site.write, ohne die Akquiseakte zu öffnen.

Das Geld ist in zwei Richtungen getrennt. Rechnungen, Mahnwesen, Zahlungseingänge, Bürgschaften, Finanzbuchungen und die Nummernkreise verlangen finance.manage; Vergabe, Bestellung, Wareneingang und Lieferantenrechnungen verlangen purchasing.manage. Das Ansichtsrecht der Workforce erlaubt bereits, die eigene Zeit zu buchen, zu korrigieren und zu löschen sowie die eigene Krankmeldung zu erfassen, während das Freigeben und Exportieren fremder Stunden workforce.payroll braucht. Der Assistent verlangt ai.use, der KI-Reiter ai.manage.

Beispiel: eine Polier-Rolle mit Baustellenrechten und Projekteinschränkung

Cedar Ridge Homes möchte, dass Travis Nguyen seine Kolonnen führt, ohne durch die Akquiseakte zu blättern. Ein Administrator legt die Rolle Field lead mit der Farbe #B45309 an und kreuzt genau site.write und workforce.view an; den technischen Schlüssel field-lead leitet die Anwendung selbst ab, und weil site.write das Ansichtsrecht projects.view bereits einschließt, bleibt jedes weitere Kästchen leer. Der Zuweisungsdialog setzt Travis mit einem einzigen Speichern auf die neue Rolle. Ihm stattdessen die Administratorrolle zu geben, hätte nur ein Administrator gedurft, und die eigene Rolle kann Travis ohnehin nicht anfassen, ganz gleich, wie die Oberfläche bei ihm aussieht.

Unter Projektzugriff ändern gibt das Büro Willow Creek Lot 27 und Harper Station Townhomes für ihn frei. Am nächsten Morgen zeigt seine Projektliste zwei Zeilen, deren Auftragssummen sich auf 4.636.500,00 Dollar addieren, während die firmenweite Liste weiter sechsundzwanzig Aufträge mit 29.304.500,00 Dollar führt; die Suche nach Oakmont Ridge Phase II liefert gar nichts zurück, statt den Auftrag preiszugeben. Auf seinem Baustellenpaar schreibt er Tagesberichte und Mängel und bucht die eigene Zeit, doch die Stunden seiner Leute freizugeben bleibt versperrt, weil dieser Schritt workforce.payroll verlangen würde. Im Audit-Log stehen role.created und user.role.updated mit der handelnden Person.

Rollen und Berechtigungen: vor dem Speichern prüfen

• Ein Verwaltungsrecht schließt sein Ansichtsrecht ein, weshalb records.write, finance.manage, projects.manage oder workforce.manage allein bereits genügen.

• Eine eigene Rolle lässt sich erst löschen, wenn ihr kein Benutzer mehr zugeordnet ist; Systemrollen sind grundsätzlich nicht löschbar.

• Die Administratorrolle behält alle 17 Berechtigungen, unabhängig davon, welche Kästchen ihr Bearbeitungsformular sendet.

• Eine per Projektzugriff eingeschränkte Person mit leerer Projektliste sieht nirgends einen projektgebundenen Datensatz, auch nicht über die JSON-API.

• Die eigene Rolle ändert niemand, und die Vergabe oder der Entzug der Administratorrolle bleibt Administratoren vorbehalten.

Rollen und Berechtigungen: typische Fehler

• Einem Polier records.write geben, damit er Tagesberichte schreiben kann: Die Baustellenerfassung liegt auf site.write, records.write öffnet stattdessen die Akquiseakte. Vergeben Sie site.write und lassen Sie die Stammdaten zu.

• Ein Recht entziehen und sofortige Wirkung erwarten: Die Änderung greift ab der nächsten Anfrage der Person, nicht in der bereits geöffneten Seite. Lassen Sie neu laden, bevor Sie urteilen.

• Das Löschen einer noch zugewiesenen Rolle wird abgewiesen. Setzen Sie zuerst jeden Träger über die Nutzerliste auf eine andere Rolle und entfernen Sie danach die leere Rolle.