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 ; c’est elle qui donne leurs pouvoirs d’équipe à tous les rôles hors observateurs d’affaires - admin, operations et executive.
Les quatre rôles
Un utilisateur a exactement un rôle, renvoyé comme le champ role sur l’objet utilisateur :
| Rôle | Valeur de role | Périmètre typique |
|---|---|---|
| Administrateur | admin | Contrôle total du compte : utilisateurs, paramètres, validation, règlement. |
| Opérations | operations | Opérations quotidiennes : clients, facturation, règlement des frais ; revue des feuilles de temps, congés et frais à l’échelle du compte. |
| Direction | executive | Supervision : KPI, marges, prévisions ; revue des feuilles de temps, congés et frais à l’échelle du compte. |
| Consultant | consultant | Libre-service : sa feuille de temps, ses congés, ses affectations, ses frais. |
À l’inscription, vous devenez l’admin du compte. Les trois observateurs d’affaires - admin, operations et executive - voient et arbitrent chacun tous les consultants, feuilles de temps, demandes de congé et frais 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) ; c’est ainsi que tout autre rôle dépasse ses propres enregistrements.
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 Forbiddensignifie 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 Foundsignifie 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, opérations ou direction, ou le chef d’équipe du consultant.
- Approuver ou refuser des congés : administrateur, opérations ou direction, ou le chef d’équipe du consultant.
- Approuver ou refuser un frais : administrateur, opérations ou direction, 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.
Pour les trois règles de décision ci-dessus, la séparation des pouvoirs tient : un appelant non administrateur - chef d’équipe ou observateur d’affaires - ne tranche jamais un enregistrement de son propre profil de consultant lié ; seul l’administrateur le peut.
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.
La relation manager_id est ce qui donne leurs pouvoirs d’équipe aux rôles hors observateurs d’affaires : un chef d’équipe consultant peut valider les feuilles de temps de ses subordonnés, approuver ou refuser leurs congés et leurs frais, et agir en leur nom. Sa portée se limite aux consultants qu’il encadre plus les siens, et il n’acquiert jamais ces pouvoirs sur ses propres enregistrements. Les observateurs d’affaires ne sont pas bornés ainsi : admin, operations et executive atteignent tous les consultants du compte, qu’ils encadrent quelqu’un ou non. operations et executive gardent seulement l’exclusion de séparation des pouvoirs - ils ne tranchent pas les enregistrements de leur propre profil de consultant lié.
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 :
| Champ | Apparaît sur | Visible pour | Masqué à |
|---|---|---|---|
daily_cost | profils de consultant, budgets de mission | admin, operations, executive | consultant |
billing_rate | affectations, lignes de feuille de temps | admin, operations, executive | 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
403comme un “mauvais rôle”, et non une “erreur transitoire” ; ne rejouez pas. - Prévoyez que les champs numériques sensibles soient
nullpour 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é avec un jeton
consultant, l’utilisateur qui agit doit être le responsable de cet enregistrement ; un rôle correspondant seul ne suffit pas. Les observateurs d’affaires (admin,operations,executive) agissent sur n’importe quel enregistrement du compte - sauf, hors administrateur, ceux de leur propre profil de consultant lié.
Voir Suivre le temps, Demander des congés et Gérer les frais pour la répartition des rôles dans chaque flux.