Project

General

Profile

Actions

Bug #5479

closed

Incohérence lors du déplacement d'un fichier versionné

Added by Nicolas Eysseric over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
High
Category:
Fichiers joints
Start date:
04/16/2014
Due date:
% Done:

100%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
5.12
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

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.


Related issues

Related to GED - Support #5637: ouverture de fichier impossibleClosedDavid Lesimple05/28/2014

Actions
Actions #1

Updated by Nicolas Eysseric over 7 years ago

  • Status changed from New to Assigned
  • Assignee set to Yohann Chastagnier
Actions #2

Updated by Yohann Chastagnier over 7 years ago

  • Status changed from Assigned to In progress...
Actions #3

Updated by Yohann Chastagnier over 7 years ago

  • Status changed from In progress... to Resolved
  • % Done changed from 0 to 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é.

Aucun script de reprise de données n'est à ce jour prévu.
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 :
Actions #4

Updated by Miguel Moquillon over 7 years ago

  • Status changed from Resolved to Closed
  • Target version changed from Version 5.13.5 to Version 5.14.1
Actions #5

Updated by Yohann Chastagnier over 7 years ago

  • Status changed from Closed to Resolved
  • Target version changed from Version 5.14.1 to 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.

Actions #6

Updated by Miguel Moquillon over 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF