Bug #5479
fermé
Incohérence lors du déplacement d'un fichier versionné
100%
Description
Lors du déplacement d'un fichier avec plusieurs versions, seule la dernière version est correctement déplacée.
Visuellement, les différentes versions sont bien rattachées à la contribution copiée.
Mais lorsqu'on souhaite consulter une version précédente, le lien est incorrect et provoque une erreur :
16:01:17,703 INFO [STDOUT] ERROR : root.EX_CANT_READ_FILE | MODULE : peasUtil.AbstractFileSender.sendFile | Impossible de lire le fichier ( file: D:\Silverpeas\Envs\v5.12\silverpeas\data\workspaces\kmelia2\version_724\1_0\fr\3760088640013.jpg)
L'id de l'application n'est pas bon ainsi que le nom du répertoire du document (ici version_724 au lieu de simpledoc_724).
Sur le serveur, les versions précédentes sont restées à leur emplacement d'origine.
L'usage d'un répertoire version_XXX est surprenant car, par défaut, un répertoire simpledoc_XXX est toujours utilisé !
Le problème ne se limite pas à l'incohérence sur le serveur de fichiers mais également au contenu de la JCR.
Mis à jour par Nicolas Eysseric il y a plus de 10 ans
- Statut changé de New à Assigned
- Assigné à mis à Yohann Chastagnier
Mis à jour par Yohann Chastagnier il y a plus de 10 ans
- Statut changé de Assigned à In progress...
Mis à jour par Yohann Chastagnier il y a plus de 10 ans
- Statut changé de In progress... à Resolved
- % réalisé changé de 0 à 100
Il s'est avéré, au cours de l'analyse de ce problème, que la fonctionnalité de déplacement de document joints versionnés, ainsi que celle de copie, étaient défectueuses.
Au niveau de la copie existaient les problèmes suivants :- les numéros de versions n'étaient pas systématiquement respectés. Par exemple, si l'historique d'un document en terme de version était 0.1, 0.2, 1.0, 1.1, 2.0, après copie, l'historique pouvait devenir 0.1, 0.2, 0.3 ...
- l'i18n n'était pas géré, seuls les contenus de la langue "par défaut" étaient copiés
- les dates de mise à jour des versions d'un document étaient erronées (certaines étaient bonnes, puis d'autres correspondaient à la date à laquelle la copie était réalisée)
Au niveau du déplacement, l'anomalie ici décrite est issue de problèmes au niveau de la modélisation d'un document joint versionné et des services associés. Ces derniers, dans certaines configurations des données et selon la manière d'y accéder, pouvaient effectivement disfonctionner et donner le résultat décrit.
Aussi, les corrections apportées permettent maintenant d'afficher l'historique d'un document par rapport à la langue dans laquelle les contenus doivent être présentés.
Lors de l'intégration des corrections, merci donc de bien vérifier également la copie de fichiers joints versionnés (fichier sans version, avec une version, avec un historique conséquent)(multi-langue et non multi-langue) ainsi que les autres corrections mentionnées.
Pour rappel, le versionnement des documents joints est géré via la JCR depuis la version 5.12 de Silverpeas. Dès lors qu'une information technique ou fonctionnelle est modifiée pour un document joint versionné, cela occasionne la création dans la JCR d'une version dans l'historique des modifications de ce document. Par conséquent et pour un document, il peut exister un delta entre le nombre de versions dans l'historique de la JCR et le nombre de version présentées à l'utilisateur.
Par exemple, la modificaton d'une donnée fonctionnelle, comme la description d'un document joint, occasionne la montée d'une version fonctionnelle (publique ou de travail), et donc, engendre aussi la création d'une version dans l'historique des modifications du document dans la JCR.
Autre exemple, la modification de l'ordre de l'affichage d'un document joint par rapport à un autre, elle, n'engendre pas de montée de version du document. Par contre, même si la version du document joint reste inchangée du point de vue de l'utilisateur, l'ordre d'affichage étant une propriété du document joint lui même (bien que cette données ne soit pas versionnée), une version est tout de même créée dans l'historique de la JCR.
Ces deux exemples illustrent bien l'écart qui peut exister entre l'historique des versions d'un point du vue de l'utilisateur et celui réel dans la JCR pour un document versionné.
Si un problème lié à cette anomalie se présente sur un serveur, il faudra :
- mettre à jour ce dernier avec une version de Silverpeas contenant les correctifs
- effectuer des actions manuelles pour rétablir les données dans la JCR et sur le système de fichiers. Ce point nécessitera notamment la mise en place des outils permettant de manipuler les données de la JCR
Cf. PR :
Mis à jour par Miguel Moquillon il y a plus de 10 ans
- Statut changé de Resolved à Closed
- Version cible changé de Version 5.13.5 à Version 5.14.1
Mis à jour par Yohann Chastagnier il y a plus de 10 ans
- Statut changé de Closed à Resolved
- Version cible changé de Version 5.14.1 à Version 5.13.5
Les corrections ont été portées pour la 5.13.x.
Cf. https://github.com/Silverpeas/Silverpeas-Core/pull/510
Cf. https://github.com/Silverpeas/Silverpeas-Components/pull/307
Aussi, j'ai découvert un autre problème au niveau de la copie d'un document. Les deux PR ci-dessus indiqués, concernant la version 5.13.x, prennent déjà en compte ce nouveau problème.
Le PR https://github.com/Silverpeas/Silverpeas-Core/pull/511 est celui qui permet d'intégrer la correction du nouveau problème détecté sur les versions 5.14.x et 5.15-SNAPSHOT.