This is a port of the README file within the Workbench Module. It may need to be adapted to fit the Handbook style.
Workbench Access is designed to be a pluggable access control system. New access control systems should be possible by following the documentation in workbench_access.api.php, distributed with the module.
Currently, new plugins must be loaded from the /modules folder inside the workbench_access directory. Fixing that is on the Feature roadmap.
Note also that we do not use Field API for data storage. This decision is deliberate for three reasons:
- Section data for nodes is 'stateless'. That is, it is permanent data that is independent of node revisions.
- Doing the necessary queries and joins to custom table data is easier than using the Field API, and likely faster.
- To properly integrate with Views, we need direct control over the table structures of our data.
However, we may consider moving to Field storage in later versions.
Workbench Access creates four tables in your Drupal installation.
Stores data for the active access schemes on the site.
Stores the section assignments for each node.
Stores the section assignments for each role.
Stores the section assignments for each user.
See workbench_access_scheme() in workbench_access.install for table definitions.
Workbench Access provides Views integration in three distinct ways.
- It provides the necessary fields, sort handlers, and filters for using node section assignments with Views.
- It provides a definition for menu_links table data if one is not present. This integration is very lightweight and only useful for sorting and filtering content when menu module controls the access scheme.
- When using the full Workbench suite, it adds a Sections filter and field to any View defined by Workbench modules. (These are identified by a 'Workbench' Views tag.)
Note that the Views integration has to alter how Views joins to taxonomy tables when taxonomy-based sections are used.