Décocher une case doit changer quelque chose.

Le catalogue

La liste est un fichier source.

34 permissions, en 7 groupes, écrites dans le code plutôt que conservées dans une table. Ça a des conséquences que vous voyez pour vrai : une nouvelle permission arrive avec la fonction qu’elle encadre, au lieu d’être une modification de données à appliquer compte par compte, et il n’y a qu’un exemplaire de la liste à lire.

L’éditeur de rôles du portail est dessiné à partir de cette même liste, servie par le serveur qui l’applique. Les mots à côté de la case (« Play back call recordings », « View the whole organization’s call history ») sont donc ceux du code, et non une reformulation plus aimable rédigée des mois plus tard.

Les permissions de la personne qui appelle sont établies à l’arrivée de chaque requête, d’après le rôle vers lequel son compte pointe à cet instant. Une modification à un rôle est donc en vigueur dès la requête suivante, et non le jour où les gens qui le portent se reconnecteront.

Le contrôle

Une case qui ne change rien est pire qu’aucune case.

Dix de ces permissions étaient dans l’éditeur et attribuables pendant des mois sans être contrôlées nulle part. Les routes de messagerie et celles de la boîte vocale ne portaient aucune vérification, si bien qu’un administrateur qui décochait « Send SMS » pour un rôle ne changeait rien du tout : n’importe qui, une fois connecté, pouvait lire tout l’historique de messages de l’organisation, ou supprimer n’importe quel message vocal.

Ça n’a jamais été un client qui atteignait les données d’un autre. Chaque requête était déjà bornée à son propriétaire, et une suite de tests au complet ne sert qu’à le prouver. C’était l’écart entre ce que l’éditeur promettait et ce que le serveur faisait : un défaut difficile à remarquer, parce qu’une route sans barrière répond exactement comme une route qui en a une, pour quelqu’un qui détient tout.

C’est pourquoi la réponse n’a pas été un correctif mais une habitude. Chacune de ces permissions a maintenant un test qui donne à un rôle exactement celle-là, puis vérifie les deux sens : la route qu’elle doit ouvrir, et la route voisine qu’elle ne doit pas ouvrir. Ne vérifier que le refus passerait tout aussi bien contre un serveur qui refuse tout, et c’est le genre de test qui donne l’impression qu’un trou est bouché.

Activer une vérification est un risque en soi, et il a été traité comme tel. Avant que ces routes se mettent à refuser qui que ce soit, nous avons passé un rapport en lecture seule sur les rôles réellement en place, pour savoir lesquels perdraient l’accès à l’instant où le contrôle entrerait en vigueur. Une permission que personne n’avait pensé à cocher, soudainement appliquée, enlève quelque chose à quelqu’un un vendredi après-midi.

Et quand une vérification refuse, elle dit quelle permission manquait, pas seulement qu’il manquait quelque chose. La personne qui cherche pourquoi un rôle n’atteint pas un écran a besoin du nom de la case à cocher, et qui peut modifier les rôles peut lire la liste au complet de toute façon.

Les rôles

Trois qu’on ne modifie pas, et autant qu’on veut qu’on modifie.

Chaque organisation démarre avec les trois d’à côté, et le serveur refuse de les modifier comme de les supprimer. La raison est étroite et bien réelle : les modifier permettrait à quelqu’un de retirer les permissions qui donnent accès à l’écran des rôles (sur le rôle qu’il porte lui-même), et de là, il n’y a plus de chemin de retour.

Ce qu’un rôle système accorde est lu dans le code au moment de la décision, pas dans la copie rangée à côté dans la base. Cette copie est tenue à jour pour ce qui lit les tables directement, mais elle n’a jamais voix au chapitre : une ligne périmée, ou retouchée à la main, ne peut donc pas élargir Supervisor ni rétrécir Agent en silence.

Vos propres rôles sont une sélection dans le même catalogue, et rien d’autre. Une clé qui n’y figure pas est refusée à l’enregistrement plutôt que stockée puis ignorée, ce qui serait le même défaut que les dix, habillé autrement.

Un rôle personnalisé que des gens portent ne se supprime pas dans leur dos. On vous dit combien de personnes l’ont et on vous demande de les déplacer d’abord, parce que le supprimer changerait ce que ces gens peuvent faire sans que personne ait décidé que ça change.

Une chose qu’un rôle ne décide volontairement pas : dans quelles files une personne se trouve. Un rôle dit si vous pouvez créer une file et choisir qui y est. Y être, c’est une propriété de la personne, gardée à côté d’elle plutôt que dans son rôle. Deux personnes aux permissions identiques peuvent donc répondre à des lignes complètement différentes.

Le dernier admin

La modification qui enfermerait tout le monde dehors est refusée.

Retirez « Invite, edit, and deactivate agents » et « Create and edit roles » au rôle que porte votre unique administrateur, et plus personne dans l’entreprise ne peut administrer quoi que ce soit : ni réinviter un administrateur, ni modifier un rôle, ni atteindre la facturation. S’en sortir veut dire que nous allons dans la base de données pour vous, et ça, un client ne peut pas le faire tout seul.

