Platinum sponsors
Tutorials
The final step in our efforts to get this introduction website running is to look at distributed maintenance - a core requirement to a CMS. We already discussed the difference between frontend and backend users and how backend users were located in the root of the page tree:
The introduction package is shipped with four users. Let's see what they can do. The best way to do this is to logout as admin and log in as one of these users, one at a time.
When you log in as "simple_editor" you will see this when you activate the Page module and select the page "Examples" for editing:
Only the page "Examples" with its subpages. The "simple_editor" is allowed to edit only that branch of the website. But it does not only reflect permission management - it also helps make the system more intuitive and user friendly. As you can see most of the backend modules are not shown to the simple_editor either. The menu to the left contains only the "Page" and "View" modules in addition to the "File" and "Help" module.
Images and Documents are managed in the "Filelist" module. The "simple_editor" sees only a Folder "Documents" which is linked to the folder fileadmin/user_upload/documents/. So all folders he does not need, are hidden.
Now log in as "news_editor".
The "news_editor" is only responsible for writing the news. He should not bother with all the other content of that website. The news are managed via the News-Admin Modul. Just like the simple_editor, he can see only the things, he should see.
Now select the module "News Admin" (#1), close the sidebar (#2) and select the provided path (#3). In the "News Admin" module the user can create and edit new News.
Now check the "Filelist" module.
The "news_editor" has an restricted view at the folder structure as well, but he sees only documents, which are located in fileadmin/user_upload/news/.
Now, log in as "advanced_editor".
The "advanced_editor" sees much more modules and the whole page structure. He is able to do the same as the news_editor and the simple_editor and much more. So, it is possible to restrict everyone to that modules and pages, which he needs to know. Have a look at the Filelist module.
The "advanced_editor" does not see the whole fileadmin folder. But he has access to the "News", the "Documents" and another "Images" folder.
Now we want to know how the users "simple_editor", "news_editor" and "advanced_editor" have been set up! Log in as "admin" again and let's explore it. Select "Edit" for the three users. You will see, that they are almost identical. But they all have a different Group selected.
On the tab "Mounts and Workspaces" there are both "Mount from groups:" are set. Which page and which folder the user can access, depends on the rights which are set at the group level.
It is a good practice to manage the permissions on group basis.
Let's look at the Simple editors group which the simple_editor is a member of.
On the "General" tab you can edit the Group-Name, and write down a short description for that group. If you select an Sub-Group, all permissions from that group are inherited. An user which is in the simple_editor inherits all permissions from the "Simple editors" Group and the "All users" Group.
The "Include Access Lists" is the important point to notice here since that is the reason why we have all these options listed! Apart from those the group contains DB mounts and Filemounts which apply to all users that are members.
Looking at the access lists you will see that (#1) membership of this group will grant access to the Page and View module (unfortunately you will have to know that these codes are the equivalents of the names you know from the menu...).
The tables that a simple_editor is allowed to edit are listed (#2).
Log in as "simple_editor" and then try to create a new element:
Only pages and page content elements could be created. No users, no news elements. Only pages and content elements.
Why this? Well, because "simple_editor" should not worry about anymore than this! He is not the guy in charge of the news, right!
This field (#3) dictates what page types members of the Simple editor group should be able to select. But if the simple_editor creates a new page, he does not have the possibility to change the page type.
That is because the Page-Type is not in the list of "allowed Excludefields":
This is a long list, which becomes even longer with more Extensions installed. It is very powerful, but it takes a little background to understand it.
When tables and fields are configured in TYPO3 (in the internal global PHP array, $TCA) some fields are marked as "excludeFields". This means that the fields are not allowed to be edited unless you have been granted special permission - that is what the "Allowed Excludefields" list does!
This is easy to understand if you take a look at what the "simple_editor" sees when he edits a page header:
Not an impressive amount of fields. In particularly not if you compare it with what you see as "admin" user.
The reason for this difference is that
most of the fields in the pages are marked as "excludeFields" - hence cannot be edited by default - and
that the All Users group where the simple_editor inherits its rights, allows only access to some of these "excludeFields".
Now edit the simple_editor group and select the Page-Type field ("Page: Type") and save the group.
Now log in as simple_editor and edit a page-record.
The simple_editor has now the ability to change the page-type, but as it has been configured in section page types, the simple_editor has only the choice between standard and shortcut.
You can restrict which type of content element a group is allowed to use. If an editor should be allowed to use an plugin like tt_news, it is important to allow the use of the type "Insert Plugin" and to allow in subsection "Pagecontent: Plugin:" the appropriate Plugin itself.
Inverting the behavior
You can change the behavior of this setting in the install tool. If you set [BE][explicitADmode] = explicitAllow you have to select the types of content elements which a group should be allowed to use instead of deny those types.This is actually recommended. First of all it is more secure, as nothing is allowed by default. It is also more intuitive when setting up permissions (because you are giving permissions and not removing them).
DB mounts (database mounts) are used to restrict a user's access to only some parts of the page tree. Each mount corresponds to a page in the tree. The user will have access only to those pages and their sub-pages.
As you see it couldn't be more easy to give a specific user access to a specific part of the page tree - just set the fields value to that page. Or two pages even! You can add any number of "DB mounts" as you like!
The file mount assigned to the simple_editor group is a relation to a simple record created in the page tree root as well:
When you edit it you will see how logically it is configured:
Simply, the directory "user_upload/documents/" (#1) is entered as PATH and the "BASE" field is configured to interpret that path relative to the "/fileadmin/" direcotry (#2). That simple. When a user has a relation set to this record he will have this directory mounted in his Filelist module!
One note to "DB mounts" - if the user has no read access permission to the page and sub pages of the DB mount then it really doesn't matter whatever you have configured - it will not work! And what is read access then? Each page has a permission setting for access like the file system on a UNIX server - there is an owner user, an owner group and then permission settings for each in five different categories; read page, edit page, delete page, new subpage and page content. Normally the default settings are fine enough and using the DB mounts to assign access is probably the easiest way to go. If you run into trouble, just set all permissions to "on" - that will make green starts over the full line (see image below). Of course, if you want to really know the ins and outs of this, go to the Inside TYPO3 document - here you will get the hairy explanation.Probably the best way to show you how page permissions should be set is to view the current permissions of the page tree. This is done by the "Access" module.
You have an overview which user and groups are able to edit which pages. You can change the permissions if you click on the allow/deny Icons. When you look at the ownerships of the pages you can see that the simple_editor actually owns a few pages. He might have been the creator of those. When you create a page you become its owner automatically. But the main point is that the group "All users" is the owner group of all pages. And since "All users" is a subgroup of "Simple editors" as well as a subgroup of "Advanced editors" all members of that groups have access to that pages. But they are still restricted to work within their DB mounts. But with this configuration it is only possible for the owner to delete a page.If an editor creates a new page, he will become the owner of that page and his maingroup (the first one, if he is member for more than one) will be set for that page. But you are free to change that default-values via PAGE-TypoScript configuration.
Let's have a look at that "PAGE-TS-Config". As an admin edit the page "Home" and select the "Options" tab.
In the TSconfig section you can control how the Backend should behave. We do not want to explain now, what you can do with TSconfig, but keep in mind, that you can change how the Backend react - on page basis! Have a look at the TSconfig Reference to get an overview.
With the module "User Admin" you can actually validate that you have set the correct permissions.
This will tell you right away what the combined permissions will be for her.
The first two green stars mean "Read page" and "New content on page" - the red crosses means "Cannot edit, delete and create new pages".But you can also simulate a Backend-User by clicking on the red Switch-to-User Icon. After that you are logged in as that user - and if you log out, you are switched back.
The User Admin module is a great tool to evaluate user settings, compare users etc. Indispensable when you have many users and want to make sure you have control over their rights!.
Maybe you have noticed in the process of logging in and out as different users that an icon like this can appear:
This is just a warning to users that someone else is working on this page at the moment - records are not truly locked in TYPO3 since access to a record should be allowed if people have access. But this warning is a nice touch since it helps people to avoid conflicts. Every time a user starts to edit a content record, an internal flag is set, which lasts for two hours. If the user close this record via save & close or close Button, that flag gets deleted. But if the user just select a different page to edit, that flag stay as it is. So, it is recommended to use the close button, if you are done with an record.
Now, we can create a user who should be in charge for the "Resources" page including sub-pages.
User groups and Users are just records. Copy the backend user group record "Simple editors".
Reload the List.
And paste the copied record in the list.
Users are just records - create a "Backend user" record:
Enter the username, password, group membership:
Take care, that the "Mount from Groups" settings are set:
Save the record and check the new backend user with the switch-user function in the Admin-Tool.
It works:
