JPlatform 10 SP8 includes 808 changes (issues) distributed as follows:

• 35 new features
• 280 improvements
• 410 bug fixes
• 85 tasks

This article introduces you to the main new features and improvements brought by JPlatform 10 SP8.

1. Content classification

JPlatform is designed to manage all of an organization's content and documents. These items may contain sensitive information that would jeopardize the organization if unauthorized and malicious people had access to them.

JPlatform's already very rich rights management allows you to control who has access to what content. This management is based on accreditation lists (via members or groups), on categories (via the CategoryRight plugin), on membership in collaborative spaces (secret/private) or by other data-specific rules (via RightPolicyFilter). However, this management, which is suitable for many use cases, has its limits for the classification of sensitive content, which requires being able to standardize access levels and apply specific controls according to the level. The new content classification functionality meets this expectation.

1.1 Principles

Content classification is optional and allows you to define standardized classification levels (e.g. Public, Internal, Restricted, Confidential, Secret, ...) that are assigned to all content on the platform. Once activated, it applies to all content (document, Wiki page, article, ...) on the platform. This information is displayed on the content in the form of a small colored badge with the name of the level. This way, users know the sensitivity of each content and how they can use it. A set of levels is offered as standard (Public, Internal, Restricted, Confidential) but you can define the number of levels, labels and colors you want. In the screenshots below, these levels have been prefixed by C0, C1, C2 and C3.

Classification is also to be defined on spaces. The information is displayed in the Tobpar of a workspace:

As well as on the home page of a collaborative space:

In the search interface, a new "Classification" facet allows you to filter search results according to their level of confidentiality:

1.2 Setup

Classification is deactivated by default. If you wish to set it up, go to the property editor, Advanced tab and check the "Content classification" option, then save the properties.

Classification is now activated. Click on the "Configure classification" button. This takes you to the classification management interface, where you can modify functionalities and constraints, audit functionalities/contracts by level, choose levels and other options.

All content and workspaces are classified according to the reference classification level defined in the "Advanced" tab:

1.3 Membership Qualifications

The classification also allows, optionally, to apply access rights to members. This is called clearance. This option is activated in the Advanced tab of the classification management interface.

Once the control of member clearance is activated, you must then define for each member their clearance level. A member will only be able to access content lower than or equal to their level. For example, a member authorized at the Restricted level will be able to see content at the Public, Internal and Restricted levels. But she will not have access to content at the Confidential level. The clearance level is nominative information. It cannot be retrieved from groups (which do not have this concept). However, you can use group processing to assign a level to a group of members.

Permission level-related rights controls also apply to central administrators. To allow administrators to manage and view classified spaces and posts, administrators must be explicitly modified to specify their clearance level.

The control of the member clearance has an impact on the delegation. The delegation of a user A to a user B can only be done if A has a clearance level greater than or equal to that of B. A member A connected in delegation with user B cannot increase the clearance level of user B.

1.4 Feature Control

The classification also allows you to act on the features available at each level. Thanks to this, it becomes possible, for example, to prohibit the sharing of content with external parties (public links) or editing with MS 365 if the content is confidential. The interface presents all the core features and those of the plugins. For each feature, it is possible to indicate up to which level it is available. Beyond that, the feature will disappear on the content concerned.

This table describes the set of JPlatform features that can be disabled depending on the classification level:

This table describes all the plugin features that can be disabled depending on the classification level. The features offered by the plugins will be available as the plugins are released.

1.5 Application of constraints

Classification can also impose constraints depending on the level: e.g. requiring the presence of an access code on a public link or requiring TOTP authentication to access the content.

This table describes the set of JPlatform constraints that can be enabled depending on the classification level:

A two-step authentication (TOTP 1.3 plugin) can also be imposed to access content according to its classification level.

1.6 Audit of levels

The Audit tab provides a summary of features and constraints for each level. It is also possible to list the members who have access to a given level by going to the Audit tab of the classification management interface.

1.7 Definition of levels

The number of levels, their color and description are fully configurable:

It is possible to determine the default classification level of content on the site. In addition, it is also possible to specify this level more precisely for a particular workspace. It is even possible to impose a minimum classification level in a dedicated workspace (for example, a workspace containing particularly sensitive content).

In the case of collaborative spaces, the choice of classification level is made from the configuration interface.

If you increase the minimum classification level of a workspace, this will cause the classification level of any posts that have a level lower than the new minimum level to be updated.

2. Content profiling

Providing the right information to the right person is a key point to facilitate the adoption of intranets. To this end, content profiling consists of filtering the information distributed according to the user's profile. The user profile can be defined along several axes: the job, the geographical location, the hierarchy, .... For example, with profiling, a person from the Marketing department based in Paris will be able to see different information from another person based on a production site in Toulouse.

Profiling is similar to but distinct from JPlatform's audience rights function. The latter applies rights according to profiling axes. The difference with profiling is that even if the information disseminated is filtered according to the profile, it remains consultable, for example by a search.

2.1 Principles

Profiling axes are defined by category trees. You choose the number and nature of profiling axes you want. However, it is recommended not to exceed 4 profiling axes.

Profiling can be applied to any type of content that can be categorized. The profiled content must be categorized on these axes. JPlatform then takes care of matching the member's profile with the content categories.

2.2 Example

Let's take two profiling axes represented by the category trees below:

• Business Axis
  • All departments
    
    • Purchase department
    • Technical department
    • Accounting department
    • Marketing department
    • HR department
• Geographical Axis
  • World
    • Asia
      • China
      • Japan
    • Europe
      • Germany
      • France
        • Alsace
        • Brittany

And let's take 3 members:

• Alice works in the Purchase department in Alsace .
• Bob works at the Technical department in Brittany .
• Carl works at the China Technical department .

In profiled displays:

• An article intended for All departments in France , will only be visible to Alice and Bob
• An article intended for the Technical department, regardless of the geographical area ( World ), will only be visible to Bob and Carl.
• An article is intended for Asia, will only be visible to Carl

