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 and the known issues and limitation page.
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.
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>Other permissions>Workflow tasks when editing a role in Roles and permissions.
For continuity, this permission is granted by default to the Jahia roles that can operate on workflows including:
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.
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.
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.
By default, permissions to access jExperience project features are already added to the Editor in chief and Site administrator edit roles.
To add jExperience project permissions for custom edit roles:
Whether you’re using default roles or custom roles, you will need to associate the user to the role by editing your site:
By default, permissions to access jExperience global features are already added to the Digital Marketer server role.
To add jExperience global permissions for custom edit roles:
Whether you’re using the digital marketer role or custom roles, you need to add your user or group to the server role.
Notes:
Example
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:
In Jahia 8, the following functionality was removed:
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:
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:
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.
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.
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.
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:
Global mount points and saved searches are not longer available to users.
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:
If the mount point needs to be accessible from different sites, you have two options:
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.