Any page element that a user can view or hear or otherwise interact with, such as a menu link, is available for doing so because the user, via a role, has been given permission to do so. This is a very important concept, so I will give an example. You have no doubt seen a Terms and Conditions link on most sites.

On a Drupal site, if you see such a link, it is because your user role has been granted permission to access that content (the Terms and Conditions page). Were that permission not granted for your user, the link would probably not be visible. Were it still visible, or were you to enter the URL for the page in your browser, you would receive a message stating that you have not been granted access to that content. 

Because permissions can be granular and detailed, there are a lot of them, and adding modules will typically add more to the list. We're going to focus on a subset of them to keep things simple.

With that warning, let's take a look by clicking the Permissions tab at the top of the page, which will take us to admin/people/permissions.

The structure of the permissions page is all permissions provided in a scrollable table. Across the top of the table are the roles defined on the site. You'll see that they are the same as those that were listed earlier. Down the left-most column of the table is the list of permissions for actions categorized by alphabetical topic and/or name of the module that defines them. 

The manner of management is quite simple. If a box is checked, that column's role has the listed permission. For example, looking at the first permission, which is associated with the Block module, the ability to Administer blocks has been granted only to those users having the Administrator role.

Rather than scroll down and up for each of the roles, we'll approach this by permission, so that we only have to scroll once. In the following table, I will provide each of the categories and permissions within it that require our attention, as well as what the checkboxes should look like after you have checked the appropriate ones to accomplish the grants we defined earlier for our roles.

I will only provide rows for those permissions that require a setting change. For example, you will notice under the category of Comment that already all authenticated user types have the ability to post comments, while Anonymous users have the ability to view comments, so no changes are needed, which is why that row won't appear in this table:

Most of the permissions in the preceding table relate to CRUD operations on specific content types. That is, being able to create (add), edit (update) and delete content of a specific type, such as the Appointment type that we created. You can see that we granted permission to perform such operations to Consultants, but not to Editors, whereas we granted permission to perform those same operations on Article content to Editors, but not to Consultants.

You will notice that some of the permission descriptions look very similar, such as:

• Appointment: Edit own content
• Appointment: Edit any content

The difference between the two is that with the second, the user is able to edit Appointment content regardless of who created it, whereas with the first, the user needs to have created it. 

The final permission, View own unpublished content, is worth noting as well. Unless this permission is granted, if a new piece of content is saved as unpublished, its author can no longer access it, only being able to access content marked published. With this permission, the user can also access his unpublished content, which is necessary for working with drafts.

You might also notice that permissions for reading/viewing specific content types were not present. That is because, while there is a permission for viewing published content, that is as granular as the permissions get for viewing content; there are no permissions regarding viewing a particular content type. There is, however a module that provides those permissions, which we will add in Chapter 5, Making Drupal Even More Useful. Once we have those permissions available to grant, we can ensure that only the roles we select can comment on a specific content type, because if you can't view the content, you can't comment on it!