In the previous articles of the cycle, we created different user roles and permissions for them. And now it is time to get know about the function of User in managing access permission and how to create and manage users of your site.

A single user account can be given as many or as few permissions as you like via the use of roles. Drupal users are not really anything unless they already have a role that defines the manner in which they can operate within the Drupal framework. Hence, we discussed roles first.

Users can be created in two ways. The most common way is by registering on the site—if you haven’t already, go ahead and register a new user on your site by clicking the Create new account link on the homepage just to test things out. Remember to supply a valid email address otherwise you won’t be able to sign in properly. This will create an authenticated user, with any and all permissions that have been assigned to the authenticated user role.

The second way is to use the administrative user to create a new user. In order to do so, log on as the administrative user and click on Users in User management under Administer. Select the Add user tab and follow the instructions on that page. For example, I created a new forum moderator user by ensuring that the relevant role was checked:

You will need to supply Drupal with usernames, email addresses, and passwords. Once there are a couple of users to play around with, it’s time to begin working with them.

Administering Users

The site’s administrator is given complete access to the other users’ account information. By clicking on the edit link shown to the right of each user account (under the Operations column heading) in the Users page under User management, it is possible to make any changes you require to a given user.

Before we do though, it’s worth noting that the administration page itself is fairly powerful in terms of being able to administer individual users or groups of users with relative ease:

The upper box, Show only users where, allows you to specify several filter conditions to cut down the result set and make it more manageable. This will become more and more important as the site accumulates more and more users. Once the various filter options have been implemented, the Update options allow you to apply whatever changes are needed to the list of users selected (by checking the relevant checkbox next to their name).

Having both broad, sweeping powers as well as fine-grained control over users is one of the most valuable facilities provided by Drupal, and you will no doubt become very familiar with this page in due course.

Click on the edit link next to the forum moderator user and take a look at the Roles section. Notice that it is now possible to stipulate which roles this user belongs to. At present there are only two new roles to be assigned (yours might vary depending on which roles have been created on your setup):

Whenever a user is added to another role, they obtain the combined permissions of these roles. With this in mind, you should go about delegating roles in the following fashion:

1. Define the most basic user of the site by setting the anonymous user permissions.
2. Set permissions for a basic authenticated user (i.e. any Tom, Dick or Harry that registers on your site).
3. Create special roles by only adding the specific additional permissions that are required by that role, and no more. Don’t re-assign permissions that the authenticated user already has.
4. Create new users by combining whatever roles are required for their duties or needs.

If you follow the steps above, you will be sure to always give the correct permissions to each role by avoiding redundancy and only applying permissions incrementally by role. Basically, you are building up a user’s permissions from the most basic to the most complex without having to assign every single permission each time. It should be commonsense (although not a technical obligation) that a forum moderator would have all the permissions of an anonymous and authenticated user, plus a few more. Looking back to the first diagram in the section Planning an Access Policy you can see that, in this case, we would:

1. Define the anonymous user and authenticated user role permissions—an authenticated user should have all the permissions of an anonymous user, plus whatever else is needed by a basic site user.
2. Create new roles with only the additional permissions needed for both the forum moderator and blog user respectively—other than those given to the authenticated user.
3. Assign blog writers to the blog user role (they are automatically given the permissions granted to an authenticated user), and do the same for forum moderators and their role.

Other than using that strategy for assigning roles to users, the rest, as they say, is history. Play around with any new roles you create to ensure they behave as you expect and then move on.

User Settings

This section looks at how the site treats users, rather than discussing what users can and cannot do. However, you will find that some of the information in this section is important for the look and feel of the site.

Click on User settings under the User management. The following set of options is provided, beginning with user registration settings, as follows:

You might want to consider which of the first three options to select quite carefully, depending on how you envisage the site functioning. For example, allowing everyone to read and post comments to the forums, or do whatever, without needing to register first may be ideal. If this is the case, then it is likely that the only people who would need to register are going to be performing some sort of administrative duties, in which case you would probably want to select the first option, or at least the third option.

If you do go for the third option, then check the user list regularly in order to unblock new users as soon as possible. Note that Drupal can be configured to email the site administrator automatically whenever there is a new user registration application.

Additionally, if you enter a message into the User registration guidelines text area then this will appear during the registration process, as shown in the following screenshot:

I specifically added this note in here because it is fairly well known that new users often log in with the one-time password generated by Drupal, but then fail to add their own password before logging off. When they return, they are then locked out because the one-time password has expired and there is no new one set.

The next section on this page deals with the process of user email customization for the various different type of emails that Drupal sends out. There is an interesting facet to this in that Drupal makes certain variables available for use within the static text that is entered. Let’s take a look at how to modify a line or so in order to get the feel for how it works.

By way of example, we will change the Welcome, no approval text from:

Account details for !username at !site

to a slightly sprightlier:

Congratulations !username, you have registered with the !site on !date!

Nothing too complicated here! The keywords preceded by the ! sign are simply placeholders for other values that are inserted into the email, according to how they are set at that particular time. This gives you the ability to personalize correspondence. In this case, the subject of the welcome email for a user registered as David M is now displayed as follows:

The !username, !site, and !date placeholders have been correctly changed to reflect the contents of the variables for that particular setup. There are settings available for several standard emails such as password recovery and welcome (awaiting admin approval). The defaults are fairly sensible and easy to change should you need to. Remember the placeholders that are available for each piece of text are mentioned below the section heading, so play around with them until you are comfortable with their usage:

The final two sections deal with Signatures and Pictures. If you wish to enable Picture support for users, then select Enabled from the list, provide a default picture (if you want one), and click Save configuration (the other settings are fairly self explanatory and sensible, and you can come back at any stage to change them if they are not suitable).

Drupal will set up a pictures folder to hold all of the pictures within the files folder in your Drupal installation. Once everything is done, users will have a new section added to the edit tab of their my account page, like the following figure:

When the picture has been successfully uploaded, it will appear on the my account page, and with the user’s blog and forum posts on the site. If the image does not appear and you end up seeing a link, something like the following:

…then you will need to ensure that you set the correct upload module permissions on the Permissions page, as follows:

Remember that since the forum administrator user automatically receives all the permissions of the authenticated user, it is not necessary to enable the view uploaded files permission for the forum administrator as this would be redundant and would make the purpose of your user less clear.

It is possible to control where the user pictures are displayed by selecting the Configure tab of the Themes page under Site building and checking the relevant picture related checkboxes, as shown in the following figure:

Allowing users to incorporate pictures into a site is a good way for people to be able to personalize their contributions, and also gives everyone something visual to associate posts with. This is a great way to foster a community, as it helps give different users an identity of sorts.

Changing the picture is easy! Simply modify it in the Picture section of the user’s edit page, as shown in the following screenshot:

That is pretty much the end of the line for configuring users. There are still a few more things we need to discuss with regards to security before we can move on though.