Test cases / checklists to check against while testing Roles and User Permissions on a Drupal site

| | 2 min read

When focusuing on Drupal website development, user roles and permissions are an important way of controlling access to the site. This is more so important when there are multiple individuals besides the website owner who administers the site. Other people can be assigned certain 'roles' which define the kind of access that is to be granted. Basically in Drupal, the Site maintainer and Administrator roles are given all the available permissions and Drupal Administrator role receives all permissions throughout the lifespan of the site. This is not the case for other 'roles', where access within admin permissions and time limits only are granted to users linked to those roles.

A major advantage of adding permissions is that, when a new feature is added to a Drupal domain which is not allowed for everyone by default, this functionality can be made specific for a 'role' or a group of 'roles' but granting access to them alone. Roles are not just a way to group permissions, but they also hide important information about the site as well. For this reason, users, roles and their permissions are imperative and have to be set up and configured appropriately and tested systematically. The major Test cases/checklists to be considered while testing roles and permissions in Drupal are documented here.

Test cases for user roles and permissions:

  1. Ensure the domain allows to create new users with role(s).

    For this

    • Create a test account and assign the created role to it.
    • Then login as the new user and ensure all privileges given to that role.
    • Alternatively, use a different browser (not a new window in the same browser) to test the role without logging out as administrator.
    • Repeat the above steps for all roles and permissions in the site.

    In case a new role arises as a requirement while handling a maintenance site or after the completion of site, then it has to be tested extensively before being assigned to any user. The above procedures are to be repeated in such cases as well.

  2. Ensure that the permissions granted to custom roles are working as expected.
  3. Ensure that "access denied" error message is shown when
    • Anonymous or non permitted users attempt to view a resource which is granted only to certain roles.
    • Anonymous or non permitted users attempt to access a page/URL that is restricted to them.
  4. In case a user has more than one role, ensure that multiple roles and the combinations of those permissions (same user with conflicting permissions) work correctly.
  5. Ensure that Admin can mark/unmark permissions for users via the permissions page and these changes get reflected in the users role as well.
  6. Ensure that user does not have access to permissions once these permissions are taken out from the users role.