Silverpeas » Silverpeas Components » GED

Après avoir travaillé sur cette demande pendant un certain temps, j'ai remarqué un problème de cohérence avec les raccourcis qui vient, en fait, que ceux ci n'existent pas en tant que tel dans le code métier, mais ne sont qu'un simple calcul qui s'avère en plus être faux.
Je m'explique.

Dans Kmelia, les publications sont en fait créés dans l'éther et sont rattachés à un dossier (ou thème dans le jargon de Kmelia) que par le biais d'un alias. On pourrait penser qu'un alias est un raccourcis vers une publication (déjà rien que par le nom même d'alias). Il n'en ait rien. C'est juste un lien d'affiliation entre une publication et son "père", le dossier ; autrement dit c'est un emplacement. Par conséquent, dès qu'une publication est créée dans un dossier, un alias est créé. Dès que l'on choisit pour la publication plusieurs emplacements, ce sont de nouveaux alias qui sont ajoutés, un par emplacement différent. Ici, pas de notion de raccourcis.

• vous copiez la publication d'un dossier à un autre, c'est bien une copie qui est effectuée et rien ne vous permet de distinguer une copie d'un emplacement différent d'une publication (on commence à sentir notre bogue ici).
• vous changez la publication d'emplacement local, ça équivaut à un déplacement
• vous modifiez une publication pensant à une copie, manque de bol, c'est n'est pas une copie, c'est la publication d'origine que vous modifiez.
• vous supprimez une publication d'un dossier pensant à une copie, manque de bol, vous avez supprimé la publication d'origine et elle n'apparaît plus dans aucun emplacement !
• ...

Maintenant, il est possible de désigner un emplacement d'une publication vers une autre GED. Il a été alors choisi, dans l'IHM, de représenter ceci sous forme de raccourcis. Dans le code métier, en fait, c'est toujours un alias et ce qui va dire que cet alias est un alias (sic) c'est que l'instance de Kmelia soit différente de celle de la publication d'origine (un simple calcul et qui est plus est non centralisé et donc répartie un peu partout dans le code). Ce qui est faux. Un raccourcis reste un raccourcis et pas autre chose selon l'instance de l'application. Autrement dit une publication dans un emplacement autre que celui d'origine est un raccourcis vers la publication originale quelque soit l'instance de l'application concernée, puisque, si on veut être cohérent, un raccourcis est censé exister aussi dans une même GED. (Et par extension, un emplacement d'une publication different de celui d'origine est un alias du premier.) Actuellement, dans le code métier, un alias est à la fois un emplacement et un raccourcis mais rien n'est vraiment fait pour différencier un emplacement comme raccourcis vers une publication de l'emplacement d'origine de cette publication.

D'où le bogue : parce que les raccourcis n'existent pas en tant que tel dans le code métier, lorsque, dans une GED donnée, vous copiez un dossier qui contient un "raccourcis" vers une publication (qui n'est pas autre chose qu'une publication dans le code), et vous le collez dans un autre dossier, il y a bien copie de la publication d'origine, que la publication d'origine soit dans la même GED ou dans une autre. Même comportement ; ce qui est cohérent. Donc, pour coller avec la notion de raccourcis actuels, il faut deux comportements différents selon l'instance de l'application concernée ! Ce qui complexifie le code. Ce qui conduit à des bogues. Et ce qui peut amener l'utilisateur à des surprises bien désagréables.

PR https://github.com/Silverpeas/Silverpeas-Core/pull/1003
PR https://github.com/Silverpeas/Silverpeas-Components/pull/661

Voici quelques informations supplémentaires afin de bien cerner ce qu'apporte la correction.

Dans Silverpeas, hors le Plan de Classement (PdC), tout ce qui permet de catégoriser une publication (que ce soit une catégorie dans Blog par exemple ou un dossier dans Kmelia) est représenté par un nœud (un objet Node). Les liens entre les différents nœuds forment un graphe. Une forme particulière du graphe est l' arbre pour lequel un nœud ne peut être relié que par un seul embranchement (un seul père) et les feuilles que par un seul nœud (là aussi un seul père). Cette structuration en arbre est celle communément en vigueur dans les systèmes de fichier et donc dans les arborescences de dossiers ; Kmelia utilise celle-ci. Selon cette structuration, une publication (une feuille) ne peut être que dans un seul dossier (un nœud). Toutefois, la possibilité est donnée de pouvoir définir d'autres emplacements à la publication. Cette opération, afin de respecter la structuration en arbre, consiste à créer un lien virtuel entre la publication dans son emplacement d'origine avec des images d'elle même dans d'autres dossiers : ce sont des alias ou raccourcis. Les liens étant virtuels, la publication n'est pas vraiment dans ces dossiers. C'est pourquoi on parle d'emplacement principal quand c'est le dossier d'origine de la publication (qui peut être déplacé) et d'alias pour les autres dossiers.

Toutefois, à côté de cette structuration en arbre, l'API de Silverpeas supporte n'importe quel type de graphe. Ainsi, il est toujours possible d'associer une contribution (publication, image, ...) à différentes catégories sans notion de catégorie principale et de raccourcis. Dans une telle approche, pour des raisons érgonomique, on prendra soin alors à ce que le nom de la contribution soit unique.