Managing backend user permissions and groups can be a very challenging task, especially if you have to deal with many user and different permissions. Having a clear concept when organizing these groups, makes it later on much easier. This article describes my preferred concept.
The central point is, that each group has a clear focus, so that you can read from its name, which permissions the group contains. Mixing up different permission areas will make it hard to name the groups and will lead at least to some level of mess, especially if the website grows and more editors are added.
Very helpful is to prefix the group names with an abbreviation, which indicate the purpose of the group. I use the following prefixes. In the latter chapters, will explain the in detail and how to use them.
Backend user group prefixes and their purpose
- „DM_” = Database Mount groups contain the entry point to the page tree
- „PG_“ = Page Groups will be used in the page module to set permissions
- „ACL_“ = Access Control List groups contain permissions to database tables and modules
- „FM_” = File Mount groups only the file mounts to which members should have access
- „R_“ = Role groups are the to group the different permissions together
TYPO3 Backend User Group Types explained
„DB_“ – Database Mount Groups
This groups contains the entry point to the page tree. These groups define which part, of the page tree may be viewed (and edited) by this user. Besides the database mount nothing may be set here.
Normally the user can only set links to his own pagetree. With the following option, set in the TSconfig field of the group, other parts of the page tree can be allowed as link targets.
options.pageTree.altElementBrowserMountPoints = <PID>
<PID> is a comma separated list, which contains the possible other branches. If the user (group) should be able to link the complete site, the pid must be set to the pid of the website root.
„PG_“ – Page Groups
For each “DB_”-group there must be a group, which serves as the standard group for the access module. The access module defines which permissions, the owner, the group and every body has. If you know the unix file permissions, this system is quite similar, despite that there are some more possible permissions.
The permissions are:
- Show and copy page and content (later on referred as “Show page”)
- Change, add, delete and move content (later referred as “Edit content”)
The details, which tables may be edited, is defined in the ACL groups
- Change and move page (later referred as “Edit page”)
- Delete page and content (later referred as “Delete page”)
- Create new page under this page (later referred as “Create page”)
„Everybody“ get the following permissions assigned
- “Show page”
- “Edit content”
- “Edit page”
The owner and the “PG_” group get always full permission on the page. This means additionally
- “Delete page”
- “New page”
The “PG_” group must be set in PageTSconfig with this code:
TCEMAIN.permissions.groupid = <UID>
If you include the PageTS file-based, you need to surround it with a condition
[PIDinRootline = ]
The PID is the uid of the upper most page of the branch where the assigned users and groups should have full editing permissions.
Furthermore it is necessary to set the permissions for groups and everybody consistent over the complete website as suggested above. In order achieve this, the uppermost pageTS must include the following snippet:
# Permissions of the group of this page
# Permissions of everybody on this page
permissions.everybody = show,edit,editcontent
The owner / creator of the page has always full permissions.
„FM_“ – File Mount Group
FM groups are the entry points to the file list. The backend user assigned to this group can only view files and subdirectory set in this group.
Permissions for files and folders can be set in the tab “Mounts and Workspaces” of the usergroup. it can be found in the lower part of the form labeled “Fileoperation Permissions”.
Alternatively it can be set in the TSconfig field of the group with the following code snippet:
addFile = 1
readFile = 1
writeFile = 1
copyFile = 1
moveFile = 1
renameFile = 1
unzipFile = 0
deleteFile = 1
addFolder = 1
readFolder = 1
writeFolder = 1
copyFolder = 1
moveFolder = 1
renameFolder = 1
deleteFolder = 1
recursivedeleteFolder = 0
These are the settings valid in all file storages. But the permissions can be set per filestorage. In smaller environments usually this is the good old fileadmin. This can be achieved through the following snippet:
The <UID> is the UID of the filestorage, where these permission should apply. The possible values are the same as in the default section.
Just to make it clear: Regarding the permissions, we are talking about the file storage and not the file mount. As far as I know, it is not possible to restrict permissions on a file mount basis. (Please leave a comment, if I am wrong :-) )
If a user must be able to link to a file or folder, which is outside his folder tree, this can be activated via an TSconfig option which, must be set in the userTS
options.folderTree.altElementBrowserMountPoints = /data1,/data2
This option replaces the filemounts of the user with the mentioned directories. Multiple directories can be provides via a comma separated list.
„ACL_“ – Access Control List Group
Groups with the prefix ACL provide the permissions to modules, plugins and tables, which enable the editors and authors to do their work.
There must a basic “Page and content” group, that enables group members to edit pages and content. This defines what every backend user should be able to do.
Every installed extension has its own ACL group. This group contains all permissions that are necessary to work for a backend user with this extension. This includes every aspect, which can be configured in a group: modules, tables for listing and editing, allowed exclude fields and so on.
If you have one extension, which needs different permissions, like creating and editing news articles and providing the news on a page, you must define two groups that contain all necessary permissions. I consider the inheritance of permissions as a bad concept within the ACL groups, because it is hard see all the possible side effects when changing a group.
All of these groups must provide all permission to work independently. There may be no dependencies between these groups. If there are dependencies, you do not remember or are nor documented, this will lead to hard times of failure search.
„R_“ Groups for Roles
Basically it is possible to add all these groups defined in the last chapter to single users. But usually you have several users with the same permissions. A best practice is to group the permissions with “Role Groups”.
Each role needs at least one “DB_” group, one “FM_” group and one “ACL_” group. A “PG_” group is only assigned, if the users are allowed to add and delete pages.
It is possible to assign several roles to one user. The “easiest” situation is, when one user has just one role assigned.
I’m calling it the “easiest case”, because it is only possible to add permissions for the whole system. So you have to be careful when assigning the roles. Different editing and viewing permissions based on page branches are not possible by default.
Let me give an example. Think about two roles:
- an author, who is allowed to edit content on branch A
- an editor, who has additional permissions to create pages on branch B
If a user has now assigned both roles, he will also be able create pages on branch A. If this is a problem for your customer there are two possibilities:
1) Use the extension “be_acl”
With the extension “be_acl” it is possible to add several groups with different permissions for content and page editing to one page. But this extends only the standard permission system. It is not possible to restrict the access to extensions on a page basis.
2) Create a publishing workflow
A publishing workflow serves as a filter, so that nothing unwanted hits the public website. There are at least two solutions: The built-in workspaces and in2codes Content Publisher.
I must admit, that setting backend user (group) permissions is not really fun. But the task of integrating an extension into a TYPO3 instance is only of the state “Done done” if the permissions and fields are properly configured for the editors.
Hopefully this concept helps you to keep the overview over the different permissions and helps to structure this task.