urlaubsverwaltung icon indicating copy to clipboard operation
urlaubsverwaltung copied to clipboard

Berechtigungskonzept

Open fraulyoner opened this issue 6 years ago • 4 comments

Berechtigungen sollten feingranularer vergeben werden können.

Beispiel:

darf Einstellungen zur Anwendung vornehmen, die Daten aller Mitarbeiter verwalten, Urlaub für alle Mitarbeiter beantragen/stornieren und Krankmeldungen pflegen

Dieses Berechtigung ist viel zu groß und sollte sinnvoll gesplittet werden in mehrere Berechtigungen, z.B.:

  • darf Einstellungen zur Anwendung vornehmen
  • darf die Daten aller Mitarbeiter verwalten
  • darf Urlaub für alle Mitarbeiter beantragen
  • darf Urlaub für alle Mitarbeiter stornieren
  • darf Krankmeldungen einsehen
  • darf Krankmeldungen pflegen
  • ...

fraulyoner avatar Jan 10 '19 23:01 fraulyoner

Folgende Notizen hatte ich mir bereits im Sept. 2016 gemacht. Kann nicht genau sagen, wie aktuell dieser Stand ist.

Status Quo

Aktuell gibt es folgende Rollen in der Urlaubsverwaltung

  • INACTIVE: hat keinen Zugang mehr zur Urlaubsverwaltung (Daten des Benutzers bleiben bestehen)
  • USER: hat Zugang zur Urlaubsverwaltung und darf Urlaub für sich selbst beantragen
  • DEPARTMENT_HEAD: darf Urlaubsanträge für die Benutzer seiner Abteilungen einsehen, genehmigen und ablehnen
  • SECOND_STAGE_AUTHORITY: ist bei der zweistufigen Genehmigung von Anträgen verantwortlich für die endgültige Freigabe
  • BOSS: darf Urlaubsanträge aller Benutzer einsehen, genehmigen und ablehnen
  • OFFICE: darf Einstellungen zur Anwendung vornehmen, die Daten aller Mitarbeiter verwalten, Urlaub für alle Mitarbeiter beantragen/stornieren und Krankmeldungen pflegen

Gedankenspiel

Vorstellbar könnte es sein folgende Berechtigungen zu haben (nur ein erster Entwurf!)

  • INACTIVE: hat keinen Zugang mehr zur Urlaubsverwaltung (Daten des Benutzers bleiben bestehen)

  • ACTIVE: hat Zugang zur Urlaubsverwaltung

  • VACATION_APPLY: darf Urlaub für sich selbst beantragen

  • VACATION_APPLY_DEPARTMENT: darf Urlaub für Mitarbeiter seiner Abteilungen beantragen

  • VACATION_APPLY_GLOBAL: darf Urlaub für alle Mitarbeiter beantragen

  • VACATION_ALLOW_TEMPORARY_DEPARTMENT: darf Urlaub für Mitarbeiter seiner Abteilungen vorläufig genehmigen

  • VACATION_ALLOW_DEPARTMENT: darf Urlaub für Mitarbeiter seiner Abteilungen endgültig genehmigen

  • VACATION_ALLOW_GLOBAL: darf Urlaub für alle Mitarbeiter endgültig genehmigen

  • VACATION_REJECT_DEPARTMENT: darf Urlaub für Mitarbeiter seiner Abteilungen ablehnen

  • VACATION_REJECT_GLOBAL: darf Urlaub für alle Mitarbeiter ablehnen

  • VACATION_CANCEL_DEPARTMENT: darf Urlaub für Mitarbeiter seiner Abteilungen stornieren

  • VACATION_CANCEL_GLOBAL: darf Urlaub für alle Mitarbeiter stornieren

  • USERS_ADMINISTRATE_DEPARTMENT: darf in seinen Abteilungen Benutzer pflegen

  • USERS_ADMINISTRATE_GLOBAL: darf global Benutzer pflegen

  • SICK_NOTE_ADMINISTRATE_DEPARTMENT: darf Krankmeldungen für Mitarbeiter seiner Abteilungen pflegen

  • SICK_NOTE_ADMINISTRATE_GLOBAL: darf Krankmeldungen für alle Mitarbeiter pflegen

  • SETTINGS_ADMINISTRATE: darf Einstellungen zur Anwendung vornehmen

fraulyoner avatar Jan 10 '19 23:01 fraulyoner

Hierzu vielleicht eine kurze Idee:

Warum erstellt man nicht Benutzergruppen, denen über eine Matrix sowohl die Mitgleider der Gruppe als auch deren Rechte granular zugewiesen werden können. Ich stelle mit hier eine Tabellenform vor. Links werden die Gruppen angezeigt, der Tabellenkopf zeigt die Gruppen.

CarstenBaumann avatar Sep 12 '19 08:09 CarstenBaumann

Anmerkung: #1348 behandelt lediglich die generelle Zugriffserlaubnis auf die Anwendung in Abhängigkeit einer dedizierten Rolle aus dem OIDC-ID-Token. Aber auch für ein granulareres Berechtigungskonzept könnte auf Rollen aus dem OIDC-Provider zurückgegriffen werden.

joachimmathes avatar Sep 21 '20 13:09 joachimmathes

Hi,

I can only support this feature request. I am planning to use the software at a scientific institute. Here were have mutliple research groups (department), having their own professors (department head); however, they all have secretaries (some also share secretaries) and their is no deparmtent_office currently. To be compliant with DGSVO I would need to run multiple instances of UV or get a permission of the users that alls secretaries can see all vacations - not very likely. (And there is no "betriebsbedingter Grund", that all secretaries should see all vacations.)

Furthermore, I am would manage the system, but there is no admin role. I would like to set the settings of the system, but do no need to see all vacations and so on....

Are there any plans to implement something as described in the OP?

Best and thanks for the software, Jan

gebauer avatar Apr 07 '22 06:04 gebauer