This is a port of the README file within the Workbench Module. It may need to be adapted to fit the Handbook style.

In the above scenario, The University is the root element of the hierarchy. All other elements are "children" of this "parent" item. Individual items can themselves have children.

For our University, the following relationship exists:

• Alumni is a child of Students
• Students are a child of The University

When we grant access rights for content editors, we can therefore decide if a user should be able to edit any of the following:

• All content in The University and all its children
• All content in Students and all its children
• Only content in Alumni

In practice, this means that the Dean can have wide authority over that part of the website that she is responsible for, while a student intern might have very limited roles.

In our University, we have three types of web site users:

• Editors are responsible for the entire site.
• Deans are responsible for an entire College.
• Writers are responsible for specific departments.

In this scenario, Workbench Access would be configured as follows:

• Jane Doe, site editor
  • Assigned to The University section.
  • Can edit content on the entire site.
• John Smith, Dean of Medicine
  • Assigned to the School of Medicine section.
  • Can edit content in the following sections:
    • School of Medicine
      • Dentistry
      • Medicine
      • Nursing
• Ken Johnson, Alumni relations director
  • Assigned to the Alumni section.
    • Can edit content in the Alumni section.
• Paula Thompson, Dental school administrator
  • Assigned to the Dentistry section.
    • Can edit content in the Dentistry section.

What makes this system powerful is the inheritance of permissions based on the
organizational hierarchy. Put another way, you will see that:

• Jane Doe
  • Can edit all content, including that posted by:
    • John Smith
    • Ken Johnson
    • Paula Thompson
• John Smith
  • Can edit School of Medicine content, including that posted by:
    • Paula Thompson
• Ken Johnson, Alumni relations director
  • Can edit content in the Alumni section.
• Paula Thompson, Dental school administrator
  • Can edit content in the Dentistry section.

Extending a section

Let's say that Paula Thompson hires two writers for the Dental school. Those writers can be assigned to the Dentistry section as well, so that Paula can edit their content. We can even use Drupal's tools to extend the Dentistry section as follows:

• Dentistry
  • Courses
  • Faculty
  • Policies
    • Regulatory compliance
    • University regulations

Suppose, then, that one of our new hires is Pete Peterson, an expert in regulatory compliance. Pete can be assigned to work on just that section of the site.

Ignoring Sections

By default, all elements of a hierarchy are set as editorial sections. But it may be that your organization does not need the full complexity. Perhaps your hierarchy can stop at the Students level.

For this case, Workbench Access allows you to disable select terms within the hierarchy, so that not all options need to be considered when assigning editorial access.

A simplified editorial structure for our University might look like so:

• The University
  • Colleges
    • College of Arts and Sciences
      • Art
      • Biology
      • Physics
    • School of Medicine
  • Staff
  • Students
    • Alumni

In this case, the 'Prospective Students' section would simply fall under the 'Students' area. We retain Alumni as a special case, since that section has distinct editorial needs.

This 'partial hierarchy' system is very useful when you use the hierarchy for one purpose -- like site navigation or information architecture -- but don't need the same complexity for editorial access.

But don't panic. You don't have to use this feature if you don't need it.

See section Automated section assignment of the configuration for information about enabling this option.