2.3 Implementation

Currently, this feature requires the ESN module. In a future version, this dependency will no longer be necessary.

To enable profiling in JPlatform 10 SP8, go to the Property Editor, in the Users tab and in the Profiling section, select one or more category trees representing the axes.

Members then enter their profiling on their profile page. In a future version, it will be possible to define standard profiles by group. 

Then, create (or edit) a Publication List portlet by checking the "Refine with Profiling Categories" option.

Insert this portlet into a portal page and it will display user profiled content.

3. Analytics

3.1 Improved graphics rendering

Until now, for periods below the month, the time scale on time charts was not always very readable, because it presented dates and times sometimes not aligned with the data displayed. Starting with JPlatform 10 SP8, the scale is now systematically in days and consistent with the data presented.

3.2 Export metrics to CSV

To go beyond what JPlatform offers in usage analysis, and to do other analysis, it may sometimes be necessary to use other tools. But for this, you need to have the data. Now, on each metric you can export all the values available on this metric in the form of a CSV file that you can then open with a spreadsheet (Excel, LibreOffice) or a BI tool. The export is offered in the "..." menu.

3.3 New filtering periods

In addition to the periods already proposed and covering the last 7, 30 and 90 days, the interface also offers the last 3 months, the past year and the current year.

3.4 Unauthenticated access ignored by default

Finally, by default, unauthenticated accesses, such as those from indexing robots, are no longer taken into account.

If you still want to take them into account again, you must set the following property:

analytics.display-anonymous-visitor: true

4. Other functional improvements

4.1 Video player

On the video player, you can increase or decrease the playback speed of videos.

If you have the Video plugin you can chapterize the video. Users will see the chaptering on the playback bar and can quickly jump from one chapter to another.

You can also retrieve a link to a specific passage in the video by right-clicking in the video and clicking on the "Copy video link from this sequence" button. The person who opens this link will automatically be positioned at this position in the video.

4.2 Sharing content

When you share content with members, a small message appears confirming that the content has been shared.

Additionally, it is now possible to hide recipients so that they do not see who the sharing was done with.

4.3 Improved rich text fields

Improved in-page editing

JPlatform allows you to edit the content of a "Rich Text" (ie Wysiwyg) field directly where you are viewing it, by clicking on the Edit button. When the area is small, you can switch the editor to full screen for more writing comfort. Once your changes are made, you must remember to exit full screen mode to save these changes.

With JPlatform 10 SP8, you can trigger recording directly from full screen mode and continue writing.

New version comparison mode

JPlatform manages the versions of the contents that are modified. It is thus possible to consult all the modifications that a content has undergone. It is also possible to compare 2 versions to see the fields that have been updated. When this modification concerns a field of type "Rich text" (or Wysiwyg) until now JPlatform presented the different changes (addition and deletion of text) directly in the body of the text. And this on the raw text or the HTML code. It was therefore not always easy to see where the change was located in the page.

JPlatform 10 SP8 offers a third way to present the differences: by comparing the 2 formatted versions side by side.

4.4 New Media Library

When you create content, you can insert images, or videos and open the media library. With version 10 SP8, it has been redesigned to be even easier to use.

The interface has been refined. Different filters are offered (text, space, type, ...). Adding media is done by a simple drag and drop in the area or by clicking on the "Add" button.

By clicking on the Eye icon that appears when hovering over a media, a detailed view of the media appears:

The media library can also connect to other image sources, such as Giphy or Unsplash. You can find them in the menu to choose the space, at the very end in the "External services" section. To do this, you must install the plugins offering the connection with these external media services.

4.5 Creation and modification by default in modal

Many types of content offer a dedicated page or modal for creation and modification. This is for example the case for JNews articles, JEvent events, Flash Info, JGallery albums, ...

Until now the menu for adding the Publication List portlets opened the advanced form. However, this form opens as a pop-up and is quite complex. And for many types of content it is more convenient to use the dedicated modal.

Starting with JPlatform 10 SP8, the "Publications List" portlet add menu now opens the modal associated with the content type. This can be the modal specific to that content type, or the modal automatically generated for that content type.

Example of a generic editing modal:

It is possible to disable this behavior to restore the old popup editing, by setting the property templates.edit.use-popup-and-front to true.

4.6 Improvement on documents

Document submission areas have been expanded to facilitate drag-and-drop submission:

Document display has been centered to improve readability:

JPlatform allows you to ask users to confirm that they have read a content. This is done by activating the reading confirmation on a content (from the reader tracking interface). A confirmation area then appears under the content. Due to this position, users could not see it. It is now displayed above the document.

By default, when uploading a file, JPlatform replaces underscores ("_") with spaces to create the document title. And when uploading the document, since it is based on the title, underscores are not preserved. This bothers some users who have naming rules that include the use of underscores. The file-document.title.replace-underscore property controls whether underscores should be replaced or not. The property defaults to true to keep the existing behavior.

4.7 Other improvements

The Trash Bin offers bulk operations on documents that have been placed in it, so you can quickly restore or permanently delete a whole range of content at once.

The interface for uploading your profile photo has been simplified: the user chooses the photo, the cropping window appears with a circle representing the cropping area, it saves and the photo is updated.

The search results display shows both the content corresponding to the searched text but also two small cards to the members' directory and that of collaborative spaces with the number of results corresponding to this search.

With public links, you can share documents from your intranet with external people. The sharing interface has been improved to provide clearer indications when you have just created a public link:

When you add content for bulk processing, an icon appears in the Topbar with the number of contents added. Now, when you click on this icon, a menu appears and offers to access the bulk processing management interface or to empty the bulk processing. In the future, other functions may be offered in this menu.

When a user does not have a photo, his initials are displayed as a photo. To encourage him to put a photo on his profile, a camera icon appears permanently on his initials in the sliding window that opens when you click on the photo in the Topbar and in his profile page (ESN plugin).

