Ce que vaut un historique de validation

Ce qui est écrit lorsqu'un client prend une décision

Une décision depuis le portail client écrit trois choses en une seule transaction. Une ligne de décision sur la validation, avec le verdict - validé ou modifications demandées - le commentaire, un type d'acteur portail et aucun identifiant d'utilisateur. Une ligne d'audit dans le vocabulaire propre au studio indiquant que la validation a été validée ou que des modifications ont été demandées, avec le commentaire. Et la validation elle-même est marquée comme décidée avec l'heure.

Une fois l'écriture sécurisée, une deuxième ligne d'audit enregistre que la décision est passée par le portail client : quel accès, quelle session et quel cycle de révision l'a reçue. C'est seulement à ce moment-là que les membres du studio sont notifiés, de sorte qu'une panne de messagerie ne puisse jamais annuler un verdict, et le tableau se déplace selon les règles propres au workflow.

Une décision qu'un producteur enregistre du côté du studio écrit les mêmes lignes avec l'identifiant d'utilisateur du producteur et un type d'acteur utilisateur. Les deux ne se trouvent jamais sur la même ligne, ce qui permet au studio d'affirmer avec certitude si le client a appuyé sur le bouton ou si le studio l'a fait sur sa parole.

Quelle version

La question de la version trouve sa réponse dans le cycle de révision. Un cycle correspond à une review d'une version, ouverte une fois et fermée une fois par un seul verdict, sans jamais être réouverte. Lorsque le client prend une décision depuis le portail client et que la tâche de validation a un espace de review ouvert, le verdict est enregistré dans cet espace, et la ligne d'audit de la décision du portail nomme le cycle. Le cycle nomme la version.

Le portail client lui-même montre au client le numéro de version de ce qu'il regarde, de sorte que le client et le studio lisent le même numéro au moment de la décision. Dans l'espace du studio, deux versions peuvent être comparées côte à côte avec des notes reportées sur la version suivante, de sorte que le cheminement depuis la note sur la version deux jusqu'à la validation sur la version trois est lisible de bout en bout.

Quel accès, et qui était derrière

Un accès possède un libellé choisi par le studio - un client, ou une personne chez le client - et un type : code, lien, téléphone ou e-mail. Un accès ayant requis un code à usage unique par SMS ou e-mail lie la session au numéro de téléphone ou à l'adresse ayant reçu le code, et l'envoi ainsi que toute tentative infructueuse sont audités. La session enregistre l'adresse IP et le navigateur, et l'accès compte le nombre d'appareils distincts qui l'ont utilisé.

Ainsi, l'enregistrement d'une décision indique : accès 'Dana, marketing', type e-mail avec code à usage unique, session ouverte à cette date depuis cette adresse, décision validée à cette heure sur la version trois. Un accès pour l'ensemble du client sans code à usage unique est moins précis, et le studio choisit ce qu'il souhaite lorsqu'il génère l'accès.

Un accès refusé est également enregistré, avec le motif - introuvable, révoqué, expiré, code à usage unique requis - conservé pour le studio et jamais affiché au niveau de l'accès. Un lien qui subit des tentatives répétées est visible dans le journal avant de devenir un problème.

L'ajout uniquement signifie l'ajout uniquement

La table d'audit ne comporte aucun chemin de mise à jour ni de suppression, quel que soit le niveau de l'application, et une vérification lors de la compilation refuse tout code qui en ajouterait un. Une ligne écrite est une ligne conservée. Corriger l'historique implique d'écrire une autre ligne qui le précise, à la manière d'un grand livre.

La trace survit aux personnes qui y figurent. Lorsqu'un compte utilisateur est supprimé, ses lignes sont définitivement supprimées, mais chaque ligne d'audit pointe vers l'utilisateur via un lien défini sur null plutôt qu'en cascade, et l'e-mail de l'acteur a été inscrit sur la ligne au moment de l'écriture. Un an plus tard, la ligne indique toujours qui l'a fait.

La même règle empêche le départ d'un freelance d'effacer le travail d'un studio : les projets, tâches, commentaires, validations et fichiers sont rattachés par un lien qui est défini sur null lors de la suppression, et non en cascade.

Toute la trace autour d'une décision

Une décision est une ligne parmi tant d'autres écrites par le portail client. La trace qui l'entoure comprend la génération de l'accès, avec ses paramètres et jamais ses identifiants ; la remise de l'invitation ; la révocation de l'accès ; chaque entrée et entrée refusée ; chaque code à usage unique envoyé ou échoué ; chaque note publiée ; chaque brief téléversé ; chaque livrable téléchargé ; chaque rappel envoyé, par une personne ou par le système ; et chaque cycle de révision ayant dépassé le nombre convenu, avec le décompte des cycles. Toute modification du nombre convenu de cycles est auditée avec les anciennes et nouvelles valeurs.

Le côté studio du portail client liste chaque accès avec sa première ouverture, sa dernière visite, les appareils distincts et le nombre de validations client enregistrées. Ce tableau est lu à partir des mêmes lignes ; il ne s'agit pas d'une seconde source qui pourrait être en contradiction.

• Décision : verdict, commentaire, type d'acteur, heure, accès, session, cycle.
• Accès : généré, remis, révoqué, connecté, refusé avec motif.
• Autour : notes, téléversements, téléchargements, rappels, cycles dépassés.

Suppression, exportation et ce qui survit

Le propriétaire d'un espace de travail peut exporter tout ce que l'espace de travail possède dans un seul fichier depuis l'écran des paramètres, et peut supprimer l'espace de travail ou son propre compte sans rien demander à personne chez Tasked. La suppression est protégée par trois étapes : la saisie de l'identifiant de l'espace de travail ou du compte, une réauthentification récente et une confirmation indiquant la date à laquelle l'action cesse d'être réversible. Un compte qui est le dernier propriétaire d'un espace de travail actif ne peut pas être supprimé tant que cette situation n'est pas résolue.

Le délai annoncé est de 30 jours. Un espace de travail supprimé est exporté, marqué comme supprimé, puis détruit définitivement 30 jours plus tard par une purge quotidienne ; ce délai est le même que celui indiqué dans les conditions d'utilisation, la politique de confidentialité et l'accord de traitement des données, et un test de build échoue si le code et les mentions publiées ne concordent pas. L'exportation est un fichier zip récupéré via un lien signé d'une durée de vie de cinq minutes.

La piste d'audit survit à la suppression, débarrassée de tout détail d'identification, afin que ce qui s'est passé puisse toujours être démontré. C'est là toute la valeur de l'historique : la validation qu'un client conteste dans un an est toujours là, avec le qui, le quand, la version et l'accès, que les personnes concernées aient encore un compte ou non.