Drupal's default methods of handling user names, emails, and registration processing work pretty well out of the box for many web sites. Drupal assumes your users are online, have unique email addresses, and that you want to create a site that grows organically as users find it and register themselves. Drupal out of the box may not work so well for real-world groups of people where the group already exists and consists of specific people who may or may not be online, may or may not have unique email addresses, and may or may not be able or willing to register themselves on your site.

Some good examples of the problems I have run into are creating web sites for families, clubs, and churches, but the same problems exist for any other real world organization or group. They have established groups of members, some of whom may share email addresses or have no known email address. And in these cases the administrator will probably create user accounts for everyone rather than waiting for users to self-register. On top of that, we may want some control over usernames so that users can recognize each other once they do get online, by forcing the username to be FIRSTNAME LASTNAME.

This creates several problems that have to be overcome creatively. After several years of trying various approaches, here is a summary of the problems I ran into and the ways I eventually solved them. I have included links to the ones I discuss, with the number of downloads in the week of November 22 as a measure of how commonly used they are.

Some emails are shared

Drupal expects each user to have a unique email address, but many people in these groups share a single email address for a whole family. The parents may share an address because they don't know how to set up another email account and consolidate it with the one they are used to using. If they set up another one just to gain access to a new site, it is likely they won't ever actually check that address anyway, so they might miss important messages. Plus if there are children in the family, children and parents probably share an email address so the parents can stay on top of the messages the child is sending and receiving, and in that case they won't want the child's email messages going someplace else. So sometimes it is not a good idea to require users to create a new, unique, address.

