Rôles et accès¶

Cette page explique comment OS décide de ce qu'une personne peut faire dans une organisation : les rôles, les groupes, les attributs, le document de règles de l'organisation, la façon dont un partenaire atteint les organisations situées sous lui, et pourquoi personne ne peut donner plus que ce qu'il a lui-même. Elle ne contient aucune étape ; les pages de tâche sous Gérer montrent comment le configurer.

Une règle décide¶

Tout ce qu'une personne peut faire dans OS vient de règles. Une règle indique, pour un type d'élément (un groupe, un membre, un agent, une conversation), si elle l'autorise (permit) ou le refuse (forbid), pour quelles actions et sous quelles conditions.

Il y a quatre actions :

Trois principes décident de chaque cas :

• Rien n'est permis sans une règle qui l'autorise. L'ordre des règles n'a pas d'importance.
• Une règle de refus l'emporte. Si un forbid s'applique, OS refuse, quoi que dise un permit.
• Aucune action n'en inclut une autre. Qui peut modifier sans pouvoir voir ne trouve pas l'élément. Ce que vous n'avez pas le droit de voir n'existe pas pour vous : OS répond comme si cela n'existait pas.

Une règle peut poser des conditions sur l'élément (le nom, ou une étiquette qu'il porte) et sur la personne (un attribut qu'elle a). Une règle ne s'applique que si toutes ses conditions sont remplies ; pour autoriser deux valeurs, on écrit deux règles. L'aspect exact d'une règle figure dans Types et actions.

Rôles¶

Un rôle est un ensemble nommé de règles. Qui a un rôle relève de ses règles. Un membre reçoit un rôle directement, ou par un groupe dont il fait partie.

Chaque organisation a les mêmes rôles intégrés. Ils sont identiques partout et vous ne les modifiez pas.

En outre, un administrateur crée des rôles propres pour son organisation : par exemple un rôle « Chef d'équipe » qui peut gérer les membres de son propre service. Une organisation en a 100 au maximum, chacun avec 200 règles au maximum. Voir Gérer les rôles.

Ce que les rôles intégrés permettent dans les fonctions d'IA¶

Les rôles intégrés contiennent aussi des règles sur les fonctions d'IA : modèles, agents, connaissances, fichiers et conversations.

Chaque rôle intégré peut utiliser tous les modèles, outils, agents, prompts, skills, planifications, workflows, connaissances et fichiers de l'organisation. Ce que le service de l'organisation ne contient pas, un rôle intégré ne le permet pas non plus. Parmi les conversations, la mémoire, les fichiers enregistrés et les lignes de datastore, un membre atteint les siens et ceux qui sont partagés, qui n'appartiennent à personne en particulier.

Un administrateur ne voit jamais les conversations, la mémoire ou les fichiers d'un collègue. Même org-admin n'atteint de ces lignes que les siennes et celles qui sont partagées. Qui veut autre chose écrit lui-même une règle pour cela, et ne le peut que s'il a lui-même cet accès (ci-dessous).

Paramètres pour toute l'organisation¶

Quelques éléments valent pour tout le monde dans l'organisation à la fois et ne dépendent pas de la personne. Ils ne figurent donc pas dans un rôle, mais dans le document de règles :

• si les fonctions d'IA peuvent écrire dans la mémoire : par défaut pour personne ;
• si les fichiers et pages enregistrés peuvent être partagés par un lien : par défaut pour personne ;
• si les fichiers créés par un outil peuvent être téléchargés : par défaut pour chaque membre ;
• quels routeurs de modèles peuvent être utilisés : par défaut chacun, pour chaque membre ;
• quelles adresses externes les fonctions d'IA peuvent atteindre. Sans règle à ce sujet, ce sont les adresses que votre opérateur autorise pour l'organisation ; une règle peut les restreindre.

L'écriture dans la mémoire et le partage par lien s'activent dès que le document de règles les autorise, et alors pour tout le monde, jamais pour une seule personne. Seul qui les a lui-même, org-admin ou operator, peut écrire une telle règle (comment). Un rôle propre ne peut rien dire à ce sujet.

Groupes¶

Un groupe rassemble des membres, par exemple une équipe ou un service. Un groupe peut avoir des rôles et des valeurs d'attribut, et chaque membre du groupe les a alors aussi. Qui quitte le groupe, ou dont le groupe disparaît, perd ce que le groupe donnait. Voir Gérer les groupes.

Attributs¶

Un attribut est un fait sur un membre que les règles peuvent lire, comme department (service) ou office (bureau). L'administrateur décide quels attributs l'organisation connaît et si les valeurs sont libres ou issues d'une liste fixe. Un membre a les valeurs qu'il a reçues lui-même plus celles de ses groupes. Voir Gérer les attributs.

OS lit toujours lui-même trois attributs, que vous ne pouvez pas créer :

• role : chaque rôle que le membre a, directement ou par un groupe ;
• group : chaque groupe dont le membre fait partie ;
• subject : qui est le membre, pour qu'une règle puisse dire « cela m'appartient ».

OS détermine ces faits de nouveau à chaque requête, à partir de ce que l'organisation a enregistré. Un membre ne peut pas indiquer lui-même ses attributs.

Le document de règles¶

En plus des rôles, chaque organisation a un document de règles : des règles qui valent pour chaque membre actif. Vous y mettez ce qui vaut pour tout le monde, comme « personne n'utilise le modèle coûteux » ou « les stagiaires n'utilisent pas les agents du service financier ». Les paramètres pour toute l'organisation s'y trouvent aussi. Voir Le document de règles.

Pour un membre valent donc ensemble : les règles de ses rôles, le document de règles, et member.

Partenaires et organisations situées en dessous¶

Un rôle est donné avec une portée :

• organisation (par défaut) : le rôle vaut dans l'organisation qui l'a donné.
• descendants : le rôle vaut dans cette organisation et dans chaque organisation située en dessous.

Ainsi, les collaborateurs d'un partenaire travaillent dans les organisations de leurs clients sans y être membres. Un collaborateur du support qui a org-admin avec la portée descendants chez le partenaire gère aussi les clients situés sous le partenaire. Du partenaire, ne compte dans une organisation cliente que ce qui est donné avec la portée descendants ; le document de règles du partenaire et ses rôles avec la portée organisation n'atteignent pas le niveau inférieur.

Une organisation ne peut pas retirer la gestion qu'une organisation au-dessus d'elle donne avec la portée descendants : il n'existe pas de règles de refus sur la gestion. Sur les fonctions d'IA, si : un forbid dans le document de règles d'une organisation s'y applique aussi aux collaborateurs d'un partenaire. Le journal d'audit de l'organisation indique, pour chaque modification, de quelle organisation la personne agissait.

Le premier administrateur d'une nouvelle organisation reçoit org-admin avec la portée descendants, afin de gérer aussi les services qu'il créera plus tard sous son organisation.

Personne ne donne plus que ce qu'il a¶

Toute modification qui permet à quelqu'un de faire davantage est une attribution : donner un rôle, placer un membre dans un groupe, donner un rôle ou une valeur à un groupe, donner une valeur d'attribut, écrire les règles d'un rôle propre ou le document de règles, et inviter avec l'un de ces éléments. OS n'autorise une attribution que si vous pouvez faire la modification vous-même et si vous avez vous-même ce que vous donnez :

• un rôle, vous l'avez si vous l'avez vous-même (avec au moins la même portée), ou chacune de ses règles ;
• une valeur d'attribut, vous l'avez si vous l'avez vous-même, ou si vous pouvez attribuer cet attribut (org-admin le peut pour chaque attribut) ;
• un groupe, vous l'avez si vous avez chaque rôle et chaque valeur que le groupe donne ;
• une règle, vous l'avez si l'une de vos propres règles autorise la même chose, sur les mêmes éléments, et qu'aucune règle de refus n'en retire une part.

Une attribution refusée ne change rien, et OS indique ce que vous n'avez pas. Une invitation est vérifiée à l'envoi et de nouveau à l'acceptation.

Vous ne pouvez pas écrire de règle de refus sur la gestion (organisations, membres, invitations, groupes, rôles, règles et attributs). Une telle règle pourrait aussi retirer des droits aux administrateurs eux-mêmes. Sur les fonctions d'IA, vous pouvez refuser.

Dans le service de l'organisation¶

Tout ce que les rôles, groupes et règles permettent ne vaut que dans le service de l'organisation : ce que contiennent ses offres et ses exceptions. Une règle sur quelque chose qui ne fait pas partie du service n'autorise rien. Le service rend donc les rôles plus petits, jamais plus grands, et une règle de refus s'applique toujours.

Qui attribue un rôle propre, un groupe ou une règle qui dépasse le service reçoit 403 avec This is not part of your organisation's service, avant même de vérifier que vous avez ce que vous donnez (ci-dessus). Les rôles intégrés peuvent toujours être donnés : ils sont identiques partout et le service ne fait que les réduire. La gestion propre de l'organisation (membres, invitations, groupes, rôles, attributs, règles, journal d'audit et lecture du service) fait toujours partie du service (Toujours dans le service).

Ce que vous voyez dans OS¶

OS affiche boutons et menus exactement pour ce que vous pouvez faire, dans le service de l'organisation : pour chaque élément, il indique quelles actions vous pouvez y faire, et pour chaque type, quelles actions vous pouvez faire sur au moins un élément de ce type. Ce que vous ne voyez pas, vous n'avez pas le droit de le faire. La façon dont un programme lit cela figure dans L'API d'accès.

Le journal d'audit¶

Chaque modification des personnes, groupes, rôles, attributs, règles, invitations et paramètres d'une organisation va dans son journal d'audit : quand, qui, depuis quelle organisation, et ce qui a changé. Le journal d'audit ne contient ni mots de passe, ni clés, ni adresses e-mail. Voir Lire le journal d'audit.