When a user has a personal contact form, a contact tab appears on that user's account page:

By unchecking the checkbox here, all newly created users will not have a personal contact form on their account page. You can still select it to enable one on a per-user basis; the setting here only configures the default for new users. If the setting is enabled on a particular user, other users with the permission Use users' personal contact forms will be able to send e-mails to them using the form.

If you allow anonymous users to perform any actions such as comment or create content on the website, then that content will be shown as being submitted by the Drupal username Anonymous. The name displayed is easily changed here to something of your choosing—a common alternative is to use the word Guest.

Change the value to Guest now.

When modules are enabled for the first time, they may define new permissions. It is generally convenient that your highest permission role is granted these new permissions so that users in that role are able to use and configure the module right away.

The Administrator role is the default role that is assigned the new permissions, but you can use this dropdown menu to change the role to an alternative. For example, you may have a Superuser role to which you want all new module-management permissions to be assigned automatically.

In your site, we can leave this setting as it is.

This screen allows you to define the behavior for newly created user accounts. Firstly, you can determine who is entitled to create new user accounts. The setting here is often determined by the type of site you are building:

Based on the requirements we mentioned at the beginning of this section, we will need to change the setting to Visitors.

We will keep the checkbox for e-mail verification ticked so that people can only create accounts if they have a valid e-mail address. This should reduce the amount of spam accounts.

Unchecking this box will prevent the password indicator showing on the new user creation page. While this is a useful tool to assist the user in selecting a password, some find it annoying and it might not work well on old browsers.

A canceled user account in Drupal does not necessarily mean that the account is deleted. The next option allows you to determine what happens to the user account itself and to the user-generated content when the user account is canceled.

For example, if a user has commented on a news article, what should happen to the comment if the user account is deleted?

The options are given in the following table:

Note that it is possible to set a permission for a role to enable the user to make their own decision on what happens to their content when they delete their account.

For our example, to make sure you don't lose any content if a user account is deleted, you should use the third option otherwise when a key member of the content-editing team left, all of the content they created would be deleted.

Select Delete the account and make its content belong to the Guest user. Now, when a user account is deleted, the author of the article or comment will be shown as belonging to Guest.

There are a number of system e-mails (discussed next) sent in response to certain user-related events.

The from address of the e-mails will default to the site e-mail address set in Configuration | Site information, unless you set a different value here.

For example, you might want the site e-mail to be [email protected] but the from address for automatic e-mails to be [email protected].

These are the emails that are sent out automatically in different user scenarios.

They are triggered based on some of the settings you have just been looking at in the previous section.

You can change the contents of any of these e-mails so that you can set the tone of voice and message to match your audience.

When you edit the templates, note the use of tokens here again such as [user:name].

Tokens are elements that are replaced live by actual content in the message that gets sent out. For example, the [user:name] token gets replaced by the actual username of the currently logged in user, in our case admin.

While some tokens are optional, it's important not to remove key information like the one-time login URL ([user:one-time-login-url]) on a password reminder e-mail.

Available tokens are as follows:

In our scenario, the e-mails that will be active are as follows:

If you are using Dev Desktop for your site development, you will be able to test these e-mails assuming that you used real e-mail addresses when setting up the site and user accounts.