A large government website (or any large website, for that matter) must allow individual departments to generate and publish their own content. Moreover, many organizations require an explicit content creation workflow, where certain employees can only author draft content, while higher ranking individuals can promote drafts to a published stage. Oftentimes it is also necessary to schedule the publication time of content for a later date.
Drupal's user roles, coupled with the Workflow module, allow for fine grained control over who can publish what and when. The following manual pages detail and explain the necessary setup.
In this manual we will designate the department in question with a generic placeholder Dept, and you will substitute in any appropriate department name. Everything you create for this department will use the same identifier to make it easy to keep related items together. Once your site spans a dozen departments or more, you will be glad that you stuck with a rigid naming convention.
Note: In this manual we will designate the department in question with a generic placeholder "Dept", and you will substitute in any appropriate department name. Everything you create for this department will use the same identifier to make it easy to keep related items together. Once your site spans a dozen departments or more, you will be glad that you stuck with a rigid naming convention.
To create a complete and autonomous workflow for a given department, we need several pieces:
We will create a simple setup with two user roles: Dept Author and Dept Manager. The former can create content drafts for Dept, while the latter can promote drafts to the published state, as well as create content from scratch. Also, Dept Managers can push published content back to draft status, i.e. make it invisible to regular site visitors.
Log in as a site administrator, navigate to /admin/user/roles and create the new roles, Dept Author and Dept Manager.
Next, navigate to /admin/content/types/add and add as many content types as are needed for the department. As a good starting point, we suggest two types, Dept Page and Dept Story, patterned after the default Page and Story content types. Pages consist of title and body text and are optimal for content which rarely changes. Stories additionally display a post date and author name, and are a good choice for timely information and blog-type entries on the website. Be sure to add a good description of the content type so that minimally trained users can choose the appropriate type for any given content they need to add to the site.
We recommend that you force new revisions for each content edit by checking Create new revision in the Workflow settings section. In addition to the explicit workflow we will add below, this will help you keep control over your content as it undergoes multiple updates over time.
Note: You may want to add custom fields to the content types, depending on the needs of the department. The details of how to do this is explained elsewhere in this manual. The relevant administration page can be reached via the Manage Fields link for the content type in question on /admin/content/types.
Finally, visit /admin/build/themes/settings/global and decide which of your new content types need post information displayed.
Even though the workflow module overrides most of the permissions in the node module section at /admin/user/permissions, we still need to make a few adjustments: If you are enforcing revisions you need to grant revert revisions and view revisions rights to Dept Manager. Further down and more important, grant access workflow summary views and schedule workflow transitions rights to Dept Manager.
We want automatic email notification of Dept Managers when a new document is ready for review. Visit /admin/settings/actions/manage and make a new advanced action available: Send email to users in specified role. Click the create button. On the next page edit the description to read Notify Dept Managers, select the appropriate recipient role, set notifications for selected node types only and select the Dept node (content) types. Add a tile, such as "%title is ready for review at %node_url" and a body such as "A new Dept page, %title, has been submitted for review. You may see the page at %node_url or in your Workflow Summary page." Then save.
We also need an action when a manager rejects the document in its current form: Create a new advanced action "Send email ...". Set the description to "Bug author to rewrite page", recipient is %author, subject "%title needs more work", message is "A manager is requesting that you make changes to your page, %title. Please check your workspace or %node_url and follow the recommendations in the workflow log."
We want some feedback when an author promotes a document from Draft to Review status: Create an advanced action "Display a message to the user". Description is "Placate author", message is "Your page %title has been submitted for review".
Likewise, we want feedback to the manager when a document is published: Create an advanced action "Display a message to the user". Description is "Feedback to manager", message is "%title has been published and is now visible for all site visitors at %node_url".
All these actions will be triggered by certain events. Navigate to admin/build/trigger/workflow. For When dept_page moves from Dept workflow: Draft to Dept workflow: Review choose the "Notify Dept Managers" action. For When dept_page moves from Dept workflow: Review to Dept workflow: Draft choose the "Bug author to rewrite page" action. For When dept_page moves from Dept workflow: Review to Dept workflow: Published choose the "Publish node" action. You'll notice that Drupal also adds a save action on its own to record the pubslishing status in the database. We also want to add the "Feedback to manager" action here. Finally, for When dept_page moves from Dept workflow: Published to Dept workflow: Draft choose the "Bug author to rewrite page" action, plus the "Unpublish node" action. Again, Drupall wil automatically add a save action.
With all action and triggers in place, we can now construct the workflow itself.
Note: It always helps to carefully read the explanations on the relevant administration pages, regardless of how well this manual might be written. This is especially true for the workflow setup.
With all other infrastructure in place, we can now implement the workflow itself:
Go to /admin/build/workflow/add and name the new workflow Dept Workflow and add it to the system. Drupal will bring you to the main workflow administration page /admin/build/workflow. Locate your new workflow and click the Add State link next to it. Add a state Draft and save. Similarly, add a second stage Review, and a third stage Published. Next, scroll down and find the Dept content types. Choose your Dept workflow from the menu next to it and be sure the Post box is checked. This assigns the workflow to the appropriate content types. Save the workflow mapping by clicking on the button on the bottom of the page.
Finally, scroll back up and click the Edit link next to your workflow.
On the next page is where most of the important configuration will happen. At the top you are looking at a table or matrix of possible state transitions and who is allowed to make these transitions. In each field, check the roles you want to grant this right to. For the field (creation) to Draft you want to check author, Dept Author, Dept Manager and any other roles you may have for general site administration and who need to have this right. For Draft to Published be sure that only Dept Manager and site administrators are checked. Likewise for (creation) to Published and Published to Draft.
Down in the Workflow Tab Permission section, Dept Manager and site administrators need checking.
Near the bottom in the Access Control section your settings should mirror what you entered into the state transition table. Be sure to uncheck visibility of Draft states for anonymous and authenticated users. Drafts must remain invisible to anyone but a chosen few people. Note that if you add visibility permission for Published states for anonymous and authenticated users you need not check any other boxes since everyone is automatically in either category, regardless of what other roles they may be assigned to. Save the setup.
(a walk through Greg's custom module)
Any user who has Dept Author rights can create a new page by going to /node/add and selecting an appropriate content type. Only content types to which this role has authoring permissions will be presented. Typically, someone in the department will have decided that new web content is needed and will call on a person who has authoring rights to get this done.
The author writes and saves the page, at which time the page goes into the Draft state. Since we configured an action to send email to Dept Manager when a document moves into the Draft state, the appropriate people will now receive notification that a Draft is ready for review and promotion.
Upon receipt of the draft notification, a Dept Manager can now go to workflow and review content. Note that Manager roles have a helpful Workflow Summary link in the navigation menu in the sidebar, and that the email also contained this link. In the workflow summary it helps to choose Dept content in Draft state to filter out other, distracting content. Click on the page title link to view the page. If the content is satisfactory click the Workflow tab. Change the state to Published, choose whether to go live immediately or at a later date and time, add an optional comment, and submit the change.
If you chose to publish the page at a later date, the content will go live during the next cron run after the specified date. Therefore, be sure you have your cron jobs under control.
If a Dept Manager creates content there will be a
For any departmental content a Dept Manager can click on the Workflow tab and change the state from Published back to Draft. You probably want to edit this content right away or assign the editing job to a Dept Author. There are no built in notifications for this workflow, so it is up to you to make sure that work is handed off properly. Alternatively, you can configure more actions and assign them to the appropriate workflow state changes.