Functionele rechten autorisatie beperken tot data rechten
Medewerkers krijgen nu een functionele autorisatie toegevoegd die in combinatie met de data rechten autorisatie leiden tot toegang van verschillende planeenheid.
Wij lopen er echter tegen aan dat roosterplanners voor de ene planeenheid het rooster maken en inzicht willen in het rooster voor een andere planeenheid om bijvoorbeeld te kijken of assistentie van medewerkers van een nabijgelegen locatie ingeroepen kan worden.
Als wij dit nu willen doen, kunnen deze roosteraars ook direct het rooster aanpassen (per ongelijk). Plus deze medewerkers hoeven niet de mogelijkheid te hebben alle gegevens van een medewerker in te zien.
Als wij dit per planeenheid kunnen instellen, kan de onderlinge samenwerking verbeteren en hebben wij beter in de hand wie waar toegang tot heeft (ook met het oog op de AVG wetgeving).
M.R.A. Daanen (Mathijs)
plaatste dit idee
-
Functioneel Beheer Partou
schreef
Contextuele autorisatie (Gelaagde rechtenstructuur)
Omschrijving: Het scheiden van de 'rol' (wat mag iemand) van de 'scope' (waar mag iemand dat).
User Story: Als Functioneel Beheerder Ik wil per rol verschillende datatypes of scopes kunnen koppelen Zodat gebruikers alleen toegang hebben tot de data die relevant is voor hun specifieke functie op dat niveau.
Beheerslast (Uitgebreid): Momenteel dwingt SDB Planning ons tot een 'vlakke' rechtenstructuur. Als een Locatiemanager (LM) bewerkrechten krijgt, gelden die vaak voor de hele regio of alle gekoppelde eenheden. Dit is een groot AVG-risico. In Quebble konden we per locatie bepalen of iemand mocht schrijven of alleen mocht inzien. Zonder deze gelaagdheid moeten beheerders handmatig honderden specifieke rollen aanmaken en onderhouden om datalekken te voorkomen, wat bij 400+ locaties onbeheersbaar is.
-
T.J.H. Plekenpol (Theo)
schreef
Wij voeren meerdere roosterprocessen binnen onze organisatie. Sommige teams doen aan Zelfroosteren, bij andere teams is een roosterplanner actief, bij weer andere teams zou de volledige vrijheid moeten zijn zichzelf in te plannen zonder tussenkomst van een roosterplanner of manager.
Doordat bepaalde instellingen niet per planeenheid kunnen worden ingesteld worden wij hierin beperkt.
Een voorbeeld is welke dienstcodes of diensturensoorten wel of niet gebruikt mogen worden voor wijzigen of aanmaken van een dienst.
Ook het genereren van berichten bv bij het aanmaken of wijzigen van een dienst is niet overal gewenst. -
J.F. Sikkes (Jacob)
schreef
Binnen ons bedrijf hebben we meerdere CAO's, waarbij medewerkers van één CAO wel PLB uren opbouwt en de andere medewerkers van het andere CAO niet.
Op dit moment kunnen medewerkers van beide CAO's PLB verlof aanvragen. Medewerkers zonder PLB uren kunnen een verlofaanvraag indienen en deze kan ook goedgekeurd worden door de leidinggevende. Of te wel: een medewerker kan niet bestaande verlofuren opnemen en dit ook nog laten goedkeuren.
Het zou mooi zijn als er onderscheid kan worden gemaakt tussen verschillende CAO's, zodat het in de toekomst niet meer mogelijk is om niet bestaand verlof aan te vragen.