The final steps in our efforts to get this website for "FC Bigfeet" 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:

Three users already exist. 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. All passwords are "football" for now.

"christine"

When you log in as "christine" you will see this when you activate the Page module for editing:

Only one page!! Yes, "christine" is allowed to edit only one single page, the "This week" page. That is her responsibility. We don't want her to tamper with anything else - just that page.

This is quite cool - she only gets to see the page she needs to see. So not only does it 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 Christine either. The menu to the left contains only the "Page" and "View" modules in addition to the "Help" main module which does not require special permissions.

"jonathan"

Now, log in as "jonathan":

Jonathan is the trainer of the Youth section of the club. So he is put in charge of the pages in relation to that! Just like with Christine he can see only the things he should see.

Contrary to Christine he has also been granted access to the Filelist module: If you look what is in there you will see a slight difference to the view you get as the "admin" user:

The root folder is not "fileadmin/" but the Image Archive folder directly!

Now we want to know how the users "jonathan" and "christine" have been set up! How did he do it, that guy behind all this? Well, log in as "admin" again and let’s explore it!

Try to select "Edit" for the two users, "jonathan" and "christine". You will see that their profiles are "identical" in two areas: They have the same group membership (#1) and they both have a "DB mount" (#2, the starting page for their individual page trees). But jonathan is also allowed access to the "file" and "file_list" modules (#3) and in addition he has been assigned the file mount "Image Archive" (#4). This makes sense if you think about it since those features were the ones we noticed when we logged in as him!

File Mounts

The file mount assigned to "jonathan" 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 "Image_Archive/" (#1) is entered as the PATH and the "BASE" field is configured to interpret that path relative to the "fileadmin/" directory (#2). That simple. When Jonathan has a relation set to this record he will have this directory mounted in his Filelist module!

DB mounts

The DB mounts (database mounts) are very easy to understand - basically they point to the page in the whole page tree which you want to become the root page in the page tree the user should see! 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!

Page permissions

Ahh, yeah. 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? Well, 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 stars 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.

When you look at the ownerships of the pages you can see that "jonathan" 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 "GENERAL" is the owner group of the pages that Jonathan and Christine have access to - and since they are both members of this group they can access the pages alone by this fact (still they are always restricted to work within their DB mounts!). The only thing they cannot - at least "christine" since she doesn't own the "This week" page - is to delete the page with a membership of the GENERAL group. You can see that when you click one of the pencils:

As you can see the "Delete page" right is not set for the owner group of one of those pages. You can do that if you need Christine to delete it - but most likely she should not be able to do so. In fact you might even restrict access further by not allowing her to create sub pages nor edit the page title:

The result is this in the permission overview:

Validation of settings

With the module "User Admin" you can actually validate that "christine" now has the correct permissions to this page:

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"

The same view for jonathan might be worth a look:

This clearly shows what we would expect - the file mount and the webmounts as we experienced them earlier. Jonathan cannot delete the main page "Youth Section" though.

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!

Let’s look at the GENERAL group which "jonathan" and "christine" are both members of - what is inside it?

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 can also contain DB mounts and File mounts which will then apply to all users that are members.

Modules

Looking at the access lists you will see that (#1) membership of this group will grant access to the Web, Page and List module (unfortunately you will have to know that these codes are the equivalents of the names you know from the menu...).

Tables (modify)

Secondly the tables that "jonathan" and "christine" are allowed to edit are listed (#2). Now, can that be true? Can they only view the pages and page content tables? Well, let’s try and log in as "jonathan" again and then try to create a new element:

How interesting - only pages and page content elements could be created. No users, no guest book elements, no news elements. Only pages and content elements.

Why this? Well, because Jonathan should not worry about anymore than this! He is not the guy in charge of the news, right!

Page types

This field (#3) dictates what page types Jonathan and Christine - or members of GENERAL group - should be able to select. Let’s make the "Jonathan-test" again and edit a page header:

With Jonathans login we try to create a sysFolder. Will we succeed?

Nope. Sorry, Jonathan. Cannot do.

Allowed Excludefields

This is a loooong long list. But important. And powerful! But it takes a little background to get 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 "jonathan" sees when he edits a page header:

Not an impressive amount of fields. In particularly not if you compare it with what you see - the "admin" user:

The reason for this difference is that

So in fact we should be happy that Jonathan actually can edit the fields "Type", "Hide page", "Start" and "Stop" since he wouldn't have been able to do so if the GENERAL group didn't assign that specific permission!

Record locking?

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.

Well, with all our brilliant knowledge we can now create a user  who should be in charge of the second website in our database - the Fan Club site.

Step 1: Create the user

Users are just records - create a "Backend user" record:

Enter the username, password (football), group membership and the DB mount:

Save "phil".

Step 2: Check the new user

In the User Admin module, check that "phil" is correctly granted access to the "Fan Club" site:

Oops - typical error. The page permissions are not with us here! But that is simple to change - go to the Access module:

Step 3: Set the correct Page Permissions

Edit the permissions for the root page of the site:

Then set the owner and group and make sure the recursive setting is selected - this will apply the changes for the root page to subpages down to 1 level:

Nice:

Step 4: Final check

In the "User Admin" module "phil" checks out fine now:

Step 5: Test the new user

Finally log in as "phil". A neat trick is to just press the "SU" (Switch User) button in the User Admin module - that logs in without the user of a password (for "admin" users only of course...):

And "phil" really checks out well - he has access to the pages of the new website!

It's that easy.