There is a Drupal module called Shared Email (280 downloads) that allows more than one user to register with the same email address. That's one way to solve the problem, but I ended up with a different solution that doesn't require any extra modules. Users can share an email address and still create different accounts if they use 'Sub-addressing' (see http://en.wikipedia.org/wiki/Email_address for more about that topic.) Basically, each user of a shared address can add '+tag' or '-tag' to the name part of the address and it will still go through as a valid address that will end up in their shared email account. For instance, if Bob and Cindy share the email address 'smiths@yahoo.com', Bob can create an account with the email address of 'smiths+bob@yahoo.com' and Cindy can create a different account with the email address of 'smiths+cindy@yahoo.com'. The email addresses are unique, so Drupal will let them create different accounts, and messages to either address will land in their shared email account. They can even use this feature in their email software to send messages for Bob and Cindy into different folders. With this solution, you just need to explain this option to users, perhaps by overriding the theme for the user registration form with a better description.

Some people don't have email addresses

This problem was a bit tougher to overcome. You can't leave the email address empty, and you have to be careful about using made-up email addresses like 'user@test.com' because you will be sending out email to another domain that may actually exist. I found a module that looked like it might work, the Local Email module (45 downloads). This module creates a dummy email address for these users using the system domain, and then provides a way for them to log in using pre-created questions and answers. I was concerned about security with this system and the module seems neglected, plus it solved the wrong problem for me. My users without email addresses were not web users and would not be logging in. If they actually want to use the system and log in and are knowledgeable enough to do that, they can get an email address.

In my case, I just needed a way to create a user record so they will show up in some directories and lists, these users would not need a way to log in nor would they need any way to register themselves. And the solution for that was to use sub-addressing again. I created email addresses like 'nomail-1@mydomain.com', 'nomail-2@mydomain.com', etc. It is a valid email address and email will actually go there, but I can use a garbage account for that purpose. I can also use that value in Views as a filter to find users that do or do not have valid email addresses.

We want to force FIRSTNAME LASTNAME

We can set this up intially the way we want for any user accounts we create, but we have to keep them current if names change or there are duplicates, we have to notify users about what name we set up for them and educate them about using it, and users can change their usernames and break everything if they want to. A better solution would be to create separate fields for the first and last name that the administrator or end user can create and keep current, then automatically use those names wherever the username would show up. I spent time exploring ways to auto-create the username out of the field values, and there are patches here and there to do that in various ways, but all of them seemed to have reports of problems.

I finally realized a better solution was to ignore the username value and enable the Real Name module (4,442 downloads) to just display the names the way I wanted them. We can set up fields for First Name and Last Name in the system, either by turning on the core Profile module and creating profile fields, or by enabling the Content Profile module (12,287 downloads), and setting those fields up in the Profile node type. Once the fields exist, the administrator can visit the Real Name settings page (in the User Administration area) and identify which fields to use for the user's 'Real Name'.

Once I had this working well, the actual username isn't really shown anywhere, it is only needed as a way to login. And for login, it is actually easier to just let people login with their email address. The Logintoboggan Module (14,257 downloads) allows users to login with either their username or email address, so that was my first solution. But then I realized that if I want users to login with their email address and have the system automatically display their 'Real Name' instead, that the username ends up just being an annoying, and confusing, extra field to fill out. What I really wanted was to force everyone to login with their email address and get rid of username altogether. I finally found the Email Registration Module (1,484 downloads) and turned that on instead of Logintobbogan. That module hides the username on the login and registration forms and changes the form description to eliminate any reference to 'username', telling users to use their email address to login.

The administrator will be creating the account, not the end-user

If the administrator creates the account, the administrator will have to create both usernames and passwords for each, possibly before the site is live. That means we need an easy way to auto-create a password. There are two modules that help with auto-creating passwords, Generate Password (569 downloads) and Password Quick Set (46 downloads). Generate Password works only when a user is created, and has some settings where the admin can choose whether the user will have a choice to create their own password or if the password will be created for them. Password Quick Set does nothing when a user is created, but adds a button to the user edit form for administrators to allow them to create a new random password for an existing user. So they fill different needs and don't seem to step onto each other, and you can use either or both.

If the administrator creates the username, we need a way to let the users know how to login. If the site is already live, you can opt to send email messages to the users as their accounts are created to tell them what username and password to use, but if you are creating users before the site is live that won't work. For that situation we can create random passwords using one of the above methods, and then send an email out to all users when the site goes live telling them that they can override our temporary generated password with the actual password they wanted to use by using the Drupal feature to reset your password.

The administrator may need to mass-create users

Another issue when the administrator creates accounts is that we want to have some easier ways for them to do so. There are a couple modules that can be helpful here. I have used the User Import module (2,737 downloads) to import a list of user data from a comma separated file created from a spreadsheet. Also handy is the User Plus module (1,764 downloads), which creates a table where you can input many usernames in a single submission. The only downside of these methods is that they don't use the standard Drupal user forms, which means that some other modules won't integrate with them. For instance, the modules to auto-generate passwords and change usernames to email addresses won't do anything if you use User Plus to create users. But they have numerous handy features of their own. User Import has its own method of auto-generating passwords, and both allow you to assign roles and required Content Profile fields (like FIRSTNAME and LASTNAME) to the users as they are created. Another method of importing user data is to use the Feeds or Feed API modules, there is some how-to information from Development Seed.

Non-administrative users may need to be able to create other users

This is a less common situation, but it does come up. For instance, you may have a family site where you want a parent to create accounts for their children or you want Organic Groups group administrators to be able to create accounts for group members, but you don't want them able to touch any other user accounts. I have found two modules that help here, but both have limitations. One is the Subuser module (48 downloads) and the other is U Create module (1,447 downloads).

The Subuser module allows you to define a role that can create subusers and maintains a relationship between the original user and the subuser, allowing you to name the relationship. So you can call the creator a 'parent' and the target a 'child' and the parent will see links to the children's accounts on his account page. The module doesn't use the standard Drupal user input forms, so it you can't create or see profile fields, and it has a buggy method of letting the 'parent' see a user administration page of only their users which could be fixed by using Views and Views Bulk Operations to create a custom user administration page instead of the system page.

The U Create module lets and user with the right permissions create a user, and it integrates into Organic Groups so that the created user can be assigned to specific groups. But, again, it doesn't use the standard Drupal user input forms so there is no way to create profile fields. U Create does not create any relationship between the creator and the user or provide any way for the creator to edit the user account, only a way to create a new user.

The main problem with both solutions is that Drupal has lots of ways of allowing you to control which nodes you can edit, but fewer ways to control which users you can edit, so all the methods of trying to do this end up being less than ideal. Maybe this problem will be solved in better ways in future versions of Drupal.

Comments on this post will automatically be closed three months from the original post date.