A publication is a peculiar contribution in Silverpeas as it can be located in several locations in the same or in different component instances. In this case, we have the original publication along with its all aliases. This capability is used in the Kmelia application. As consequence, the publication is only referred uniquely by its local identifier (its local identifier is its global one), whereas the others types of contributions are identified uniquely by their global identifier that is made up of their local identifier and of the identifier of the application instance they belong to.
Despite this peculiarity, the indexation, the search and the access rights computation treat the publications only by their local identifier, and this can cause troubles when the aliases of a publication (with the original one) are implied. For example, if an alias was removed, then the index in which the alias is referred is simply deleted, despite the fact there is others aliases or, worse, there is the original publication referred by the index.
In the fix, we ensure now that all the treatments are done on both the local identifier of the publication and the identifier of the application instance it belongs to. And, in the management of the indexes of the publications, they are deleted only if there is no more publications (original one/aliases) referred by them. And, in the access rights computation, in the case of a search, we look for the access rights of nodes with specific rights in which is linked the in-checking alias.
In several very peculiar locations in the code, both in JS and in Java, the filename, description or title of an attachment (or of a publication), aren't correctly escaped for HTML rendering. Fix those omissions.
The move of a node was done by deleting and then recreating in database the node with its new location, and this without updating its translations to refer the correct new node.
Replace the deletion and then the creation of the moved node by a simple suitable update: in fact, a move method already existed in the NodeDAO but it wasn't anymore used. This method update accordingly a node details in the database for a node move. The translations of the node are then not lost.
Refine the update of a node in DefaultNodeService by avoiding to retrieve again from the database the current node before update; Get it at first, then use it all along the update process.
A publication is a pueculiar contribution in Silverpeas as iti can be located in several locations in the same or in different component instances. In this case, we have the original publication along with its all aliases. This capability is used in the Kmelia application. As consequence, the publication is only referred uniquely by its local identifier (its local identifier is its global one), whereas the others types of contributions are identified uniquely by their global identifier that is made up of their local identifier and of the identifier of the application instance they belong to.
Despite this peculiarity, the authorization mechanism in Kmelia takes the publication by their local identifier and, in a such context, any access right validation can be incorrect on publication aliases located in a topic for which specific access rights have been set.
Now, the publications, whatever they are (original one or aliases) are taken in charge by both their local identifier and the identifier of the component instance they belong to.
In several peculiar locations, the filename, title or description of an attachment aren't correctly escaped for HTML rendering. Fix those issues.
Refactor the rendering process in AjaxPublicationListServlet in order first to separate in a way some responsibilities, and to fix the issues sent back by Sonar.
By testing the fix of the bug, I discovered a nasty hidden bug in js when adding a new translation for a given topic: when the properties of a topic is rendered, an HTML select element is updated with the translations of the node's properties. If we ask to see the properties of a topic for which its name and description were translated for all of the supported languages, the HTML select element is correctly updated. But, if after we ask to see the properties of another topic for which a translation is missed, then the HTML select element isn't correctly updated for the missed translation: instead of having for the missing translation an identifier of -1, it kept the id of the translation of the previous selected topic for the same language.
![[Jenkins]](/jenkins/static/4fe7b4ec/images/svgs/logo.svg){kind=logo}
