Written by The Jahia Team
   Estimated reading time:

This topic lists changes that system administrators should be aware of in Jahia 8. Please review the changes carefully. We also strongly encourage you to read the Migration guide for functional administrators and Migration guide for developers, as well as our known issues and limitation page.

Permission changes

This section describes permission that have been renamed in Jahia 8, obsolete permissions that have been removed, and permissions that are new to Jahia 8.

Replacement of permissions

To better correspond with the new interfaces, we have introduced new permissions as replacement of ones used with Jahia 7.3. The:

  • jContent permission replaces the Edit mode permission
  • jContent access replaces the editModeAccess and contributeModeAccess permissions
    When set on an edit role on the current site, jContent access grants access to Page Composer and jContent.
  • jContentActions permission replaces the editModeActions permission

Note that these replacements are handled during the Jahia upgrade and do not require any change on your side. The roles who had the old permissions are automatically granted the new ones.


For compatibility purposes, we have moved replaced permissions into a legacy section available in the Other permissions tab in Content Editor, but not removed them. We have also moved obsolete permissions, contributeMode and editSelector,  that are not used anymore.

If these permissions were set on a role in 7.3 they will still be set on the same role in Jahia 8. If you were relying on these permissions in your own modules, you do not have to update your own code as the permissions still exist and are still granted to the same roles.

We encourage you, if you have the opportunity, to update your code to use the new permissions.

Removed permissions

We have removed the permissions related to the legacy managers as these were already deprecated with Jahia

  • Editorial content manager
  • File manager
  • Site manager

New permissions


A new Remove locks on contents (clearLock) permission has been added. It allows a user to remove a lock on a node using the context menu, even if the user is not the owner of the lock. This permission is available by default to server administrators, who can then grant it to other roles. To do so, they need to set it on Permissions on current site>Other permissions>Remove locks on contents.

Note: Use the removing locks feature with caution. Always verify the owner of the lock first, as it is not recommended to remove the lock when the corresponding content is part of a publication workflow.

Advanced Options tab

The Advanced Option tab of Content Editor is protected by the Can see advanced options tab permission. This permission is granted by default to the following roles:

  • Editor in chief
  • Site administrator
  • Server administrator

This permission needs to be set at node level (select Permissions on current node when editing a role) to be effective. You can find it in Other permissions under Content Editor.

For more information about permissions required by Content Editor, see About Content Editor permissions.


If you are using jExperience, you will need to upgrade it to jExperience 1.12 as jExperience 1.11 is not compatible with Jahia 8. This upgrade to jExperience 1.12 also requires an upgrade from Elasticsearch 5 to 7.

For more information about upgrade jExperience, see Upgrading to jExperience 1.12.


Jahia 8 only supports Forms. Form Factory 2.3 is not compatible with Jahia 8 and must be upgraded before you migrate from Jahia 7.3 to 8. If you were on Form Factory, you must first migrate to Forms while still running Jahia 7.3. See Upgrading to Forms from Form Factory. Once you have migrated to Forms 2.4 on your Jahia 7.3, then you can migrate to Jahia to 8.

To migrate from Forms 2.4 to Forms 3.0 on Jahia 8, you need only to update the modules you are using from Forms in your digital-factory-data/modules folder. Remove the older versions and copy the new ones. This is presented in detail in step 4 of the How to upgrade guide, which explains how to run the Jahia fix applier.

All new versions will be available on the Store for download to prepare your migration.

/jahia prefix for backoffice UI

We are introducing /jahia as prefix for our backoffice URLs (new navigation). If you are blocking such backoffice URLs or if you have custom rewrite rules, we advise you to verify your configurations and update them if needed.

Global mount points are not displayed in contribution interfaces

For information on why global mount points do not display in contribution interfaces, see the corresponding section in the Functional administrators migration guide.

Note that you can still create global mount points if you are using them for more technical integrations. These mount points can be accessed from the Repository Explorer. When editing content in Content Editor, they can be accessed when using the legacy interfaces in the Advanced options tab.

Deprecation of portlets

Portlets are deprecated in Jahia 8. If you are using portlets in Jahia 7.3, they will continue to work for the entire lifetime of Jahia 8.

  • If you are not using portlets, you should revoke the permission for your editors to add portlet references
  • If you are using portlets, you must deploy the Portlet module to make the portlet screen visible in Jahia. In your modules, define a route to display Portlet Manager in your site, either in the Administration>Sites accordion or in jContent>Additional. Here is an example of route declaration where edccb972-243e-4564-92e0-c0756891b8b3 is the site node UUID.
    window.jahia.uiExtender.registry.add('adminRoute', 'portletsite', {
        targets: ['jcontent:40'],
        label: 'portletsite:label.title',
        isSelectable: true,
        iframeUrl: window.contextJsParameters.contextPath + '/engines/manager.jsp?conf=portletmanager-anthracite&lang=en&site=edcytcrhcb972-243e-4564-92e0-c0756891b8b3'

Identifying a cluster node in the backoffice UI

In Jahia 8 you can display the name of a node/environment in the expanded main menu. A diamond displays over the burger icon to indicate that a name has been provided. You can set this name per node (or use the same name on all the nodes of an environment), by adding the following property on each node:

jahia.environment = Preproduction

where Preproduction is the name of the node

Access to the /tools section

Note: This change has been introduced in Jahia

Prior to Jahia, users accessed the /tools section with the Jahia Tool Manager user. We removed the Jahia Tool Manager user for security reasons, as administrators had to share this username and password with others. Now Jahia users access the /tools section when they are granted the new System tools access permission. This permission is only available to a new category of roles named System roles and is granted to the new default System administrator role. The root user is the only user who can add users to system roles. In other words, only root can grant a user access to the /tools section by adding them to the System administrator role.

Things to consider when upgrading to Jahia

  • Assign the System administrator role to users in your organization that require access to the /tools section
  • If you are calling pages from the /tools section in your scripts, you will have to either:
    • update your scripts with the username and password of a user who has access to /tools through membership in the System administrator system role
    • create a new user in Jahia with the same username and password as the previous Jahia Tool Manager user

For more information on using the new System administrator role, see Managing roles and permissions.