Permissions for editors in a multilingual site

This tutorial is over a year old and may not apply to your version of Concrete CMS.
Jun 2, 2021
By myq for Editors

Goal

Set up a multilingual Concrete CMS site where each locale can be assigned to a group of editors to maintain. In this case, each editor will have access to only the sections of the website that match their assigned language.

Steps

Sign in as superadmin

This avoids certain permissions issues.

Turn on advanced permissions

Advanced permissions must be enabled for this use case. Go to Dashboard > System & Settings > Permissions & Access > Advanced Permissions (/dashboard/system/permissions/advanced) and enable advanced permissions. Note: this is an irreversable choice; once enabled, the site can not be set back to the simple permissions model, so be sure you want to set up a site this way.

Set up groups for each locale

Depending on your needs, set up groups for each locale. Go to Dashboard > Members > User Groups and select Add Group (/dashboard/users/add_groupAdd).

Hint: if setting up more than one linguistic group, it may be useful to put all those groups in a Group folder to make setting permissions easier.

Create a Group Set

If one does not already exist, create a Group Set and add the linguistic group to the set. Go to Dashboard > Members > Group Sets and select Add Group Set (/dashboard/users/group_sets).

Add a Group Set to match the group folder made in the previous step. Add the linguistic groups to this group set. When setting permissions and such below, set the group set where appropriate (Task Permissions, File Manager permissions, Block & Stack Permissions, etc. wherever there is an option of setting up by group or group set).

Add members to group

Find each user you want to add to the group by going to Dashboard > Members > Search Users. After finding a user to add, select the username to see the user detail page. In the Groups section, select Edit and add the group.

Enable multilingual setup

Do this by adding a locale other than the locale set when the site was installed. Go to Dashboard > System & Settings > Multilingual > Multilingual Setup (/dashboard/system/multilingual/setup) and add a locale. Choose the language, country or region, template, home page name, and URL slug.

Copy languages from one locale site tree to another (optional)

This assumes that your default locale already has content in it, go to Dashboard > System & Settings > Multilingual > Copy Languages (/dashboard/system/multilingual/copy) and copy the default locale tree to the other locales.

Set up permissions

Setting up permissions correctly is essential. Be sure to follow each of these steps as missing one or setting up a permission incorrectly could lead to things not working as expected.

Set Task Permissions to give access to Sitemap

Go to Dashboard > System & Settings > Permissions > Task Permmisions (/dashboard/system/permissions/tasks) and add the Group Set created above to the Access Sitemap permission.

Set File Manager Permissions

/dashboard/system/files/permissions

Go to Dashboard > System & Settings > Files > File Manager Permissions and add the Group Set to the following permissions:

  • Search File Folder
  • Add File

Note: this sets the default permissions on the root node of the File Manager and all files and folders inherit these permissions by default. Step 12 creates a private folder for each linguistic group / locale, so if there’s no need for any shared assets, this step can probably be skipped.

Set Block & Stack Permissions

Go to Dashboard > Stacks & Blocks > Block & Stack Permissions (/dashboard/blocks/permissions) and add the Group Set to the following permissions:

  • Add Block
  • Add Stack

Set Page Type permissions

Optional: If the editors are free to create pages in the localized site tree which are not associated with a page in the default locale, they will need to be given permission to add new pages.

Go to Dashboard > Pages & Themes > Page Types (/dashboard/pages/types) and select Permissions for each page type you want to allow.

For each relevant page type, add the Group Set to the following permission:

  • Add Pages of This Type

Note: if running a multi-site installation, you may need to select the site type on order to view the relevant page types.

Add permissions to Drafts

(optional: this is only necessary if the editors are free to create pages in the localized site tree which are not associated with a page in the default locale. However, you’ll probably need to add the group of default locale editors if they are not in the Administrator’s group)

/dashboard/sitemap/full

Select View System Pages option

Likely need to add:

  • View Versions
  • View Page in Sitemap (not sure if this one is needed for Drafts)
  • Edit Properties
  • Edit Contents
  • Change Page Template
  • Edit Page Type
  • Delete
  • Delete Versions
  • Approve Changes
  • Add Sub-Page (not sure if this one is needed for Drafts)

Adjust permissions on the locale’s root node

Go to the Sitemap

/dashboard/sitemap/full

Select the site and locale

Select root node permissions

Add the locale group to the following permissions:

  • View Versions
  • View Page in Sitemap
  • Edit Properties
  • Edit Contents
  • Change Page Template
  • Edit Page Type
  • Delete
  • Delete Versions
  • Approve Changes
  • Add Sub-Page

Adjust Dashboard view permissions

/dashboard/sitemap/full

Select View System Pages option

For each of the nodes under Dashboard, change “Assign Permissions” to “Manually” for each node that the linguistic groups will not need to view.

Then go back and add the group or group set to the View permission to the Dashboard node. All nodes that have not been set to manually assigned permissions will inherit the Dashboard node permissions.

Depending on how many should be visible or hidden, it might make sense to manually assign permissions to the nodes the groups will need to view.

Nodes likely not needed:

  • Dashboard
    • Members
    • Express
    • Boards
    • Reports
    • Pages & Themes
    • Calendar & Events (depends on use case)
    • Conversations (depends on use case)
    • Stacks & Blocks (depends on use case)
    • Extend concrete
    • System & Settings (may be needed if access to the Locale Page Report or interface translation tool are needed)
    • Concrete Theme

Create a File Manager folder

Create one for each groups' private use (optional, but this can help keep the File Manager organized. Depending on the use case, you may want groups to share assets, so permissions could also be adjusted as needed)

/dashboard/files/search

Create a new folder to hold the linguistic groups' folders

Create a folder in that folder for each of the groups

Override the inherited permissions from the root node (set in step 7) and add permissions per folder so that the matching group can:

  • Search File Folder
  • Add File

]

Set up a workflow

(optional) if edits need to be approved, set up workflows.

Recent Tutorials
Customize locale icons
Oct 29, 2024
By myq.

How to customize locale (language region) flags

Concrete CMS Caching Guide
Oct 16, 2024

An overview of types of caching in Concrete and considerations when using them.

Redirect all requests to HTTPS
Oct 9, 2024
By myq.

How to follow best practices for a secure web

Upgrade Concrete versions 9.3.1 and 9.3.2
Sep 10, 2024
By myq.

How to get past a bug in versions 9.3.1 and 9.3.2 that prevents upgrading the Concrete core through the Dashboard

How to use Composer with Marketplace extensions
Aug 22, 2024

Composer can be used to manage third-party extensions from the marketplace

Controlling Google Tag Manager Tags Based on Concrete CMS Edit Toolbar Visibility
Aug 13, 2024

This document provides a step-by-step guide on how to control the firing of Google Tag Manager (GTM) tags based on the visibility of the Concrete CMS edit toolbar. It explains how to create a custom JavaScript variable in GTM to detect whether the edit toolbar is present on a page and how to set up a trigger that ensures GTM tags only fire when the toolbar is not visible. This setup is particularly useful for developers and marketers who want to ensure that tracking and analytics tags are not activated during content editing sessions, thereby preserving the accuracy of data collected.

Improvements?

Let us know by posting here.