Bug #1339
ferméWorkflow - Champ de formulaire non contrôlé - Champ fichier en anomalie non signalée
0%
Description
Constaté sur version 5.3.2, sur l'extranet du CLARA
Cas rencontré :
Dans un processus de workflow, si un formulaire lié à une action dispose d'un champ de type fichier et qu'on y place un fichier dont le nom local sur le disque dur est très long et supérieur à 100 caractères, lors de la validation du formulaire, l'injection du fichier échoue et le champ correspondant reste vide, mais l'utilisateur n'est en aucun cas prévenu. De plus, et c'est plus grave, le processus n'est pas interrompu et les conséquences éventuellement associées à l'action sont déroulées normalement ce qui peut occasionner certain effets de bords voire des anomalies conséquentes (par exemple si un traitement est déclenché par un trigger alors que la pièce jointe attendue n'existe pas).
Plus généralement :
Ce type de problème existe peut-être sur d'autres types de champs. Il existe peut-être aussi sur d'autres fonctions de formulaires (ailleurs que dans le workflow).
Solution attendue :
Il faudrait au minimum que
- l'utilisateur soit prévenu de l'anomalie avec un message clair qui lui explique quoi faire (ici dans mon exemple que le nom de fichier est trop long, ou incorrect, ou autre cas)
- l'action du workflow soit interrompue, qu'il n'y ait pas changement d'état et que les conséquences ne soient pas exécutées.
C'est un problème majeur pour le CLARA qui travaille avec des personnes qui ne sont pas forcément au fait de ces explications et car cela provoque des anomalies dans leur workflow de publication (blocantes pour chaque procédure démarrée).
Mis à jour par Nicolas Eysseric il y a presque 14 ans
- Statut changé de New à Assigned
- Assigné à mis à Nicolas Eysseric
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
- Version cible changé de Version 5.6 à Version 5.7
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
- Statut changé de Assigned à Closed
- Version cible
Version 5.7supprimé
Les champs de type fichier, image et vidéo sont contrôlés côté client (cf bug #1895).