Migration guide for functional administrators

December 21, 2021

This topic lists changes that functional administrators should be aware of in Jahia 8. Please review the changes carefully. We also strongly encourage you to read the Migration guide for developers and Migration guide for system administrators pages.

Changes to permissions

Jahia 8 introduces a new permission that grants or denies access to the new Workflow dashboard, an improvement to how users can edit content in Page Composer and jContent, and introduces new permissions for jExperience.

New permission to access the Workflow dashboard

The Workflow dashboard helps you manage publication flows such as reviews, feedback, and publishing content. To make it easier to control who can see publication notifications in the UI, you can use the new Workflow dashboard access permission to grant or revoke access to the Workflow dashboard. You select the permission in Permissions on current site>User interface>Managers when editing a role in Roles and permissions.

Note: This permission needs to be set on the current site. Setting it on the current node will not work.

For continuity, this permission is granted by default to the Jahia roles that can operate on workflows including:

  • Editor in chief
  • Reviewer
  • Site administrator

This permission can be added to any custom roles that require access to the Workflow dashboard. When multiple step workflows are necessary and an editor needs to access the workflow dashboard (for example, a correction is needed), then the Workflow dashboard access permission must be granted to the editor role or a custom role assigned to a specific user.

Permission changes to editing content

Note: Permission changes to edit content represent a minor change that you may not have been aware of.

In 7.3, a user needed both component and write permissions to edit a content item in a page in Edit mode. In Content and Media Manager and the legacy Site Manager, the write permission was enough to edit a content item. A user who did not have the component permission for a content type could not edit this content in a page in Edit mode. However, they could edit that same content in Content and Media Manager or the legacy Site Manager. In any case, as the user did not have the component permission, they would not have been able to create such new content.

In Jahia 8 the component permission is only selected in the content type selector when creating new content in Page Composer and jContent. A user with the write permission on a content item will always be able to edit it. For more information on permissions required for Content Editor, see About Content Editor permissions.

Translator role

User withs the translator role still have access to a similar translation interface as with Jahia 7.3 in Page Composer, without any required action.

However, to allow them to also use Content Editor to edit internationalized properties, you need to grant the following permissions to the translator role. In Permissions on current site > User interface > jContent > Engine tabs:

  • View content tab
    With this permission, translator will see the content properties, and be able to edit the internationalized ones
  • View options tab
    If some content types define internationalized properties to be displayed in the "Options" section, then you also need to grant this permission to the translator role
  • View layout tab
    If some content types define internationalized properties to be displayed in the "Layout" section, then you also need to grant this permission to the translator role
  • View metadata tab
    If some content types define internationalized properties to be displayed in the "Metadata" section, then you also need to grant this permission to the translator role

Permissions for the context menu entries (introduced with 8.0.3)

Jahia 8.0.3 provides a new set of permissions providing more control over the entries/actions available in the context menu of pages and content item in the Page Composer and jContent interfaces. This allows the creation of roles with simplified permissions, usually for occasional contributors. These permissions are available for the edit roles, under Permissions on current site > User interface > jContent action
For instance, it is possible to remove the Export and Import entries in the context menu of pages and content.

These new permissions act as a second level of permissions, on top of the Permissions on current node > Basic permissions > All basic permissions > Write which were used by the previous Jahia versions and which are still necessary with Jahia 8.0.3+

When upgrading to Jahia 8.0.3, these new permissions are added by default to the edit roles, and shall be transparent for you, as they are added on top of the already existing ones.

If you have roles allowing the creation/edition of content, but for which you have revoked the Create page action, you shall verify this setting after the upgrade.

New jExperience permissions

The lastest version of jExperience divides administrator functionality into project and global settings. A user requires both types of permissions to have full access to jExperience.

Granting permissions at the project level

By default, permissions to access jExperience project features are already added to the Editor in chief and Site administrator edit roles.

Note: If you use custom edit roles, you must add jExperience project permissions to the custom roles.