The category management interface has been simplified by grouping the actions that can be performed on each category in a contextual menu.

And it is possible to force alphabetical sorting on a set of categories via bulk processing processing

5. Administration

5.1 Workflow

In the workspace type management interface, the choice of the Workflow to use is now made with a menu with a search box.

In the Workflow template management interface, you can display all the spaces in which a workflow is used with one click.

5.2 Members and Groups

New filters have been added in the list of members and groups in the back office:

New filters on members

LDAP Synchronization: Filters local members or those synchronized with LDAP.

New filters on groups

• Workspace/Transverse: Filters transverse groups or workspace groups.
• Organization: Filters on the groups that make up the organization's group tree / organization chart.
• Visibility: Filter on the three possible group visibility types: default, members or admins.
• LDAP Synchronization: Filters local groups or those synchronized with LDAP.

Deleting a member's photo when disabling them

To comply with GDPR, it may be necessary to remove the photo of a member whose account is disabled. This is now possible by setting the property member.photo.delete-on-disable to true (it is at false by default).

Deleting a space admin

It is now possible to delete a member who is a space administrator provided that he is not the last active administrator of a space.

Auditing application launchers

Members can add, remove, and reorder apps in their app launcher. A new tool, accessible from the App Catalog, is available for admins to audit a member's app launcher and restore the default launcher if necessary

Time zone support enabled by default

Time zone support was introduced in JPlatform 10 SP1 to allow entering and displaying dates and times in the user's time zone. It is now enabled by default. You can disable it by setting the channel.timezone.enabled property to false.

5.3 Organization of plugin properties by section

Some plugins may have many properties for their configuration. It is then not always easy to find your way around, especially since the properties that are linked are not necessarily placed one after the other.

With JPlatform 10 SP8, plugins can now present their properties organized in sections. The documentation for organizing your plugin properties by sections is available here: https://docs.jalios.com/jplatform10/jcms/fr/front-end/plugin-properties-388743

6. Security

6.1 Sending a message to the delegation

When using another member's account via delegation, you can enter a message that will be sent to that member informing them why you are using their account.

The member concerned then receives a security notification (already existing since JPlatform 10 SP4), enriched with the message entered:

6.2 Rights check: access for all

The interface for checking rights on a publication is now accessible to any member who can view the publication.

6.3 Managing Access Tokens

The management of access tokens, authentication keys (authkey) and JSON Web Token (JWT) has been revised to allow better management of these.

A new management interface allows you to create tokens, track their usage and revoke them if necessary.

The interface for creating a new token has also been improved. After choosing the type of token to create:

All you need to do is fill out the form:

6.4 Limit workspace sharing rights

Until now, it was possible to limit the use of workspace sharing to certain members by an ACL. And any member who had this right could share or share any content to which he had access in any workspace in which he was a contributor.

Requests have been made for finer control: to be able to limit workspace sharing to those who have the rights to publish the same type of content in the target space. That is to say, Alice will only be able to share (or share) an article in space E1 if she has the rights to publish articles in E1. This new feature is not active by default. If you want to activate it, you must set the property publication.attach-ws.check-pub-rights to true.

6.5 Message to users when a file is renamed

For security reasons, some files, such as SVGs, are automatically renamed by JPlatform. When this happens, the user is warned by a message:

6.6 Limit the right to activate portlets from JPortal

From the simplified editing interface of JPortal, it is possible to add new portlets. The activation of a new type of portlet in the space is then done automatically. But in some cases, we want to better control these activations of new portlets. Also It is now possible to limit the people who can make these portlet creations with the ACL "Creation of portlet in simplified edition".

7. JStore

7.1 New generational Store to manage very large volumes of writings

JPlatform stores the structure data (workspace, group, category, portlet, ...) as well as the members in the Store. The Store manages all of its data in memory and ensures their persistence in the file store.xml. This file does not contain the data but all the write operations that have been made on this data (creation, modification and deletion).

There is a limit if the file size store.xml exceeds 2 GB. By default, JPlatform uses the Java NIO API to read this file. However, this API cannot read files larger than 2 GB. Beyond that, you must use the Classic IO API, but it offers lower performance. This impacts the loading of the store, access to the history and especially the performance of synchronizations in a JSync cluster.

JPlatform 10 SP8 introduces a new mechanism, Generational Store, which allows to support files larger than 2GB with the NIO API and provides increased performance on JSync clusters. It is therefore recommended to enable Generational Store if your store.xml file is close to or larger than 2GB or if you are using a JSync cluster.

The generational store consists of splitting the file store.xml into several files grouped in the directory WEB-INF/data/store/. Each file is less than 2 GB and it is therefore possible to read them with the NIO API. JPlatform reads them sequentially as if they were a single file. These files are named store-prefix-1.xml, store-prefix-2.xml, … and the last file is named store-work.xml. This is where new writes will be recorded. It is therefore necessary to ensure that it does not exceed 2 GB. Note that in the case of a JSync cluster, the write consolidation mechanism supports this control.

To enable the generational store, you need to create a directory WEB-INF/data/store and copy the file store.xml into it, renaming it store-prefix-1.xml. Then create an empty file store-work.xml. Finally, you need to enable the property channel.store.dir to true :

channel.store.dir: true

Once the generational store is activated, by going to Administration > Store status , you will be able to see the status of the different files in the WEB-INF/data/store/ directory:

7.2 Compacting the store

Store compaction (called "Store cleanup" in previous versions) consists of reducing the weight of the store files by grouping or deleting certain operations. Compacting acts on series of update operations on the same object and on all operations involving destroyed objects.

Compacting is a sensitive operation. With the traditional store, it requires stopping writes and restarting the Webapp (and each of the Webapps in the case of a JSync cluster). With the generational store, it is now possible to trigger a compaction of the store without stopping writes and without having to restart the webapp. This is possible because with the generational store, compaction only affects the store prefix files. These files are not modified (apart from the special case of consolidations) and therefore they can be reworked without blocking new store writes that arrive in the store-work.xml file.

