Qui peut valider, et comment le portail le sait

Cinq options sur chaque accès

Un accès au portail comporte cinq booléens : voir, commenter, valider, importer et télécharger. Le studio les définit lorsqu'il crée l'accès, et un accès demandé sans aucune autorisation est en lecture seule. Chaque route du portail déclare l'unique autorisation dont elle a besoin, et un wrapper vérifie l'accès avant l'exécution de la route, de sorte qu'une route n'a jamais à se soucier de cette vérification.

La validation est l'option essentielle pour la signature. La route de décision la requiert ; un accès en lecture seule ou uniquement autorisé à commenter ne peut pas du tout atteindre la route, et la réponse est le même refus qu'obtiendrait un inconnu. La page du portail lit les autorisations de l'accès à son ouverture et masque ce que l'accès ne permet pas de faire, de sorte qu'un client disposant d'un accès limité aux commentaires voit le fil de discussion sans bouton de validation, plutôt qu'un bouton qui échoue.

L'option de voir n'est volontairement pas induite par les autres. Un accès qui permet de valider mais pas de voir est une erreur qu'un studio peut commettre via l'API, et le produit laisse la route de lecture renvoyer un refus pour que le studio s'en rende compte, plutôt qu'de la corriger en silence.

Un accès par projet ou un accès par client

Un accès est dirigé vers un projet ou vers un client. Un accès par projet voit ce projet et rien d'autre. Un accès par client voit tous les projets de ce client. Un accès qui ne pointe vers aucun des deux ne voit rien, et ne peut donc rien décider. Pour savoir si une validation donnée relève de cet accès, il suffit d'appliquer la même règle à l'envers : la validation se trouve sur une tâche, la tâche sur un projet, et l'accès doit être limité à ce projet ou au client de ce projet.

Le projet et le client vers lesquels pointe un accès sont vérifiés par rapport à l'organisation du studio avant que l'accès ne soit enregistré, de sorte qu'un accès ne peut jamais pointer vers une autre organisation, et un projet ou un client manquant renvoie « introuvable » plutôt que de créer un accès avec une référence orpheline.

La tâche de rappel utilise la même règle de portée pour décider quels accès relancer lorsqu'une validation dépasse son SLA, de sorte que l'accès qui reçoit le rappel est toujours un accès qui est en mesure d'agir.

Un accès par personne

Un accès possède un libellé choisi par le studio, comme le nom du client ou d'une personne chez le client. Lorsque le studio crée un accès pour un client sans plus de précision, l'invitation est envoyée à l'e-mail et au téléphone de contact du client. Lorsque l'accès est destiné à une seule personne - le responsable marketing plutôt que l'adresse de facturation - le studio renseigne l'e-mail ou le téléphone de cette personne, et l'invitation y est envoyée à la place.

Pour renforcer le lien entre l'accès et la personne, un accès peut exiger un code à usage unique par SMS ou e-mail en plus du lien : six chiffres, cinq minutes, cinq tentatives, et un nouvel envoi autorisé après une minute. Un accès peut également limiter le nombre d'appareils, de un à vingt. Avec une limite de un, la connexion d'un nouvel appareil transfère l'accès vers celui-ci et met fin instantanément à toutes les autres sessions ; avec une limite plus élevée, seule la session la plus ancienne prend fin. Un même appareil n'est jamais déconnecté : un rafraîchissement de page ou un cookie perdu ne sont pas pénalisés.

L'historique du studio indique, pour chaque accès, combien d'appareils distincts l'ont utilisé. Un accès destiné à une seule personne qui affiche six appareils indique que le lien a circulé, et le studio peut le révoquer et en générer un nouveau dans la même minute.

Lorsque le studio décide au nom du client

Un producteur peut également enregistrer une décision du côté du studio, avec l'accord du client. La ligne de décision contient alors l'identifiant d'utilisateur du producteur et un type d'acteur « user ». Une décision provenant du portail contient un type d'acteur « portal » et aucun identifiant d'utilisateur. Les deux se distinguent à tout jamais dans le flux et dans le journal d'audit, de sorte que « le client a validé » et « nous avons validé pour le client » ne correspondent jamais à la même ligne.

Les validations internes - une étape de validation validée par un producteur ou un réalisateur - reposent sur le même mécanisme, avec un membre du studio comme approbateur et les responsables de la tâche comme personnes relancées en cas d'attente trop longue.

Expiration, révocation et ce que voit le studio

Un accès expire après 30 jours par défaut. Le studio peut définir une durée de 1 à 365 jours, ou choisir explicitement de ne pas fixer d'expiration ; une valeur omise ne laisse jamais un accès permanent ouvert par accident. Un accès révoqué bloque immédiatement l'accès. Un accès révoqué apparaît comme révoqué plutôt qu'expiré dans la liste du studio, car un studio qui a désactivé un lien veut pouvoir le constater.

Côté studio, la liste affiche chaque accès avec son libellé, son état, ses autorisations, sa première ouverture, sa dernière activité, ses appareils distincts et le nombre de validations du client enregistrées. Avant l'existence de cette liste, la seule réponse honnête à « l'a-t-elle ouvert ? » était un coup de fil.

La création et la révocation d'un accès sont auditées, avec les paramètres de l'accès et jamais ses identifiants. Les accès refusés sont également audités, et le motif - introuvable, révoqué, expiré ou code à usage unique requis - est enregistré pour le studio mais n'est jamais présenté à la personne qui tente de se connecter, car une différence dans les refus sert d'oracle pour deviner les accès.

• Accès par défaut : lecture seule, 30 jours, invitation envoyée aux coordonnées de contact du client.
• La validation requiert l'option de validation ; l'interface masque ce que l'accès ne permet pas de faire.
• La portée est d'un projet ou d'un client ; jamais entre plusieurs organisations.