Add David et Sebastien among the recipients of the email about the build status for the build version construction and the version release of Silverpeas (details)
Disable the build of the Docker image of a testing version of Silverpeas when releasing a version of Silverpeas (details)
Update the pipeline for building a build version of Silverpeas Mobile so that the project isn't build if either Silverpeas hasn't be updated since the last build or there is no change in code (details)
In the pipeline for building a build version of Silverpeas, fix a bug when testing whether the quality analysis has to be executed for Silverpeas-Core (details)
In the pipeline to release a version of the Silverpeas Project POM, take into account the jcr access-control dependency isn't anymore declared in the Silverpeas projets dependencies (details)
In the release pipeline of the Silverpeas platform, enabled the build of (details)
Add David et Sebastien among the recipients of the email about the build status for the build version construction and the version release of Silverpeas
Update the pipeline for building a build version of Silverpeas Mobile so that the project isn't build if either Silverpeas hasn't be updated since the last build or there is no change in code
In the pipeline to release a version of the Silverpeas Project POM, take into account the jcr access-control dependency isn't anymore declared in the Silverpeas projets dependencies
6.4.1 has been released from build 6.4.1-build240624 (57cd88f94d1c7d02631e3576c8e5f8f174a959ce).Prepare for development iteration of next version 6.4.2 (details)
In some context, when a newsletter has a rich content full of text, with (details)
Fix bug 14243. The __isComponentType function refers an unknown variable (details)
In the VariableScheduledValueTest unit test, the time zone in which the (details)
Fix bug #14244. The error comes from the event is propagated (details)
Update the receiver of mails in the Jenkinsfile (details)
Update in the VueJS components wrapping form input elements: add support to the placeholder attribute to all the form input elements (details)
Fix an error reported by Sonar: duplication of the mounted callback defined by the vuejs mixin VuejsFormInputMixin in silverpeas-vue.js (details)
Objects used in the test of logging used incorrectly Awaitility to simulate the time spent by a method treatement: replace the atLeast call by the pollDelay one (details)
Fix bug #14479 by setting explicitly the current requester as the author and the current date as the creation date when saving the comment in database (details)
Fix a bug in NodeDAO#storeRow in which the setting of the node id and of the instance id have been inversed in the update SQL request (details)
bug #14549: popup window and labels adjustments done (details)
In SilverpeasRole add a new constant, NONE, to replace the use of null for no role played by a user (details)
Fix unit test SilverpeasRoleTest to take into account of the new value SilverpeasRole#NONE and fix some of the SilverpeasRole methods to take into correctly this new value (details)
6.4.1 has been released from build 6.4.1-build240624 (57cd88f94d1c7d02631e3576c8e5f8f174a959ce).Prepare for development iteration of next version 6.4.2
In some context, when a newsletter has a rich content full of text, with the regexp to detect potential SQL injections, we can have false positive. This fix is to involve some regexp for SQL injections so that they can be more accurate to identify a possible injection attack and hence to reduce the false positives.
Fix bug 14243. The __isComponentType function refers an unknown variable in its scope: componentType. __isComponentType is renamed to __componentTypeChecker accepting as argument the variable componentType and then returns a function working on this variable.
In the VariableScheduledValueTest unit test, the time zone in which the datetime are created isn't taken into account when asserting the period of validity of a variable, despite the datetimes in a Period object are stored, and hence returned, in UTC. Fix this.
Fix bug #14244. The error comes from the event is propagated asynchronously and in come circumstances the completedOptions.store.deferred can be not set when the callback on the event 'storage:end:store' is executed (in this case, the callback on the 'storage:start:store' event isn't triggered before as expected).
In the backoffice, the VueJS component driving the management view of the spaces and components expects the current app instance id to be set when the view body is on the rendering of a given app instance.
But, in the case of a creation, update or rank move of an app instance, once the operation done, when the control flow is passed to render the app instance info page, the current app instance id isn't set and then the VueJS component redirect the rendering of the view body to the parent space info page instead.
In order to render the app instance info page in the context of these operations, it is required to redirect to a switcher: a web page in which the control flow is passsed to a JS component controlling the backoffice view (spAdminWindow) that will then update indirectly the VueJS component and hence the view body and space/app navigation tree.
Bug #14277 In order to ensure the password to save is the one that was checked, the password that was effectively checked is cached under an autogenerated key that is sent back to the client that asked for check. The client, in the case the password satisfied all the password rules, sends to the server the check key with the password to save. If the key doesn't match any cache entry or if the password in the cache (hence the checked password) doesn't match the password to save, then an Authentication exception is thrown.
The SilverpeasBeanDAO interface allows to pass directy an SQL where clause to filter the beans to get or to remove. This is an open door to SQL injection and we cannot account to the UI or to the service layer to check the where clause. Some of the where clauses come from directly the web layer and as such a user can rewrite the clause before this one is sent to Silverpeas.
In order to avoid this vulnerability, the direct where clause is replaced by a BeanCriteria that imposes the business layers to decode the expectations coming from the web layer into a BeanCriteria before passing it to the SilverpeasBeanDAO object. The BeanCriteria object represents all the criteria the beans to get or to remove have to satisfy.
Because, the value of a criterion can be a subquery dedicated to attempt an attack, BeanCriteria uses a PreparedStatement in which the parameters are set by using the corresponding interface of the PreparedStatement. This would prevent such attempts because it encodes the textual values.
The search by a form is performed against the indexes. When a field of a form is of type PdC, the field is valued with one or more positions on the PdC by using two differents separators (one to separate two values of a given position and another one to separate two different positions) and this value is then indexed/searched under the index attribute '<name of the form>##Positioning'. Hence, the search on a such field is done by looking for indexes with such an attribute having a value matching exactly the one searched. This means the index entries in which the attribute contains at least the searched value aren't returned by the Lucene search engine.
In order to fix this, for the PdC field, the value to search is rewritten so that to be a regexp understandable by Lucene. In order to centralize this rewritting, all the code building a QueryDescription for a search by a form (coming from an XML publication template) is now centralized into the QueryParameters object. Hence this object is used both by the search on the PdC (by a search form of a publication template), and by the Users Directory component.
Fix a bug in the search on WYSYWYG contents of a form field. The bug comes from a mismatch between the name of the component managing the users in Silverpeas (and used by the indexation) and the name of the Directory component when using the publication templates to define additional information about the users. Now, the name of both is "users" and this name is used both by the user indexation and by the user directory. For doing, a migration step for the FormTemplate component has been defined.
Take the occasion also to improve some codes (as reported by SonarCloud).
When fixing the bug #14254, a regression has been introduced: * the user is an administrator or a component manager * in the app, it can ask to modify it * in the app admin page, when he validates his changes, a javascript error is raised blocking the loading of the admin page in readonly mode.
Now, according to where the user is (either in the backoffice or in the front office), once the app parameterizing is done, the view is updated to the app admin page in readonly mode.
In anonymous mode, the redirection to the contribution referred by a notification wasn't done correctly when the user isn't authenticated: * if the user isn't connected, it recieves an access forbidden (normal as it is not yet connected) * and once he signs in, he's redirected into the main page instead of the contribution.
Now, when the user accesses from the notification (email) to Silverpeas, he's automatically redirected into the login page for authentication. Once authenticated, he's redirected into the page in which is displayed the contribution referred by the notification. For doing, in the authentication process, in the session is opening, the computation of a possible redirection URL takes into account now of the parameters of redirection. Those parameters are set by AutoRedirectServlet when the user accesses first, from the notification (email), to Silverpeas. In our case, this is this servlet that redirects the user to the login page.
In anonymous mode, if the contribution targeted by a notification is protected, the user is first automatically redirected to the login page for authentication, as described above. Some times the protection of the contribution comes from its parent container (for example, a topic with specific rights for a publication in a Kmelia): take into account these peculiarities.
Bug #14411 First step in the fix: Only chat between users for whom the chat is enabled can be done now. Obviously, chatting between two users is possible if they are both connected :-) As a reminder, a chat is enabled for a user if the following conditions are met: * the chat subsystem is enabled * the domain in which the user belongs is mapped to a XMPP domain * the user belongs to a group allowed for chatting
Bug #14411 Last step of the fix The feature regression came in the migration of the chatting client from JSXC to ConverseJS. Whereas in JSXC we had to implement ourself the possibility to chat with a non-buddy user (a user not in the roster), this feature in ConverseJS is already implemented but not enabled by default. It can be enabled by setting accordingly the client initialization parameter 'allow_non_roster_messaging'.
Objects used in the test of logging used incorrectly Awaitility to simulate the time spent by a method treatement: replace the atLeast call by the pollDelay one Delete the empty test LoggerAnnotationIT.java
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.
Bug #14518 Add in Administration#synchronizeUser a new boolean parameter to indicate if the synchronization has to be forced, even when no changes are detected. If this parameter is valued at true, and in the case of no changes, then the user is indexed again.
Fix the vulnerability by using now the POST Ajax request to update the status. The servlet accepts only HTTP POST method. The data are sent foth and back in JSON.
Now, in array pane, the max number of lines to render per page is initialized from the Pagination.NumberPerPageThreshold property in the graphicElementFactorySettings.properties ViewGenerator configuration file. So, no need to invoke the 'numberLinesPerPage' property of 'view:arrayPane' if the number of lines per page has to be the default one.
Refactor the FormException exceptions so that they extend now the current SilverpeasException (and not anymore the old and deprecated SilverpeasException). Fix the modified code to satisfy the feedback of Sonar about code issues.
Ramdomly, the integration test SelectionBasketItemDeletingIT fails because the item to remove from the selection basket isn't found although it should be present. Because the cause can be the test context hasn't been completed before the starting of the test, a delay between the context preparation and the start of the test is added
Fix unit test SilverpeasRoleTest to take into account of the new value SilverpeasRole#NONE and fix some of the SilverpeasRole methods to take into correctly this new value
In PdcSearchTopicTrackerResourcePathLoader, the caching of contribution's paths is now done by the contribution identifier and not anymore by the node in which they are located.
With Silverpeas-Kernel, the parameters passed in LocalizationBundle#getStringWithParams are now encoded for HTML when they are String objects. Take into account of this new capabilities in Silverpeas. This means the HTML specific characters in the parameters (like &, > or < for examples) will be encoded in their entity number counterpart (&, > or < in our examples); this shouldn't cause any issue because the destination of such localized messages are dedicated to be rendered in HTML (even for emails).
In Web messages, in order to avoid to encode for HTML all the message text, improve the MessageNotifier#format private static method to apply the encoding for HTML only on String parameters as those are usually passed by the user himself when authoring or editing a contribution.
In user notifications, encode any possible text passed by a user in Silverpeas (the title and the description of a contribution for example). Take care of the difference between the direct notification about a contribution by a user and the user notification mechanism when a contribution is modified or created.
6.4.1 has been released from build 6.4.1-build240624 (f9d0dfc6d24df34a5a0f8f52492cf61bda8f6474).Prepare for development iteration of next version 6.4.2 (details)
Modify Jenkinsfile to take into account the Silverpeas Core project (details)
Fix the previous commit by taking into account the project is build in the context of a PR (details)
Bug #14255: Swapping roles from inheritance for writer and publishers (details)
Bug #14256 Take into account the changes in SilverpeasBeanDAO to prevent (details)
Bug 14335: Error while creating an instance by using API if the folder has an attachment (details)
6.4.1 has been released from build 6.4.1-build240624 (f9d0dfc6d24df34a5a0f8f52492cf61bda8f6474).Prepare for development iteration of next version 6.4.2
Bug #14256 Take into account the changes in SilverpeasBeanDAO to prevent SQL injections. Take advantage of the context to improve a little bit the code touched by the modification. For example, DataWarningException extends now the new SilverpeasException.
When cherry-picking a commit from a PR merged in 6.4.3 branch, invalid method invocation to JdbcSqlQuery was merged. Fix by renaming correctly the method call.
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.
In Kmelia: * Take use of the new constant SilverpeasRole.NONE when the user hasn't anymore a role for a given folder for which specific rights have been set; * When the user accesses again the application (the root folder of the application), the last accessed folder is reset and hence his role
Now, when a classified ad isn't validated, it is not indexable. If a validated classified ad is put in draft (for modification), then its index is deleted. Index is created only for validated classfied ads.
When using the Web messager, prefer to use its capability to apply parameters on the message instead of using the LocalizationBundle#getStringWithParams for that.
When building a user notification about the modification or the creation of a contribution in the different Silverpeas apps, encode for HTML the title/name and the description of the contribution.
6.4.1 has been released from build 6.4.1-build240624 (df6d70ee10c2eeff03d95814f5352340cde3998e).Prepare for development iteration of next version 6.4.2 (details)
6.4.1 has been released from build 6.4.1-build240624 (df6d70ee10c2eeff03d95814f5352340cde3998e).Prepare for development iteration of next version 6.4.2
Remove the WebSite Designer application from Silverpeas. WebSite Designer is an old application that hasn't involved for a long time and that isn't more used by any of ours customers and users. By doing so, fix the vulnerability #14511.
6.4.1 has been released from build 6.4.1-build240624 (1c9460a9becbefaf1acb3e024e789b6f956dc6b5).Prepare for development iteration of next version 6.4.2 (details)
6.4.1 has been released from build 6.4.1-build240624 (1c9460a9becbefaf1acb3e024e789b6f956dc6b5).Prepare for development iteration of next version 6.4.2
6.4.1 has been released from build 6.4.1-build240624 (42f62a777a26e76f7ea6964c5e70d231028e7057).Prepare for development iteration of next version 6.4.2 (details)
Bug #14374 Fix the script 01-jcrSettings.groovy to take into account (details)
6.4.1 has been released from build 6.4.1-build240624 (42f62a777a26e76f7ea6964c5e70d231028e7057).Prepare for development iteration of next version 6.4.2
6.4.1 has been released from build 6.4.1-build240624 (7e4bc53e19c8ce0690ec0ad8ab9f5f5128bf56e7).Prepare for development iteration of next version 6.4.2 (details)
6.4.1 has been released from build 6.4.1-build240624 (7e4bc53e19c8ce0690ec0ad8ab9f5f5128bf56e7).Prepare for development iteration of next version 6.4.2
6.4.1 has been released from build 6.4.1-build240624 (eb51ed57e389d7be21c2270528d314a06147b7a1).Prepare for development iteration of next version 6.4.2 (details)
Update dependency on Silverpeas to version 6.4.2-build240703 (details)
Update dependency on Silverpeas to version 6.4.2-build240705 (details)
Update dependency on Silverpeas to version 6.4.2-build240708 (details)
Update dependency on Silverpeas to version 6.4.2-build240905 (details)
6.4.1 has been released from build 6.4.1-build240624 (eb51ed57e389d7be21c2270528d314a06147b7a1).Prepare for development iteration of next version 6.4.2