The compaction interface has been revised to handle very large amounts of workspace (several thousand).

When compacting, the attribute opAuthor (author of the writing) is no longer considered as metadata and will no longer prevent the line from being compacted if the metadata merge option has not been checked. Conversely, the attribute restrictUpdateRights is now considered as metadata when compacting.

The Store Status interface now also offers indicators that let you know if compaction is necessary. Two general indicators are presented in the "Store Info" tab:

1. The Change/Creation ratio represents the number of changes compared to the number of creations. The higher this number, the greater the impact of compaction.
2. The Operations/Object ratio represents the number of operations (creations, updates, deletions). This indicator is particularly useful when there have been a lot of object updates or deletions.

The color of each indicator varies depending on the value:

• Red if the ratio is greater than 10
• Orange if the ratio is greater than 4
• Blue if the ratio is greater than 2
• Green otherwise

The "Classes" tab displays these ratios and the details for each class:

8. JSync

8.1 Write Consolidation

When JPlatform works with the generational store, new writes are added to the store-work.xml file. In a JSync cluster, synchronization operations consist of propagating these new writes and reintegrating them into the store-work.xml files of each replica. In the case of concurrent writes, JSync performs a merge whose performance is directly linked to the size of the store-work.xml file. The write centralization plugin greatly reduces the risk of merging. However, as not all potential contributors are centralized, concurrent writes can still take place, leading to merges. If store-work.xml files are of reasonable size (less than 100 MB), merging is generally very rapid. However, once synchronization has taken place, all these files are virtually identical. They only differ in the new operations that are added at the end.

JSync integrates a new mechanism, write consolidation, which transfers write prefixes common to the whole cluster from the store-work.xml file to the store-prefix-n.xmlfile, "n" being the largest prefix available. This operation can be performed hot (i.e. without interruption). It is controlled by the leader and requires all replicas to be declared to the leader and connected to the leader when the operation takes place. The operation can be manual (via the replication management interface), repetitive (e.g. every hour) or scheduled for a certain date (e.g. every Sunday at 04:00).

Consolidating entries is a four-step process:

• Step 1: Identification of the GCS(Greatest Common Stamp), which determines the common prefix limit in the store-work.xmlfiles.
• Step 2: Verification and validation with replicas.
• Step 3: Transfer of common operations from the store-work.xml file to the store with the most advanced prefix.
• Step 4: Handling of any errors encountered in step 3.

Numerous checks are carried out in steps 1 and 2, so that consolidation is only triggered when JPlatform is certain that it can be carried out successfully. During step 3, risks of failure may arise; however, thanks to steps 1 and 2, these risks are considerably mitigated, as they only concern changes that have occurred over a very short period (between steps 2 and 3). In step 4, the leader is required to make certain decisions based on the potential errors encountered during step 3.

Throughout the consolidation process, writes are locked on the leader's store. If new entries are made, they are put on hold.

Performance measurements have shown that consolidation is a fast and efficient process. Consolidation of over 100,000 writes (80 MB) on a cluster of 6 replicas takes 11 seconds. Verification takes less than one second per replica, while transferring the 100,000+ writes takes one second per replica. Consolidation results in a slight improvement in merge performance, by reducing the number of operations to be processed. For a simulation involving 2,400 concurrent entries, we see a gain of 2 minutes (43 minutes vs. 41 minutes). This small difference can be explained by the fact that with version 10 SP8, incoming message handling has been optimized, resulting in a significant reduction in the number of merges required.

8.2 New replication management interface

The replication management interface has been reworked to provide a better user experience and more comprehensive information.

It is accessible regardless of which node in the JSync cluster is accessed. However, some actions are only available when accessed from the leader.

The interface is broken down into tabs.

The new "Cluster" tab displays the status of the JSync cluster. It shows the replicas that are currently connected and those that are no longer connected. The actions of reconnecting and disconnecting replicas are only possible when you are on the leader.

The "Journal" tab has also been revised to provide a clearer presentation of the interactions between the leader and the replicas.

Finally, two new tabs, "DBEventLogs" and "ReplicaMessages", display the status of these two database tables that are related to cluster operation. These two tabs should be mostly empty since they are transition data that are deleted once the replicas have processed them.

8.3 JMX Agent for JSync

JPlatform 10 SP8 integrates a new JMX agent to track metrics on DBEventLog and ReplicaMessage counts.

8.4 Other improvements on JSync

Setting timeouts

It is now possible to configure the timeout of JSync exchanges. The default value is 3 minutes for exchanges (join, disjoin, suggestJoin, acknowledge) and 6 minutes for synchronizations (update). These 2 values can be modified with the following properties (in seconds):

jsync.request-timeout: 180
jsync.update-request-timeout: 360

Update Retry

Until now, when a replica sent an update to its leader, if the leader did not respond, it was necessary to wait for a new write on the replica for it to re-send the update. Now, in case of failure, the replica will try to send its update again at a regular frequency (by default every 15 minutes). This duration can be configured with the following property (in minutes):

jsync.retry-update.delay: 15

Pause during partial update

