Nuxeo : Sanity checks

Définition

Pour les considérations générales sur le reporting indépendamment du domaine d'application voir la page: Le reporting et la BI

La bonne gestion de la GED, nécessite de mettre en place des règles, que doivent respecter les documents pour refléter ce que les utilisateurs condidèrent comme la bonne organisation et qui les aidera à se repérer dans la banque de données.

Ces règles doivent être définies, mises en oeuvre et ensuite dans la vie du système une bonne pratique indispensable consiste à vérifier qu'elles sont respectées, ou tout au moins que le taux d'écart n'augmente pas.

Faute d'un contrôle régulier le désordre se réinstallera.

Ce contrôle pourrait utiliser des « sanity checks » qui consistent à poser des assertions sur la base de données, les assertions reflétant les règles qui doivent être respectées. Un rapport est produit avec la liste des documents qui ne respectent pas les règles. Ceci peut servir à faciliter la résolution, à repérer les processus qui ne sont pas bien compris par les utilisateurs ou encore à mettre en place des indicateurs qualité et mesurer la progression des pratiques.

La fondation

Les sanity checks sont matérialisés dans des queries sur la base de données. Ces queries vont faire des listes et des comptages principalement sur les documents. Du fait de la structure complexe du schéma de la base un query sous-jacent affichant la liste de tous les documents est proposé.

Voici une phrase qui présente les documents. Elle s'appuie sur une vue de jointure de la table hierarchy avec elle même pour afficher chaque élément (node) avec son père (parent). La vue s'appelle "Hierarchy_parent_content". Elle rapporte également les propriétés du 'content' associé au node.

En simplifiant, document se compose d'un node 'content' qui a un fils 'file' et un fils 'dublincore', l'état du fichier se trouve dans 'misc', il faut donc référencer les fichiers dont le misc a une valeur de lifecyclestate différent de 'deleted'. <<<A VERIFIER 2013-08-10>>>

Pour l'instant le query ne tient pas compte des versions.

SELECT "Hierarchy_parent_content".*, "dublincore"."title", "file"."filename", "misc"."lifecyclepolicy", "misc"."lifecyclestate" 
FROM 
  "Hierarchy_parent_content",
  "dublincore" AS "dublincore",
  "file" AS "file", 
  "misc" AS "misc"
WHERE
  "Hierarchy_parent_content"."parentId" = "dublincore"."id" AND
  "Hierarchy_parent_content"."parentId" = "file"."id" AND
  "file"."id" = "misc"."id" AND 
  "misc"."lifecyclestate" <> 'deleted'

Avec Hierarchy_parent_content défini par

SELECT "hierarchy".*, "content".* 
FROM
  "hierarchy_with_parent" AS "hierarchy"
RIGHT OUTER JOIN
  "public"."content" AS "content" ON "hierarchy"."nodeId" = "content"."id"

Avec hierarchy_with_parent défini par

SELECT 
  "parent"."id" AS "parentId", "parent"."name" AS "parentName",
  "parent"."primarytype" AS "parentPrimaryType", "parent"."isproperty" AS "parentIsproperty",
  "node"."id" AS "nodeId", "node"."name" AS "nodeName",
  "node"."primarytype" AS "nodePrimarytype", "node"."isproperty", "node"."mixintypes", "node"."isversion"
FROM "public"."hierarchy" AS "parent"
RIGHT OUTER JOIN "public"."hierarchy" AS "node" ON "parent"."id" = "node"."parentid"

• RIGHT OUTER JOIN est utilisé car tous les noeuds n'ont pas de parent mais on veut afficher quand même ces noeuds.
• Les noeuds qui n'ont pas de parent apparaissent avec des champs vides dans leur partie parent.

Des exemples d'indicateurs

1. Nombre de fichiers dont le nom est égal à celui du fichier : le taux doit être le plus faible car on ne maitrise pas toujours le nom des fichiers qui sont envoyés par des entités extérieures, de plus il n'est pas recommandé de modifier le nom des fichiers. Le titre du document sert à nommer le document de manière explicite, et pourquoi pas élégante.
2. Nombre de fichiers zip : ils sont à éviter
3. Nombre de documents sans fichiers : cela peut résulter d'une fausse manipulation.
4. Histogramme des tags
   1. tags utilisés une seule fois
   2. tags ressemblants ou redondants
   3. nombre de tags par fichier

Analyse des Sanity checks

NXSC003 : Liste des documents "sales"

Un document "sale" (dirty) est un document qui a été modifié sans que la version ait été augmentée.

Divers

L'ancêtre

Tous les noeuds de la hiérarchie dépendent d'une racine unique. C'est le seul node de type 'Root', il a pour autre caractéristique de ne pas avoir de 'content' associé.

La copie webdav et le titre des documents

On a observé que lorsque l'on charge des fichiers directement par copie dans le dossier partagé par WebDav la nom du fichier est parfois tronqué.

D'autre part, de manière complétement logique :

1. Lorsque l'on charge un fichier de cette manière, sont titre est égal au nom du fichier.
2. Si par la suite on change le nom du fichier directement dans le système de fichiers, la modification est répercutée sur le titre.
3. Si l'on change le titre dans nuxeo la modification n'est pas répercutée dans le système de fichier.

Il peut être intéressant de connaitre la liste des documents dont le titre est différent du nom du fichier. ( En phase de chargement du système car ensuite il faut justement ne plus faire aucun lien).

---

Retour