Skip to Content
Documentation produit SABYOO · Ouvrir l'application →
Rôles & permissionsRègles & informations

Règles & informations

Informations conservées

Rôle

Chaque rôle possède :

  • un identifiant unique,
  • l’organisation à laquelle il appartient (vide dans le cas d’un modèle, qui n’appartient à aucune),
  • un nom,
  • une description facultative,
  • un éventuel lien vers le modèle dont il est issu (à la création de l’organisation, ou à la création d’un rôle à partir d’un modèle),
  • sa liste de permissions (des couples module + action).

On conserve aussi ses dates de création et de mise à jour.

La liste calcule en plus, pour chaque rôle, le nombre d’utilisateurs qui le portent.

Permission

Une permission est un couple module + action.

Les modules couvrent 17 domaines de l’application : entreprise, planning, pointage, qualité, clients, sites, incidents, bons d’intervention, prestations, équipe, notes de frais, congés, matériel, documents, rôles, journal, assistant. Un module entre dans cette liste dès que ses permissions sont utiles, même si ses écrans arrivent plus tard : un rôle peut alors être préparé avant l’ouverture des pages.

L’action doit faire partie de celles que le module autorise : une permission portant une action inconnue de son module est refusée à l’enregistrement, à la création comme à la modification d’un rôle.

Une permission déjà enregistrée dont le catalogue ne déclare plus l’action ou le module n’accorde rien : elle ne compte pas dans les droits de ceux qui portent le rôle, n’ouvre pas les pages de gestion, et n’apparaît ni dans la grille ni dans les modèles. Le rôle s’enregistre donc sans elle, et elle disparaît avec cet enregistrement.

Catalogue des permissions

Pour chaque module, le catalogue définit les actions autorisées :

  • Entreprise, clients, sites, incidents, rôles : Lecture, Création, Modification, Suppression.
  • Planning : Lecture, Création, Modification, Suppression, Envoyer, Exporter.
  • Qualité : Lecture, Création, Modification, Suppression, Duplication.
  • Prestations : Lecture, Création, Modification, Suppression, Gérer les catégories.
  • Équipe : Lecture, Modification, Suppression, Inviter, Gestion des rôles, Lire les données sensibles (N° de sécurité sociale, salaire, etc.). L’équipe n’a volontairement pas d’action « Création » : l’ajout d’un membre passe par l’action « Inviter ».
  • Pointage : Lecture, Régulariser, Exporter.
  • Matériel : Lecture, Création, Modification, Suppression.
  • Notes de frais : Lecture, Valider, Exporter. Créer une note pour soi n’exige aucune permission : c’est une surface personnelle, ouverte à tout membre.
  • Congés : Lecture, Création, Valider, Exporter. Poser ses propres absences et répondre à un tour de vœux n’exigent aucune permission : c’est une surface personnelle, ouverte à tout membre. « Création » couvre la saisie pour un autre membre, absence comme vœux ; « Valider » couvre la décision et, sur un tour de vœux, son ouverture, son arbitrage et sa clôture ; « Exporter » sort les absences d’une période pour la paie.
  • Documents (le dossier salarié) : Lecture, Création, Suppression. Consulter et alimenter son propre dossier n’exige aucune permission, pour la même raison : ces trois droits portent sur le dossier d’un autre.
  • Bons d’intervention : Lecture, Envoyer. « Envoyer » couvre aussi la modification et la validation du bon avant son départ.
  • Journal : Lecture, Exporter, et rien d’autre. Le journal d’activité s’écrit tout seul, au moment où l’action a lieu : aucune main ne le corrige ni ne le supprime, et il n’existe donc ni action ni écran pour le faire.
  • Assistant : Utiliser, Régler ce qu’il peut savoir. Pas de Lecture, parce qu’il n’a pas d’écran : il s’ouvre depuis la barre latérale et le raccourci. « Utiliser » ouvre tout ce qu’il fait (poser une question, lire un justificatif, écrire un rôle) ; « Régler ce qu’il peut savoir » donne la main sur ce que l’organisation lui laisse connaître de la personne qui demande. Ces deux droits ne servent que si l’organisation a allumé l’assistant, ce qu’aucun rôle ne fait. Un agent de terrain qui reçoit « Utiliser » reste un agent de terrain : ce droit n’ouvre aucun écran de gestion.

Attribution rôle / utilisateur

Un utilisateur peut porter plusieurs rôles, et un rôle peut être porté par plusieurs utilisateurs.

La seule opération disponible est le remplacement complet de la liste des rôles d’un utilisateur (il n’y a pas d’ajout ou de retrait à l’unité).

Les permissions effectives d’un utilisateur sont la réunion, sans doublon, des permissions de tous ses rôles.

