Chaque requête porte un rôle, décidé à la connexion. Le rôle contrôle deux choses : quels points de terminaison vous pouvez appeler, et quels champs sensibles vous êtes autorisé à voir. Okouro possède aussi une capacité de chef d’équipe qui est une relation, et non un rôle.

Les quatre rôles

Un utilisateur a exactement un rôle, renvoyé comme le champ role sur l’objet utilisateur :

À l’inscription, vous devenez l’admin du compte. Un utilisateur désigné comme le responsable de quelqu’un gagne des pouvoirs de chef d’équipe en plus de son rôle (ci-dessous).

Ce que chaque rôle peut faire

Plutôt que de mémoriser une matrice, servez-vous des codes d’état comme repère :

• 403 Forbidden signifie que votre rôle n’est pas autorisé à appeler ce point de terminaison du tout, ou ne l’est pas pour cet enregistrement précis.
• 404 Not Found signifie que l’enregistrement existe hors de votre périmètre, ou n’existe pas du tout ; Okouro ne fait pas la distinction.

Quelques règles concrètes qui reviennent dans les guides :

• Valider ou refuser une feuille de temps : administrateur uniquement.
• Approuver ou refuser des congés : administrateur uniquement.
• Approuver ou refuser un frais : administrateur ou le chef d’équipe du demandeur.
• Payer un frais : administrateur ou opérations.
• Mettre à jour le budget d’une mission : administrateur uniquement.
• Lire les KPI de staffing : administrateur ou direction.
• Lire les KPI de budget de mission : administrateur, opérations ou direction.

Chefs d’équipe

Un utilisateur désigné comme le manager_id d’un ou plusieurs consultants devient chef d’équipe pour ces consultants. C’est orthogonal au rôle : un utilisateur operations peut être chef d’équipe, et un autre consultant aussi.

Les chefs d’équipe acquièrent des pouvoirs à périmètre sur les consultants qu’ils encadrent : ils peuvent valider les feuilles de temps de leurs subordonnés, approuver ou refuser leurs congés et leurs frais, et agir en leur nom. Ils n’acquièrent jamais ces pouvoirs sur leurs propres enregistrements, et leur portée se limite aux consultants qu’ils encadrent plus les leurs.

Vous pouvez savoir si l’utilisateur courant encadre quelqu’un depuis GET /auth/me : is_manager est vrai quand l’utilisateur gère au moins un consultant.

Visibilité au niveau des champs

Deux champs monétaires sont sensibles et sont masqués au rôle consultant :

Un champ masqué est renvoyé comme null, jamais retiré de la réponse. Ainsi, la forme du JSON est stable quel que soit le rôle ; seule la valeur change. Par exemple, la même affectation paraît différente selon qui la demande :

{ "id": "...", "consultant_id": "...", "billing_rate": "900.00", "status": "active" }

{ "id": "...", "consultant_id": "...", "billing_rate": null, "status": "active" }

La seconde réponse est ce qu’un consultant reçoit. Les chiffres de marge sur les budgets de mission et la rentabilité des devis suivent la même règle (masqués au consultant).

Isolation des comptes

Chaque enregistrement appartient à un compte (votre tenant). Un jeton n’atteint jamais que des enregistrements de son propre compte ; il n’y a aucun moyen d’adresser les données d’un autre compte, et les lectures entre comptes renvoient 404. Vous ne passez jamais d’identifiant de compte dans les requêtes ; il est dérivé de votre jeton.

Concevoir en tenant compte des rôles

• Considérez 403 comme un “mauvais rôle”, et non une “erreur transitoire” ; ne rejouez pas.
• Prévoyez que les champs numériques sensibles soient null pour les jetons de rôle consultant, et faites dériver votre interface ou votre logique là-dessus plutôt que de supposer qu’un nombre est toujours présent.
• Si vous devez agir sur l’enregistrement d’un subordonné, l’utilisateur qui agit doit être le responsable de cet enregistrement (ou un administrateur) ; un rôle correspondant seul ne suffit pas.

Voir Suivre le temps, Demander des congés et Gérer les frais pour la répartition des rôles dans chaque flux.