In order to work with permissions, click the permissions tab on the access control page and you should be presented with a screen much like this (notice the new Forum Moderator user role on the right-hand side of the page):
As you can see, this page lists all of the available permissions down the left-hand column and allows you to enable or disable that permission by checking or un-checking boxes in the relevant column. It is easy enough to see that one simply goes down the list selecting those permissions required to be given for each role. What is not so easy is actually determining what should and shouldn't be enabled in the first place.
Notice too that the permissions given in the list on the left-hand side pertain to specific modules. This means that if we change the site's setup by adding or removing modules, then we will also have to change the permissions on this page. What this means is that:
What else can we learn from the permissions page shown in the previous screenshot? Well, what does each permission precisely mean? There are quite a few verbs that allow for completely different actions. The following lists the more common, generic ones although you might find one or two others crop up every now and then to cater for a specific module:
- administer: gives the user the ability to affect the function of a module. For example, granting administer rights to the locale module means that the user can add or remove languages, manage strings, and even export
.pofiles. This permission should only ever be given to trusted users, and never to anonymous users. - access: gives the user the ability to make use of a module without being able to affect it in any way. For example, granting access rights to the comment module allows a user to view comments without being able to delete, edit, or reply to them.
- create: gives the user the ability to create content of some sort. For example granting rights to create stories allows users to do so, but does not also give them the ability to edit those stories.
- edit own: gives the user the ability to work with the content they have created. For example, granting edit own rights to the story module means that the user can modify their own stories at will.
There are also other module-specific permissions available, and it is recommended that you play around and understand any new permission(s) you set—most are pretty self explanatory.
Now, as the permissions given to the default roles are pretty sparse, you will probably want to take a look at what those users can do at the same time as you work on any new roles. More than likely, you will want to allow anonymous users to access much of the site's content, without allowing them to modify it in any way. I'll leave those choices up to you. But how do we go about setting up the required permissions for the Forum Moderator user?
If we look down the list of permissions shown on the Permission page, we see the following forum-related options (at the moment, the Forum Moderator user permissions are those in the outermost column):
Enabling these three options and then testing out what new powers are made available should quickly demonstrate that this is not quite what we want.
If you are wondering how to actually test this out, you will need to register a new user and assign them to the Forum Moderator user role. The following section on Users explains how to create new users and administer them properly, so if you are unsure as to how to do this, jump ahead quickly and check that out so that you have a new user to work with.
The following point might make your life a bit easier:
Assuming you are happy to test out the new permissions one way or another, you will find that the forum moderator can access and work with all of the forums, and we want to confine this particular user to only the Conservation-related topics. We need something more specific—perhaps in one of the other modules?
Looking over the remaining permissions we can see that there is an administer nodes option— let's try that. Disable the administer forums option and enable the administer nodes option for the anonymous user before saving and logging out. You should now find that the Forum Administrator user can edit any posts to the forum quite easily by selecting the content link in the main menu. So, what's the problem? Well, for a start this user can now also configure all the different types of content on the site, as well as edit any type of content including other people's blogs. This situation is worse than the first one!
Oh dear, despite the fact that we have quite a bit of control over who does what at the moment, there is already an indication that there are some things that are not easily done without help from elsewhere. In order to complete this task we will need to make use of the Taxonomy Access Control module that we downloaded and installed in the previous chapter, because the solution to the current problem lies in forcing Drupal to define users who can access and manipulate content based on its category.
Assuming you have this module enabled, head on over to the access control section under the administer link (you will need to be logged in as the administrator again). You should notice that there is a new tab on this page entitled category permissions. This page should contain a list of the available roles and the ability to edit their category permissions. Straight off the bat, however, it probably won't work because you need to enable the module first. If this is the case, the following link should be shown:
They're the boss! Head on over to the taxonomy_access page under settings and enable the module. Now when you view the category permissions page in access control, you will see a list of the available roles, ready for you to work with. Click the Forum Moderator user in this list to see the permissions for any and all types of categorized content (incidentally, don't worry if you are unsure about content taxonomy and categories as yet—all this will be discussed in the following few chapters), like this:
There is a lot to think about here! Now there is a taxonomy access help page at taxonomy_access under help in the administer section, which you should read along with this. Let's take a quick look at all of these options in action as well.
The first three column-options available are View, Update, and Delete. These are fairly self explanatory and allow the user to view, work with, or remove content respectively. The next option, Create, allows users to fix the specified term to a post. List causes the specified term to be displayed on a posting's page, in a category list or even in the breadcrumb navigation. Ensure that you have List enabled if you want that term to actually appear in, on, or around your pages—leaving it disabled could have some unexpected results.
The first three options have three settings to choose from:
- Allow (A): Grants the user the associated permission for any given category
- Ignore (I): Effectively denies the user the associated permission but can be overridden by using other Allow commands
- Deny (D): Denies the user the associated permission for any given category
The second bullet in this list brings us to an important point concerning precedence:
Why is this important? Think about what would happen if at some stage a posting is linked to several categories (this scenario is possible, and we will come across it later in the book). If permissions are set up such that a user has the Allow directive set for a term in one vocabulary (vocabulary, and other taxonomy-related terms are all discussed in detail in Chapter 7 on Advanced Content), but Deny set for that term in the other, then the Deny directive takes precedence. This is why Ignore is so important because it allows you to effectively deny a permission for a term in one category without affecting others.
The drop-down lists shown at the top of each vocabulary allow you to make generalized statements that influence the entire column. For example, you might want to allow a user to view all the terms in a vocabulary rather than have to change each and every setting manually. If this is the case, simply select Allow all from the drop-down list and away you go. Below the drop-down list is the Default option, which causes any new terms in that column to be automatically endowed with the permission you set here—if you are not sure what you want here, stick to Ignore.
Now, if you attempted to access the forums using your Forum Moderator user with the default permissions set, you will more than likely be disappointed:
This is really to be expected (despite the fact that we know that the forums do exist) because by default the forum moderator has only Ignore directives set. Set your page to look like the following, and ensure that your Forum Moderator user has permission to create forum topics and edit own forum topics (set on the permissions tab of the access control page):
Clicking Save category permissions captures these settings, and you can now try out the new permissions. Specifically, we need to check whether this user can perform the expected operations. What are the expected operations? Given the settings, we want the user to be able to access only the Commercial Fishing forum within the Conservation container. The user should be able to post to this forum as well as edit any posts within this forum (even if they are not the user's own posts).
Looking at the Forums page from the perspective of the forum moderator, we get the following:
This is perfect! The user can only access the one forum as expected, but the real test lies in whether we can edit someone else's posts. In this case, I used my administrator user to post a note to this forum, and accessing it via the Forum Administrator user brings up the following page:
From this you can see that the List directive that was enabled is working correctly because the taxonomy term Commercial Fishing is displayed. Obviously, the View and Update directives are working fine because we can see the post and can edit it. If you would like to confirm that the Delete directive is working, simply click on edit and check that the option to Delete the post is available at the bottom of the page.
This is great news! Having tested the simplest case of granting permissions on a single forum, you now have to go back and set all the permission that will be needed. In doing so, it is likely that you will come across a few other interesting points. I will cover a couple of them here in detail—ultimately, you need to practice working with taxonomies and permissions to be able to achieve exactly what you want. I suggest waiting until we have covered taxonomies in more detail before diving in, though.
Go back to the category permissions page for the Forum Moderator user, disable all of the Create directives, and save your settings. Now try post a new forum topic using the Forum administrator user. You should be presented with a page like this:
What's the problem? Submit this message and then go back to the forums to view it. Do you see the issue? We have disabled Create, so we are not given the option of specifying which term this post should be associated with. So, because we can only view the Conservation container and the Commercial Fishing forum, the new content is not available to us."But we would ultimately allow the forum moderator to "View" all of the forum topics anyway", you might counter. This is true, and doing so would certainly make the post accessible, but it wouldn't help the forum moderator to actually post to the forum he or she is in charge of.
This has hopefully demonstrated that choosing your settings is quite a subtle task. Re-enabling the Create directive and attempting the post again brings up the following extra option, which then does the trick:
Now when this content is submitted, it is correctly displayed in the Commercial Fishing forum. We will leave taxonomy permissions there because we have yet to discuss taxonomy in any detail, and you will be able to practice more effectively once we have discussed the ins and outs of taxonomies. Some of you may be wondering, for example, how to post this note to all the forums within the forum administrator's remit instead of one at a time—tasks like this will be dealt with in Chapter 7.
Once you are happy that you can control the Forum Moderator user, let's try something slightly different. Click the permissions tab of the access control page under administer and ensure that your anonymous user has all the available forum module permissions selected. Save these changes and log out of Drupal. Now, you have already seen what these permissions do; the anonymous user, most likely, will be able to administer all the forums. Sure enough, the main menu shows us the link to go to the forums as well as a link to administer forums. Click on the bottom link, which leads to the administration page for the forums. You should notice something fairly odd, like this:
Hmm, that's strange because we know there are forums there. Let's try the other forum link in the main menu. This time, following that link simply brings up a blank page. That's very odd, we have full administrative permissions on the forums, yet Drupal is acting like they don't exist. Can you figure out why?
As the administrator, remove the forum module permissions for the anonymous user in the access control section and save the settings. Now, click on the category permissions tab and then select the edit link for the anonymous user. You will be presented with the same untouched settings page that we initially saw for the Forum Moderator user. The answer should now be apparent. As the anonymous user has no permissions set here, we were effectively giving Drupal conflicting instructions by saying that this user is a forum administrator who is not allowed to access anything related to the taxonomy terms within the forums.
In our case, we would like anonymous users to be able to view all the content in the forums (although, if there were any topics you wanted to hide you could simply leave them unchecked) so we choose Select all from the List drop-down and Allow all in the View column drop-down and save the settings. Take a look at the results as the anonymous user. You should find that it is possible to view all the forums as expected, but you are required to login in order to post anything.
This has exemplified the need to thoroughly test your site regularly so that unforeseen changes don't have disastrous effects. You may have asked yourself at some stage during the discussion on permissions: Can one user belong to several roles? The follow-up question to this is of course What permissions does a user who belongs to more than one role receive? In order to answer these very important questions, let us take a look at the next topic in our discussion.