Workbench Access Configuration

Last updated April 13, 2013. Created by stevector on May 27, 2011.
Edited by LeeHunter, agentrickard, jbylsma. Log in to edit this page.

After setting up permissions, you should proceed through the steps below.

Access schemes

As discussed in the Installation section, Workbench Access auto-installs a test configuration for you. This process is designed to help you understand how the module functions.

When you are done testing, the next step is to decide on the active access scheme for the site. The access scheme defines how editorial sections are defined and managed.

The Workbench Access settings page shows the available access schemes. By default, these are Menu and Taxonomy.

The form element will look similar to:

You must select one option (Taxonomy is the default). Note that once your site goes live, changing this value may disrupt your workflow.

After selecting the active scheme, you can enable the top-level sections for that scheme. For taxonomy-based access, these are vocabularies. For menu-based access, these are menus.

The form element will look similar to:

You may activate multiple top-level sections. In our example documentation, the University would be a top-level section. By default, the active top-level section is the Museum vocabulary created during installation.

Enabled Content Types

This form section is collapsed by default. It allows you to select which content types should be managed by Workbench Access. This feature is particularly useful in cases where there is a content type, like a blog post, that anyone may edit.

Expanding the form element will show check boxes for each content type:

Normally, you would select all content types to be governed by Workbench Access.

Access Control Fields

This form section is new, and a bit complex. It is only available if you disable the "Require a Workbench Access form element" option.

When you disable that option, the module will attempt to use Drupal's native fields for access control. That means that each content type that should be under access control must have a field assigned that makes reference to your active scheme.

If you use the menu scheme, this field is provided automatically by Drupal core. However, if you use a taxonomy scheme, you must add a term reference field to any content type that will be under access control. That term reference field must be set to one of the active vocabularies that your access scheme uses.

The form element looks like this:

The form element for each content type will either give you a select list of the fields that are available for use or a message that a) no fields are available, or b) that the content type is not configured for access control.

If no fields are available, you must add a term reference field from the content types administration.

When editing fields that may be used for access control, a form element will be available on the settings page:

If this field is present but cannot be selected, then the field is not a term reference field and cannot be used.

The Field Property module

The Access Control Fields section contains a note about the Field Property module. This module ensures that every revision of a piece of content has the same value for selected fields. We recommend this approach because term reference fields store revision changes, but Workbench Access controls do not. That is, if you set the active revision to be in the "Museum" section, but an earlier draft is assigned to the "Gift shop" section, Workbench Access will apply the "Museum" access rules to all revisions of that content.

Since this rule can be confusing to editors, the Field Property module ensures that changes are propagated across all revisions.

Workbench Access message label

In the user interface, Workbench Access sets certain messages, such as the assigned editorial sections and the form label.

These settings lets you change how the item is labelled. The default is "Section". You may prefer another term like "Editorial Team."

Automated section assignment

On the settings page is another checkbox, labeled 'Automated section assignment'. This optional setting is enabled by default.

This setting automatically declares that all elements of the selected access scheme are active editorial sections. if you need the advanced configuration options described in 1.2.2 Ignoring sections, then you should uncheck this box.

If you leave this box checked, you can skip the Access Sections configuration below, since your sections are automatically configured for you.

Allow multiple section assignments

By default, content can only be assigned to one section at a time. This default reduces complexity. If you wish to allow content to be assigned to multiple sections, enable this setting.

Require a Workbench Access form element

This setting replaces the information in the Access Control Fields section of this document.

If this setting is enabled, all content types that are under access control will have a new field added to them. This field is the Workbench Access form element. It cannot be configured in the same manner as native fields, and it may require duplication of data entry if you use section assignment for both site architecture and access control.

For those reasons, some people prefer to use the more complex (but more flexible) Access Control Fields configuration.

This setting is enabled by default.

Access Sections

Once you have declared an access scheme, you may enable the sections for that scheme. This process can be automated (as explained above) or manual.

Access sections are configured on the Sections tab of the settings. This page shows the hierarchy of all the active schemes on your site.

Once you have configured these options, you may assign editors to sections.

Manual section configuration

Each top-level item and its children are displayed in a separate fieldset. If a fieldset has no active sections, it will display collapsed.

The default page looks like so:

Items are ordered by their parent->child relationship. The hierarchy of your access scheme is represented by the -- marks in the interface. In this case, we can see that:

Library Visitors is a child of Library is a child of All of Museum.

Your editors may be assigned to any active section. To disable a section, uncheck the option and save the configuration.

Note that disabling a section will remove any editors from an existing setting. We recommend configuring this screen once for your site.

Automated section configuration

If using automated sections, as described in 4.1.1, you will see a message at the top of the Sections page:

All sections are set to be active automatically. Disable the Automated section assignment option to make changes.

If this is the case, all options will be disabled and the submit button will be removed.

Editing sections in native forms

When using the Menu or Taxonomy schemes, you may enable or disable sections when using the native editing forms for those modules. Only roles with the 'Administer Workbench Access settings' permission may perform this action.

At the bottom of a form, look for the check box:

If using Automated section configuration, these checkboxes may be selected and disabled for you. Otherwise, select the proper status for each item as you edit.

Note that removing a section also removes all editors and content from that section.

Assigning editors to sections

The Editors tab shows you the active editorial sections for your site and the number of users assigned to each section. The page is located at: (admin/config/workbench/access).

This page shows all active sections, ordered according to the hierarchy.

In the secondary column is the count of the users assigned to the section as editors. In a default installation, only one editor is assigned (user 1) to the Museum section.

Clicking either the section title link or the editors count link will take you to a screen that shows a list of active editors for that section.

From this screen, you may add editors by using the autocomplete text form labeled 'Add editors'. Simply start typing the username to find a list of matching records. Once you have selected a user, submit the 'Update editors' button to save the changes.

You may remove an active editor by checking the 'remove' option next to a username and submitting the form.

Users who may 'Assign users to Workbench sections' may also assign editors from a user account page. Click on the 'Sections' tab of the user's account to see a list of all sections. Simply check the boxes for the desired assignments.

When adding an editor, remember that permissions cascade from parent to child. If you want an editor to access the entire Library section, you only need to assign that user to the Library section, the child permissions are inherited automatically.

Assigning roles to sections

Similar to the Editors tab, the Roles tab presents an overview of active editorial sections and the assigned roles for those sections. The Roles tab is located at (admin/config/workbench/access/roles).

Click either the section or role count links to enter the role assignment screen. This screen also has two parts. The first is a table showing all users who are in the roles assigned to the section. The user's role(s) that grant this access are shown as well.

The second element is a set of check boxes for each role which has the 'Allow all members of this role to be assigned to Workbench sections' permission. This part of the form will look similar to:

Simply check the roles that you wish to use for this section. This feature will automatically assign all users of that roles to be editors of the section.

Technical note: The role settings are applied dynamically and not stored with the user account. In effect, if you assign an editor to a section, the editor must be manually removed from that section to remove access. However, if you assign a role to a section, all editors in that role can be removed by disabling the role's access.

For example, if a user named 'falstaff' is assigned as a Museum editor, and falstaff is in the 'administrator' role, removing the administrator role from the Museum section will remove all administrators _except for_ falstaff, since his assignment is specific to his account.