Règles & comportements

  • Le nom d’un rôle est obligatoire et doit comporter entre 2 et 120 caractères. La description est facultative et limitée à 255 caractères.
  • Un rôle peut comporter jusqu’à 200 permissions. Créer un rôle sans aucune permission est autorisé.
  • Le nom d’un rôle doit être unique au sein de l’organisation : en créer un (vierge ou à partir d’un modèle) avec un nom déjà utilisé est refusé (« Un rôle porte déjà ce nom. »). Une organisation qui a gardé sa copie « Gérant » ne peut donc pas créer un second rôle « Gérant » depuis le modèle sans changer de nom.
  • Deux modèles ne portent jamais le même nom.
  • À la création d’une organisation, chaque modèle y est copié : un rôle par modèle, avec son nom, sa description et ses permissions, et le lien vers le modèle. L’organisation, ses rôles et le compte de son créateur s’enregistrent ensemble : si l’un échoue, rien n’est gardé. Le créateur ne porte pas ces rôles : son compte d’administrateur lui donne déjà tous les droits.
  • Seul un modèle peut servir de point de départ à un rôle. Le nom, la description et les permissions repris peuvent être modifiés librement avant l’enregistrement.
  • Un modèle ne se modifie pas et ne se supprime pas. Sa copie est un rôle de l’organisation, modifiable et supprimable, et la modifier ne change pas le modèle.
  • Un rôle appartenant à une autre organisation est traité comme introuvable lors d’une tentative de modification ou de suppression.
  • Un rôle encore attribué à au moins un utilisateur ne peut pas être supprimé : le bouton reste désactivé tant que des utilisateurs le portent.
  • L’attribution des rôles se fait par liste de 0 à 50 rôles sans doublon. Une liste vide retire tous les rôles. Chaque rôle indiqué doit être un rôle de votre organisation, et l’utilisateur visé doit appartenir à votre organisation. Un modèle, un rôle inexistant et un rôle d’une autre organisation sont refusés de la même façon (« Un ou plusieurs rôles sont invalides. »), pour ne rien révéler des rôles d’un autre client ; les rôles de l’utilisateur ne changent pas. La même règle vaut pour les rôles donnés à l’invitation.
  • La grille de permissions n’applique aucun enchaînement automatique : cocher une action d’écriture ne coche pas la Lecture. L’absence de Lecture à côté d’une action d’écriture déclenche seulement un avertissement, qui n’empêche pas d’enregistrer.
  • Certains modules ont besoin d’un autre pour servir à quelque chose : le Planning a besoin de la Lecture sur Prestations pour affecter un agent à une intervention, et les Notes de frais comme les Congés de la Lecture sur Équipe pour en déposer au nom de quelqu’un d’autre. La grille le signale de la même façon, par un avertissement qui n’empêche pas d’enregistrer. Une grille proposée par l’assistant, elle, accorde ces lectures d’elle-même.
  • Les permissions effectives d’un utilisateur sont la réunion sans doublon de celles de tous ses rôles ; les couples module + action en double sont fusionnés. Les permissions d’un même rôle sont également dédoublonnées au moment de l’enregistrement.
  • Les changements de rôles ou de permissions prennent effet immédiatement côté serveur : dès la requête suivante de l’utilisateur, ses droits sont recalculés (une permission retirée est aussitôt refusée). L’affichage (navigation, boutons) reflète en revanche les droits chargés à la connexion : l’utilisateur voit l’interface mise à jour après un rechargement de la page ou une reconnexion.
  • La grille des rôles affiche tout le catalogue, y compris un module dont les écrans seraient encore en construction, signalé alors par la mention « Écrans à venir » : ses permissions sont déjà acceptées par l’application et portées par des modèles, elles doivent donc pouvoir être accordées et retirées. La navigation, elle, n’affiche que les modules dont les écrans existent. Les deux listes coïncident à une exception près, l’assistant : il a des droits parce qu’on décide qui peut s’en servir, et aucun écran parce qu’il s’ouvre depuis la barre latérale et le raccourci. Il apparaît donc dans la grille, sous Gestion, et jamais dans le menu.
  • Le compteur d’actions sélectionnées ne tient compte que des actions réellement affichées dans la grille.

États d’un rôle

  • Origine : issu d’un modèle (reçu à la création de l’organisation, ou créé à partir d’un modèle) ou vierge. L’origine ne change rien : tout rôle de l’organisation est modifiable et supprimable.
  • Attribution : attribué à un ou plusieurs utilisateurs (suppression bloquée) ou à aucun (supprimable).
  • Mode de la fiche : lecture seule (utilisateur sans droit de modification) ou modifiable.
  • États de la liste : chargement en cours, aucune donnée (« Aucun rôle pour le moment »), ou aucun résultat de recherche (« Aucun résultat »).