C’est pourquoi la vérification n’est pas un avertissement sur un formulaire. Elle est dans le service par lequel chacun de ces chemins doit passer : rétrograder quelqu’un, le désactiver, le déplacer vers un autre rôle, supprimer un rôle, et modifier les permissions d’un rôle. Un formulaire ne peut barrer la route qu’à un seul écran ; le service est ce que les cinq chemins ont en commun.

La modification des permissions est le cas délicat, et il est vérifié à part. Rétrograder une personne laisse les autres porteurs de son rôle intacts ; décocher une case rétrograde tous les porteurs du rôle au même instant, de sorte qu’aucun d’eux ne peut être la raison pour laquelle le changement est sûr. La vérification va donc chercher un administrateur ailleurs que dans le rôle qu’on est en train de modifier.

Le refus nomme la sortie au lieu de dire non : donnez d’abord un rôle d’administrateur à quelqu’un d’autre, ou gardez l’une des deux permissions sur celui-ci.

Quand une modification de permissions passe, tous les porteurs du rôle doivent se reconnecter. L’autorisation, elle, avait changé à l’instant où la ligne a été écrite ; la reconnexion sert à ce que personne ne travaille encore avec une liste que son logiciel avait mise de côté en début de quart.

À qui sont les données

Quelle organisation vous êtes, ce n’est pas à la requête de le dire.

Tous les clients partagent une base de données, et chaque ligne appartenant à un client porte l’identifiant de l’organisation qui la possède. Cet identifiant est établi côté serveur à partir du jeton de session vérifié, et un gestionnaire de route n’en lit jamais un dans le corps d’une requête ni dans une chaîne de paramètres. Il n’y a aucun champ à trafiquer, parce qu’il n’y a pas de champ.

Un deuxième garde-fou se tient derrière celui-là, et il existe à cause du comportement de la couche de données plutôt qu’à cause de ce qu’une personne pourrait envoyer : un filtre absent y est traité comme aucun filtre. Une requête qui arriverait sans organisation est donc refusée net, au lieu d’avoir le droit de s’exécuter avec la condition tombée en silence.

Et il y a une suite dont le seul travail est d’essayer : la session d’une organisation lancée contre toutes les routes derrière lesquelles vivent les données de l’autre, d’un coup, en exigeant que tout échoue. Elle exige aussi comment ça échoue : en « aucun enregistrement de ce genre », et non en « pas permis ». La deuxième réponse confirmerait que l’enregistrement existe.

Les sessions des clients et celles de la console depuis laquelle nous administrons les clients sont signées avec des clés différentes. À dessein, pas par souci d’ordre : puisqu’une condition absente veut dire aucune condition, un jeton correctement signé mais sans compte nommé correspondrait autrement au premier compte venu. Des clés séparées font qu’un tel jeton échoue à la signature et n’atteint jamais le code qui aurait eu à s’en apercevoir. La deuxième clé est dérivée de la première plutôt qu’ajoutée comme un autre réglage, pour qu’il n’y ait aucune façon de déployer sans elle.

Pas un rôle

Une partie de tout ça relève de l’organisation, pas du rôle.

Un rôle est la mauvaise forme pour deux de ces questions, et s’en servir quand même, c’est ainsi qu’un modèle de permissions devient un endroit où la réponse dépend de l’écran par lequel on est entré.

L’enregistrement est le cas net. Que les appels soient enregistrés ou non est un réglage unique pour toute l’organisation (toujours, au choix de la personne qui répond, ou jamais), avec un deuxième interrupteur pour dire si elle peut arrêter un enregistrement déjà en cours. Le rôle décide qui peut appuyer sur enregistrer et, séparément, qui peut réécouter après. La politique décide si appuyer était même une option.

Ce que ça ne fait pas

Les gens se connectent avec un courriel et un mot de passe conservés ici. Il n’y a rien à raccorder à ce que votre entreprise emploie déjà pour laisser entrer son monde : un compte Ringfully se crée ici et se retire ici. Et le retirer est justement une chose à ne pas oublier quand une personne part, parce que rien à l’extérieur ne le fera pour vous.

Une permission veut dire la même chose partout où elle s’applique. À part votre propre historique d’appels contre celui de l’organisation, il n’y a pas de tranche plus fine à distribuer : un rôle qui voit les contacts voit tout le bottin, pas le coin d’une seule équipe. Si ce qu’il vous faut est un rôle qui n’atteint qu’une partie de l’entreprise, c’est un vrai manque et non un réglage qu’on aurait caché.

Rien ici n’est temporaire. Une permission reste accordée jusqu’à ce que quelqu’un la décoche ; il n’y a pas d’accès qui s’éteint de lui-même vendredi, et rien ne demande à un deuxième administrateur d’approuver le changement avant qu’il prenne effet.

Et les rôles appartiennent à une seule organisation. Il n’y a pas de bottin de groupes ailleurs d’où tirer les appartenances, et pas de rôle écrit une fois puis poussé vers plusieurs comptes : qui porte quoi se règle dans le portail, par une personne, entreprise par entreprise.

Si l’un de ces points est ce sur quoi votre examen va vraiment bloquer, dites lequel dans le premier courriel. Je préfère vous dire où ça en est réellement plutôt que vous laisser le découvrir au deuxième appel.