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 :
Mis à jour par 
Mis à jour par 
Mis à jour par