Granular (content) permissions in workflows with wf_field_access_override
The screencast below gives an introduction to the wf_field_access_override.module. wf_field_access_override (part of the wf_field.module) allows you to override (global) permissions settings (e.g. "Edit own {nodetype}" etc.) on a per-workflow-state basis.
Whilst wf_field comes with finely-grained permissions for workflow transitions, this module is required for adding similarly granular content permissions which is very important in workflowed environment. An easy example: disallow (unprivileged) contributors editing (own) nodes once they've been published (covered in screencast :).
Improved permissions in workflows w/ wf_field_access_override (wf_field) from flink on Vimeo.
The screencast gives you a brief introduction, then illustrates where and how the default Drupal permissions fall short in a system w/ workflows; we then proceed to use two examples how wf_field_access_override can be configured to provide for more appropriate content permissions in the workflow.
Caveat: This module does not integrate into the node grants system (queries, views etc.) and there are a lot of workflow setups where this approach will fall short. Architecturally I'd prefer a solution based on rules, acl and content_access and that approach (once it is completed for Drupal 7) should and probably will supersede this module (being more flexible in many use-cases).
The easiest way to reproduce this is to use the latest version of the wf_field_test-profile:
- Download the latest Drupal 7 ($ drush dl drupal-7.4)
- Install the latest complete wf_field_test-profile in the profiles/ subfolder
- Install the profile (Webinstaller chose as profile "wf_field_test" or $ drush si wf_field_test --db-url="mysql://USER:PASS@localhost/SAMPLEDB")
- Enable the wf_field_access_override module ($ drush en -y wf_field_access_override)
- Configure what overrides you need: http:/localhost/drupal-7.4/admin/config/workflow/wf_field_access_override
- Then switch to the permissions page and grant the permissions to the respective DENY or OVERRIDE to the appropriate roles

Recent comments