tchak
commented
2 years ago Nous avons eu une longue discussion avec @mfo sur l’état des revisions avec les modèles d’attestations. Je vais parler ici des modèles d’attestations, mais le même problème se pose pour les emails de changement d’état. Nous avons fait un constat : quoi qu’il arrive, un des acteurs impliqués dans la démarche va devoir gérer les conflits entre les revisions.
Il y a trois rôles directement impliqués dans les processus qui nous intéressent : usager, instructeur et administrateur. Et par conflit on entend essentiellement deux changements sur les champs qui ne peuvent pas être résolus automatiquement – l’ajout d’un champ obligatoire (ou la transformation d’un champ optionnel en champ obligatoire) et le changement du type de champ qui essentiellement nous force à réinitialiser la valeur du champ.
Jusqu’à présent, nous avons fait le choix de limiter les “rebase” des dossiers à des revisions qui ne mènent pas à des conflits. Ça implique qu’une démarche peut avoir en parallèle des dossiers en construction et en instruction sur plusieurs revisions. Ça a un impacte sur les modèles d’attestation (et les emails de changement d’état). Comme mentionné plus haut, nous devons étudier le problème du point de vue de chaque acteur.
Du point de vue de l’instructeur, il peut se retrouver à devoir instruire un dossier qui est sur une revision incompatible avec les dernières modifications du modèle d’attestation. On peut l’avertir, mais l’instructeur (à part le cas exceptionnel où il est aussi administrateur) ne peut pas intervenir sur le modèle d’attestation. Il me semble que l’instructeur est la mauvaise personne pour gérer les conflits.
Du point de vue de l’administrateur, on peut l’avertir lors de la modification du modèle d’attestation qu’un certain nombre de dossiers "en construction" ou "en instruction” sur les revisions précédentes ne bénéficieront pas des changements. On peut lui proposer de modifier les modèles d’attestation correspondant aux revisions précédentes (uniquement les revisions avec des dossiers qui seront impactées). Le problème est que ça sera toujours une opération confuse pour l’administrateur. S’il ajoute un champ obligatoire utilisé dans le modèle d’attestation, il sera surpris qu’on lui demande aussi de créer un modèle d’attestation qui ne comporte pas ce champ. De plus, les dossiers peuvent être déposés entre le moment de modification du modèle d’attestation et le moment de la publication du nouveau modèle – dans ce cas-là ça devient le jeu de la taupe !
Enfin, si on dit que la responsabilité de gérer le conflit revient à l’usager, il faut toujours "rebase” les dossiers “en construction" (et "en instruction” ?). Les champs avec des conflits doivent être annotés et présentés à l’usager pour review. On peut notifier l’usager et on va devoir aussi bloquer les passages d’état jusqu’à ce que les conflits soient résolus.
Il nous a semblé que la dernière solution est la plus naturelle et qui va crée le moins d’incompréhension. Elle a le bénéfice aussi de faire en sorte qu’au moment d’être traités les dossiers soit toujours présentés sur la dernière revision. Comme nous avons vu, les conflits qui nécessitent une intervention de l’usager sont relativement rares. Dans l’état “en construction" l’idée que l’administration demande un usager de compléter le dossier est parfaitement acceptable. Il me reste des interrogations sur l’état “en instruction”. J’ai plusieurs pistes, mais déjà si on arrive à résoudre l’état "en construction”, les instructeurs auront une porte de sortie – repasser le dossier "en construction” et attendre que l’usager corrige les conflits.
Pb au support, les admins ont fait une modif de l'attestation en incluant des nouveaux champs.
Du coup, l'attestation est incohérente pour les anciens dossiers.