To add jExperience project permissions for custom edit roles:

  1. In Administration>Server>Users and roles>Roles and permissions, select any edit role you want to edit.
  2. In the role details, choose Permission on current site>Other permissions.
  3. Scroll and select Edit mode.
  4. Enable the following permissions:
    • Access jExperience
    • Add jExperience AB Tests 
    • Add jExperience personalizations
  5. Save your changes.

Whether you’re using default roles or custom roles, you will need to associate the user to the role by editing your site:

  1. Navigate to Page Composer, right-click on the site name and click Edit.
  2. In Content Editor, select Advanced options>Edit roles.
  3. Find the role you wish to associate.
  4. Add your user.
  5. Save your changes.

Granting permissions at the global level

By default, permissions to access jExperience global features are already added to the Digital Marketer server role.

Note: If you use custom server roles, you must add jExperience global permissions to the custom roles.

To add jExperience global permissions for custom edit roles:

  1. In Administration>Server>Users and roles>Roles and permissions, select any server role you want to edit.
    Note: Do not select an edit role, this only applies to server roles.
  2. In the role details, select Permission on the whole server>Server administration.
  3. Scroll and select Global jExperience permissions.
  4. Enable the following permissions: 
    • Access to jExperience global menu
    • Use jExperience integrations
    • Configure jExperience
  5. Save your changes.

Whether you’re using the digital marketer role or custom roles, you need to add your user or group to the server role.

  1. In Administration>Server>Server roles.
  2. Click Edit beside Digital marketer or your custom role.
  3. Find and select your user or group.
  4. Save your changes.


  • Global jExperience permissions can only be set for a server role. Adding Global jExperience permissions to a role associated with a site will not apply permissions to the role.
  • Site users and site groups cannot be associated with a server role and therefore cannot access the jExperience global area.


In this example, Kaeli is a digital marketer working for ACME company on the ACME corp website. Kaeli is a member of the ACME marketers group. This group has been defined at the server level. To ensure that Kaeli and other ACME Marketers can access jExperience global and project features for ACME corp, you need to add the ACME marketers group to:

  • The Digital marketer server role in the server administration.
  • The Editor in chief site role by editing your site from Page Composer.


Removal and changes to functionality in Jahia 8

In Jahia 8, the following functionality was removed:

  • Contribute mode
  • Trash
  • Workflow menu
  • WCAG Checker for rich text

Removal of Contribute Mode and continuity of Contribute mode settings

As part of Jahia interface improvements, Contribution mode has been removed. In earlier versions of Jahia, Contribute mode settings could be applied on a specific content area or content list or at the folder level. Contribute mode settings was used to limit the types of content that could be created inside lists and folders in Contribution mode and Content and Media Manager. However, content level restrictions were not applied in Edit mode.

Jahia 8 maintains content level restrictions which are renamed “Content type restrictions”. Page Composer respects limitations on content types which can be created per area or content list and jContent respects restrictions on content folders. Restrictions on content folders are inherited.

When migrating to Jahia 8, limitations previously set for contribution mode on content areas, content lists, and content folders are preserved and applied to Page Composer and jContent. For configurations that previously relied on content level settings, we recommend that you revisit requirements for limitations and consider applying at the folder level or apply updated values directly in Page Composer and jContent.

To summarize:

  • Content type restrictions is the new name for Contribute mode settings
  • Contribute mode settings set in 7.3 will be migrated and available as Content type restriction in Jahia 8
  • The new Content type restrictions can be applied to:
    • Content areas and lists in Page Composer.
    • Content folders in jContent. Sub-folders will inherit the restrictions of the parent, if they are set.
Jahia 8.0.3 introduces additional permissions which can be leveraged to reduce the available actions for your contributor roles.

About View content type restriction tab permissions

The ability to set content type restrictions on an area (and potentially override or bypass type restrictions set on an area in the template itself), list, or content folder is given to the roles which have the View content type restriction tab permission. This permission is granted by default to the following roles:

  • Editor in chief
  • Site administrator