When the leader is heavily solicited in writing (for example, during an LDAP synchronization, it must send a large number of updates to the replicas. These updates are sent partially, by packet. During this sending phase which can last several tens of minutes, the leader ignored the incoming update requests from the replicas. JPlatform 10 SP8 avoids this tunnel effect, by adding a pause time between each partial update to allow the leader to process the incoming updates. This duration, by default 500 ms and which must remain low, is configurable with the following property (in milliseconds):

jsync.partial-update-interval: 500

Optimization of the synchronization algorithm

Several improvements have been made to the synchronization algorithm. Some synchronizations that were treated as merges are now treated as simple additions (therefore much faster to process) thanks to an improvement in divergence detection. The search for the point of divergence has been improved both by the generational store (because we know that by definition the divergence is necessarily confined to the store-work.xml file) and more in-depth analysis of the leader and replica progress tables.

Finally, when JSync is active, it is no longer possible to set milestones in the store because these operations are not replicated and can cause differences in the number of lines in the store files.

9. Tools

9.1 Store anonymization

For some anomalies, it is sometimes necessary for you to send your store to our support team. However, the store may contain sensitive data that must not leave your organization. You can now generate an anonymized version of the store. This store contains exactly the same operations but for each operation most of the attributes have been replaced by a generic text, HIDDEN_n, with n equal to the number of characters in the original text. Only numeric values, dates and identifiers are kept.

For example, a member creation operation.

<member stamp="c_100001" id="c_100001" op="create" cdate="1091526019025" declaredGroups="@|j_1" email="HIDDEN_17" info="HIDDEN_13" isEmailVisible="false" language="fr" login="HIDDEN_5" mailFrequency="0" mdate="1091526019025" name="HIDDEN_5 j_2" password="HIDDEN_24" />

To get the anonymized version of the store, go to Administration > Supervision > Store Status and click on the "Download an anonymized store" button. You will get a ZIP file containing the anonymized store.

9.2 Changing the main language of the site

JPlatform can manage sites in multiple languages. The contents and some data (spaces, groups, categories) are multilingual. When multiple languages are enabled on a JPlatform site, one of them is declared as the main language. It is in this language that the mandatory fields (such as the title) must be filled in. Technically, the storage of the main language fields is different from the storage of the other languages. Also, if the main language must be changed, this requires making changes to all the multilingual data already entered.

JPlatform 10 SP8 provides an element of response to this need. It is now possible to change the main language of the site when developer mode is activated. The new target language can be chosen from among the other languages of the site.

If the main language needs to be changed, it must be done when creating the site. The process should not be launched on a production site, and it is recommended to do it without logged in users. The site must be restarted as soon as the processing is complete.

To change the main language of the site, you must have activated Development Mode in the advanced properties, then choosing the new language is done simply by clicking on the main language editing icon in the properties editing interface:

Then select the new main language and click on the "Save" button.

The conversion process will start processing in the background. It will:

• Update (swap) all multilingual text fields of the following types: Publication (store and DB), Groups, Categories, Workspace.
• Update property channel.default-lang in the custom.prop
• Then stop the site writes and request a restart

Changes in the store are surrounded by two milestones .

The channel.default-country property and language of the members are unchanged. They can be changed later and manually.

9.3 Control of publications' categories in the database

A new tool for controlling publication categories in the database is available from the site administration area.

This tool allows you to audit the publications in the database in order to verify, and possibly correct, the denormalizations of the categories of each publication to guarantee their correspondence with the current category tree.

An inconsistency can indeed occur after unaccounted category moves. For example, if the operation was performed in a test environment or following an application crash.

10. Performances

10.1 Background Process Framework

Some features of JPlatform can take a very long time to process, which can be problematic both in terms of user experience (UX) and technical issues. Users are not inclined to wait without knowing how long the processing will take. If a request is triggered in Ajax and exceeds 30 seconds, the interface may freeze, leaving the user uncertain about the status of the processing. The user could then try to restart the process, even if it is still in progress. For particularly long processing, it is necessary to be able to inform the user once the process is finished.

Intermediate processing, although relatively short (a few dozen seconds), can sow doubt in the user as to the waiting time. In this case, it is crucial to keep users informed of the progress and to offer them the possibility to request a notification once the processing is completed, if they do not wish to wait.

Finally, some processing is predictably long, such as converting old calendar events or generating subtitles for a video, while others, such as translation or quiz generation, can vary in duration depending on the data to be processed. In these situations, the user should be allowed to decide whether or not to wait.

With the Background Process Framework, JPlatform 10 SP8 provides an answer to all these questions about processes that take a long time or unpredictable time. They can now rely on a framework that allows both

• Manage background process
• Report progress to the user
• Allow the user to choose whether they prefer to wait for the processing to complete (monitoring its progress) or go do something else and be notified once the process is complete.

Most of JPlatform's long or variable processing is now handled with this new mechanism.

• Updating Site Properties
• Updating plugin properties
• Plugin activation/deactivation
• Group processing
• Deploying and Resetting Application Launchers
• Lucene Re-indexing
• Importing members
• Data Integrity Check
• Compacting the Store
• Consolidation of common operations (JSync)

When a treatment starts the user sees a message that indicates the progress. The user can also ask to be notified when the treatment is finished by clicking on the "Notify me" button that appears if the treatment lasts more than 5 seconds:

Once processing is complete, the user is informed and can reload the page.

When a treatment is too long, the user can leave the page and go do something else. The treatment will continue in the background. But the user can follow the progress of the treatments in progress at any time from the Topbar.

Finally, an interface in the administration space allows you to find all the processes currently running in the background:

10.2 Limit on LDAP synchronizations

On large volumes of members, LDAP synchronizations can lead to many write operations. Since members are data stored in JStore, in a JSync cluster, this can lead to many long synchronization phases. In order to better control these LDAP synchronizations, they are by default limited to 30,000 members. This value can be set with the ldap.periodic-sync.maximum-operation-per-sync property.

10.3 Improved interfaces

Limit the number of categories displayed

Displaying a category containing many child categories can be time-consuming and slow down the rendering of interfaces. Furthermore, displaying lists of hundreds of categories is not practical for checking a category. And in many cases, this list is displayed when the user is not going to modify the categories (but modify the content for example).

JPlatfom 10 SP8 now caps the number of categories displayed directly under a parent category at 100. Beyond that, a message appears to indicate that not all categories have been displayed. In the case of a modification of existing content, the first 100 child categories are displayed as well as all categories already selected.

This feature can be disabled via the following property:

treeview.max-categories-displayed-per-node.enabled: true

The category limit that enables this feature can be changed by the following property:

treeview.max-categories-displayed-per-node: 200

Asynchronous loading of member status

Member statuses displayed on photos (colored dots) are now loaded asynchronously and have a client-side cache (5 minutes). Their calculation therefore no longer slows down the page loading.

Canceling duplicate Ajax requests

When an Ajax request for the same element (often an autocomplete) is triggered twice, the previous one is cancelled, this reduces requests to the server and prevents request 1 from arriving after request 2 and distorting the result.

Delayed decoding of multilingual fields of publications stored in the database

The ML fields of publications stored in the database are encoded in JSON. Until now, these fields were decoded when loading the publication.

However, the dynamic filtering mechanism of JPlatform (RightPolicyFilter and QueryFilter) means that we can load objects that we will not ultimately retain. However, for these filters, it is generally not necessary to access multilingual fields.

Multilingual fields are now no longer decoded when the publication is loaded, but when the field is first accessed.

Other performance improvements

Autocomplete in data fields (publication, members, etc.) is only triggered from the 3rd character typed.

Performance in handling "weak" links (WeakLink), i.e. links in Rich Text fields, has been improved.

Fixes have been made in DBEventLog handling to improve performance in environments using JSync.

11. Front-end development

11.1 New components

Switches

All boolean fields with Yes/No labels are now replaced by the "switch" component.

This feature can be disabled by setting the property ui.form.input-boolean.use-switch to false.

Phone field

A new type of control allows you to insert fields for entering a telephone number.

Example code:

<jalios:field  name="phone" ... >
  <jalios:control type="<%= ControlType.TELEPHONE %>" />
</jalios:field>
<jalios:field  name="mobile" ... >
    <jalios:control settings='<%= new TelephoneSettings().placeholder("ui.com.placeholder.mobile") %>' />
</jalios:field>

Segmented buttons

This new component displays a multiple choice (radio or checkbox type) via blocks of check buttons:

11.2 Tags

Tag memberphotogroup: Grouped member photos

This tag allows you to display a set of photos (or initials) of members in a small space. By default, the photos displayed are limited to 5, beyond which a number indicates the number of other members. To save even more space, the photos can overlap.

Example code:

<jalios:memberphotogroup members="<%= mbrSet %>" photoSize="TINY" moreButtonAction="MODAL" hoverMode="NONE"/>

<jalios:memberphotogroup members="<%= mbrSet %>" photoSize="TINY2" css="-grid" max="3" hoverMode="NONE"/>

Tag member: display of a member's photo and name

The <jalios:link> tag allows you to insert a link to any data (Data) of JPlatform. So it also works for members. But in many interfaces, we need to present both the photo and the name of the member. We can use the <jalios:memberphoto> tag but to respect the accessibility criteria, there must be only one link for the member's photo and his name.

The new tag <jalios:member> supports this. You just need to specify the member to display and the size of the photo (if the size is not specified, the size PhotoSize.ICON will be used).

Example :

<jalios:member member="<%= loggedMember %>" photoSize="<%= PhotoSize.TINY %>"/>

Tag Thumbnail: Delayed image loading

By default thumbnails are loaded in a deferred manner. The behavior can be changed globally with the tag.thumbnail.lazy-loading.enabled property. You can also change it punctually with the lazy attribute of the <jalios:thumbnail> tag.

Example :

<jalios:thumbnail lazy="false" path="debug/components/images/sampleLazy.jpg" width="200" height="200" />

In the Image portlet, an option is available to choose whether or not to defer loading the image.

Tag cardsData: Card swiper

JPlatform 10 SP8 offers a new card presentation template: a template that displays a number of cards adapted to the available surface and offers arrows to scroll the cards horizontally.

This new template is used as standard to present related publications.

Example code:

<jalios:cardsData collection="<%= pubRelatedCollection %>" titleTag="h3" maxItems="<%= pubRelatedMax %>" resource="cardsdata.relateds" />

11.3 New Carousel template

This new template, based on the Swiper.js library, allowed to improve the accessibility of the carousel.

11.4 Hiding portlet fields according to the chosen template

Since editing a portlet via JPortal, it is now possible to indicate which fields are available according to the template.

Example :

jportal.edit-portlet-modal.portlet-hide-fields.PortletQueryForeachDetail.box.carousel: showTitle showAbstract showAuthor

Here for the PortletQueryForeachDetail and the template box.carousel template, we hide the showTitle, showAbstract and showAuthor fields in the JPortal front office editing interface.

For more details see the documentation: https://docs.jalios.com/jplatform10/jcms/fr/front-end/composants/portal/hide-fields-depending-on-template-410677

11.5 API for copying to clipboard

A new API makes it easier to develop a button to copy content to the clipboard.

Example to propose the copy of a raw text:

<% String rawTextSample = "The R&D is wonderful (and 42<666) !"; %>
<% String copyRawTextConfirmation = "The text was copied to the clipaboard."; %>
<button type="button" class="btn btn-default copy-to-clipboard"
        data-jalios-text-to-copy="<%= encodeForHTMLAttribute(rawTextSample) %>"
        data-jalios-toastr-text="<%= encodeForHTMLAttribute(copyRawTextConfirmation) %>">
        Copy text
</button>

Example to propose the copy of HTML:

<% String copyHtmlConfirmation = "The HTML was copied to the clipaboard (pasted in a wysiwyg editor to see formated content)."; %>
<button type="button" class="btn btn-default copy-to-clipboard"
        data-jalios-target-to-copy="#html2copy"
        data-jalios-toastr-text="<%= encodeForHTMLAttribute(copyHtmlConfirmation) %>">
        Copy HTML
</button>
<div id="html2copy" class="hide" aria-hidden="true">
  <p><em>Hello</em> <strong>World</strong>!</p>
  <p>Follow this link to <a href="https://www.example.com/">access example.com</a></p>
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
  </ul>
</div>

11.6 Insert an action in the Topbar Bulk Processing menu

When a member adds data to the bulk processing, an icon appears in the topbar that reminds the number of elements selected for the bulk processing. By clicking on this icon, a menu appears. It is possible to insert yourself in this menu. To do this, declare your JSP by a property with the prefix caddy-menu.item. followed by a number / index then a free identifier.

caddy-menu.item.[order].[key]: [path-to-JSP]

Example as standard, the links "Open" and "Empty" the grouped processing:

caddy-menu.item.20.open:  jcore/topbar/items/doTopbarCaddyOpenItem.jsp
caddy-menu.item.60.clear: jcore/topbar/items/doTopbarCaddyClearItem.jsp

11.7 Front Library Added, Updated or Removed

12. Back-end development

12.1 Classification

If you wish to be able to limit access to certain features or on the contrary impose constraints according to the classification level of a content, refer to the documentation https://docs.jalios.com/jplatform10/jcms/fr/back-end/api-de-classification-des-publications-405761

12.2 Background Process Framework

To integrate the background process framework, refer to the documentation: https://docs.jalios.com/jplatform10/jcms/fr/back-end/background-process-428389

12.3 Ability to listen to plugin activation and deactivation

The PluginPolicyFilter are notified when activating and deactivating plugins via the enablePlugin(Plugin) and disablePlugin(Plugin) methods.

12.4 Analytics

In case of delegation, the information about the delegated member is now present in the delegationContext attribute.

It is also possible to programmatically filter what is recorded in JSON files. This allows you, for example, to ignore certain requests such as those made by monitoring tools. To do this, you need to develop a EventDataListener and implement the processEventData() method and add it via the AnalyticsManager.getInstance().addEventDataListener() method. To ignore an event, the processEventData() method simply returns null.

12.5 Added event on Push logins/disconnects

An internal event and usage analysis log is now generated when connecting/disconnecting on the push notification functionality.

For the internal event, a new listener PushEventListener can be registered on com.jalios.jcms.push.servlet.ProviderManager to react to this event.

12.6 SPI External Providers for PubBrowser and MediaBrowser

As described above, it is possible to open the interfaces allowing to choose a publication or a media to external sources. Version 1.1 of the JDOC plugin will thus propose to reference in any publication or document fields, files from an External EDM.

Similarly, the Giphy plugin allows you to select animated GIFs in a media field. And the Unsplash plugin offers to do the same with access to the eponymous image bank.

You can also develop connectors with external services. To do this, follow the documentation: PubChooser / Media browser: external providers

12.7 SPI for sending and receiving emails

It is now possible to replace the standard mail sending/receiving system (based on JavaMail API) with another service.

This is notably implemented by the MS 365 plugin, to allow the use of the Graph API for sending and receiving emails. Using this feature involves declaring a MailProvider in the platform properties.

Example (MailProvider declaration using MS 365 API):

mail.provider.m365Provider.class: com.jalios.jcmsplugin.office365.provider.Microsoft365MailProvider
mail.provider.m365Provider.apiKey:<API_KEY>
mail.provider.m365Provider.apiSecret:<API_SECRET>
mail.provider.m365Provider.tenantId:<TENANT_ID>

12.8 Property Chaining

It is now possible to create "chained" properties, i.e. properties whose value is the value of another property. A property can take the value of another property as its value. To do this, simply indicate the prefix prop: followed by the name of the property as the value.

Example :

my.legacy.prop: 1234
another.prop: prop:my.legacy.prop

12.9 OpenAPI / REST

User Preferences (MbrPref)

It is now possible to view a user's memberPreferences via the REST API /data/Member/{login}/preference/{key}.

This API is available in GET/PUT/POST/DELETE with the following constraints:

• A user without special rights can only access the preferences that concern him.
• An administrator (or someone with the admin/users/member ACL) can access other members' memberPreferences (read and write)

A user with ACL cannot access a DBMember's preferences (read or write). Default preferences (from code or properties) are read-only on the REST API and accessible by any logged in user on the URL members/defaultPreference/{key}.

Site Status (StateManager)

Added a manager to the product that carries the status of the platform (StateManager.getInstance().getState()).

This state is among the following values (inspired by possible states in Kubernetes):

• JPlatformState.STARTUP: indicating that the platform is starting up
• JPlatformState.READY: the platform is available for service
• JPlatformState.ALIVE: The platform has finished initializing correctly (the platform is responding to web requests)
• JPlatformState.ERROR: The platform has encountered a serious error and is unavailable. The platform status may be accompanied by an optional explanatory message.

The status can be consulted:

• via REST API: with a public address rest/state
• via a JMX resource whose key is domain jalios.jplatform:Instance=<channel name>,component=StateManager,name=StateManager

The platform status can be changed:

• via code: StateManager.getInstance().setState(JPlatformState.READY, message)
• via the REST API (if the logged in user is an admin or with the ACL admin/operation/state-management)
• via a JMX method

Finally it is possible via a com.jalios.jcms.exploitation.state.StateNotifier to be notified of all changes in the status of the platform.

StateNotifiers are added via the addNotifier method call on StateManager or by setting the notifier class name via an environment variable or a JVM system parameter (in both cases, the key is prefixed by jplatform.state.notifier.class.).

Example: -Djplatform.state.notifier.class.file=com.jalios.jcms.exploitation.state.FileStateNotifier

The default StateNotifier (com.jalios.jcms.exploitation.state.FileStateNotifier) provides the state in a file jplatform.alive, jplateform.ready, ... in the WEB-INF/jcmswork/ directory, being compatible with the previous functionality (ReadinessManager being now deprecated).

Retrieving current workflow actors on a publication

On a publication, it is now possible to obtain the list of current actors who can work on the publication, via the getCurrentWorkers() method.

This data is also available in the related fields, which can be added when exporting a publication via the REST API (related=currentWorkers).

Changes to notification rules

Previously, changing a user's notification rules required specifying all alertLevels, alertDomainNames, alertChannels parameters. It is now possible to change these settings via the encodedAlertRules parameter, a JSON object whose value is returned when retrieving a member's data via the REST API.

Example :

jQuery.ajax({
  method: 'POST',
  data: {
    "encodedAlertRules": '[{"levelKey":"warning","domain":"admin","alertChannels":["mail","web"]}]',
    "opUpdate": true
  },
  url : JcmsJsContext.getBaseUrl() + "rest/data/j_2",
  success: function(result) {
    console.log(result);
  }
});

12.10 Java Libraries Added or Updated

13. Compatibility and migration

13.1 Tomcat 9 / Java 17

Tomcat 8.5 is no longer supported. This version is end-of-life since March 31, 2024 and does not support the Servlet 4.0 specification.

You must use Tomcat 9.x (Please note, Tomcat 10 and newer are NOT supported).

JPlatform 10 SP8 is certified with Java 11 and Java 17.

13.2 13.2 Java compiler

ECJ (Eclipse Compiler For Java) is now the default compiler used to compile generated classes. It supports compiler dependency loops that javac does not.

If you nevertheless wish to revert to the javac compiler, you can do so with the following property:

channel.java-compiler: internal

13.3 Databases

JPlatform 10 SP8 is certified on several external DBMS:

• PostgreSQL 12, 13, 14 and 15 and 16
• MySQL 8 (InnoDB storage engine)
• Oracle 19c and 21c
• Microsoft SQL Server 2012, 2016 and 2019
• MariaDB 10

13.4 Plugins

JPlatform 10 SP8 requires having the latest versions of some plugins:

• Centralized Write 2.2
• Collaborative Space 8.0.9
• JCalendar 1.6
• JDoc 1.0.1 
• JEvent 1.2.1
• JNews 2.4.1
• JProcess 2.6.4
• JTask 3.7.3
• Local Calendar 1.5

13.5 Generational Store

By default, JPlatform 10 SP8 is delivered to work with the classic store (file store.xml).

If you still wish to benefit from the generational store, you must apply the following procedure:

If your file store.xml is less than 1.8 GB:

1. Create a directory WEB-INF/data/store/
2. Copy your WEB-INF/data/store.xml file to WEB-INF/data/store/store-prefix-1.xml
3. Create a file an empty file WEB-INF/data/store/store-prefix-2.xml
4. Create a file an empty file WEB-INF/data/store/store-work.xml

If your file store.xml is larger than 1.8 GB:

1. Create a directory WEB-INF/data/store/
2. Split your file WEB-INF/data/store.xml into as many files of less than 1.8 GB each.
3. Copy these files into the directory WEB-INF/data/store/ respecting the order of the splitting and naming them respectively store-prefix-1.xml, store-prefix-2.xml, ...
4. Create a file an empty file WEB-INF/data/store/store-work.xml

Finally, in both cases, add the following property in your file WEB-INF/data/custom.prop:

channel.store.dir: true

13.6 web.xml

The file WEB-INF/web.xml has been updated to use Servlet API 4.0.
If you had customized this file with specific settings, you must redo the changes.

13.7 Description of the notification (alert) of a recommendation

The language property alert.msg.recommendation.notification.description has evolved to decouple & move the recipient list below the recommendation message.

-alert.msg.recommendation.notification.description: <p>{author} shared you {data}</p> {recoContent}
+alert.msg.recommendation.notification.description: <p>{author} shared you {data}</p>

Check your possible specific developments related to this notification.

13.8 Classification of publications

Following the introduction of the publication classification functionality:

• The "classificationLevel" field on the Publication type is reserved.
  If any of your custom content types have a field with this name, it must be renamed prior to migration.
• The columns exported in CSV are evolving, this could have consequences on possible data processing:
  • CSV export of publications: a new column is present to export the value of the field classificationLevel  of Publications
  • Members CSV export: a new column is present to export the value of the authorizationLevel Members field
• A complete reindex of publications and members is required after migration

The custom.prop file contains numerous properties related to classification configuration. They all begin with the prefix classification. . However, the classification management interface allows you to manage these properties without having to edit them manually.

13.9 Properties for authentication tokens

(1) A revocable authkey is stored in the database when created, and checked when used. Enabling this setting reinforces security. This setting is deactivated by default so as not to break compatibility with authkeys already issued (not having been stored in base and therefore not controlabe). This setting applies to all authkeys corresponding to the reinforcement target, whether already issued or newly created.

(2-reco-activation) Recommendation: activate this setting for enhanced security

1. identify authkeys already issued on external services, with the reinforcement target (admin/prefix/expiration long)
2. regenerate authkeys for these services
3. enable functionality to force basic control for enhanced security
4. monitor remote service failures that may have been overlooked, and regenerate authkeys for these services

13.10 Updated CSV import of members

In previous versions, the JSP resources and sample files .csv to download were located in /admin/import.
These files have been moved to /admin/member/import.
If you have any properties pointing to the old path, please update them.

The old API has been retired in favor of a rework to asynchronous processing.
If you had API related developments in the package (com.jalios.jcms.handler.MembersCsvImportHandler, com.jalios.jcms.MemberImportManager), you will need to update them (See in com.jalios.jcms.member.csvimport: MemberImportProcess, MemberCsvImportHandler).

Example code to perform a member import:

import static com.jalios.jcms.member.csvimport.*;

MemberImportContext ctx = new MemberImportContext();
if (csvFile != null) {
  ctx.setCsvFilePath(csvFile.getAbsolutePath());
}
ctx.setGuestMode(isGuest);
ctx.setImportAuthorId(loggedMember.getId());
ctx.setSeparator(separator);
ctx.setDBMemberImport(useDbMembers);
ctx.setSendEmail(sendEmail);
ctx.setGroupIds(groupIds);
ctx.setUsage(usage);
ctx.setSimulation(isSimulation);
// Start process
BackgroundProcess process = new MemberImportProcess(ctx);
process.start(loggedMember);

Change isSimulation to run validation (true) or actual import (false).

The import runs in the background. It can be tracked in the long processing monitoring interface.