The View content type restriction tab permission can be granted to other roles. It is available in Permissions on current site>User Interface>jContent>Engine tabs.

Removal of Trash functionality

In Jahia 7.3, editors could access the Trash from Edit mode. This feature has been removed in Jahia 8 to simplify the interface.

As an alternative, you can download the Content Reports module and activate it on your sites. The Marked for deletion report lists all content marked for deletion, including the child subcontent and pages. You can also decide to generate the report on a specific section of your site. For more information about content reports, see Generating reports on your content.


Removal of the Workflow menu

In Jahia 7.3, you accessed the workflow dashboard in two clicks from the Workflow menu in Edit mode or Contribute mode.


The workflow dashboard is now directly accessible in one click in Jahia 8, regardless of where you are on the application..

With Jahia 7.3, the Workflow menu was also used to start custom non-publication workflows. This feature was not used to our knowledge and is removed from the interface. If you were using a custom non-publication workflow, you can develop your own actions in jContent to start these workflows.

WCAG Checker for rich text no longer integrated with Content Editor

The WCAG checker for rich text, integrated in Jahia until version 7.3, presented usability limitations. Content Editor no longer integrates this feature and insteads relies on 3rd party solutions including Siteimprove. Siteimprove is a more powerful tool for identifying accessibility and SEO issues, as well as improving the content of your site overall.

Note that the WCAG checker is still available from Content Editor when using the legacy Content tab in Advanced Options. You can enable or disable the WCAG check for this interface when editing the site node.

To enable or disable the WCAG checker:

  1. In Page Composer, right-click on the site node and choose Edit.
  2. In Content Editor, choose Advanced options>Content and scroll down to HTML settings.
  3. Enable or disable the WCAG Compliance feature.
  4. Save your changes.

Other changes

Global mount points and saved searches are not longer available to users.

Changes to access to global mount points

Mount points are used to connect your Jahia platform with other systems. For instance, mount points are particularly useful when you need to access and use files in Jahia that are stored on a file system (using a VFS mount point) or files originating from another DAM service (for example, Alfresco). These connections can be mounted either globally or under a Jahia site.

In previous versions of Jahia, when a mount point was created locally, editors had to leave the context of their site to reference content and files coming from an external system. This behavior was confusing for editors. To make it easier for editors, editors can no longer access such global mount points. However, they can still access the mount points created under a folder in their site.

If you have global mount points that need to be accessed by editors, then you need to edit their configuration.

To give editors access to a global mount point:

  1. Navigate to Administration>Server>Modules and Extensions>Mount points.
  2. Check Select a target local mount point.
  3. Browse the folders of the different sites by clicking on the folder names.
  4. Select the radio button beside the target folder.
  5. Click Save.

If the mount point needs to be accessible from different sites, you have two options:

  • Create one mount point per Jahia site.
  • Choose a folder under System Site. Then grant permissions to your users to access this folder
    When creating references to external content, editors must select System Site in the picker to browse the external content. This is similar to what editor had to do in previous versions when using global mount points.
    Note: Editors cannot currently switch sites in Content Editor pickers, but can do so in Content Editor in Advanced options>Content and then using the legacy interface which allows switching sites.

Saved search no longer available

In Jahia 7.3, you could save a search made in a content picker or in one of the legacy managers (Document Manager, Content Manager, and Site Managers) before they were replaced by Content and Media Manager (CMM). Just like CMM, Jahia 8.0 does not support saved searches in the new jContent and Content Editor interfaces. You can still save searches and access them in legacy pickers, accessible from the Content entry in the Advanced options tab in Content Editor.

Search queries are now reflected in the URLs of jContent allowing you to conveniently bookmark them in your browser. This makes it much easier and faster to access lists of content and benefit from the new jContent interface. Previously you would have to open Jahia, open the Document Manager, switch to the saved searches section, and click on the saved search, while facing the limitations of the legacy managers. Including the searched terms in the URL allows you to share search queries with your collaborators, which was not possible with Jahia 7.3.