Releases for Workflow

Prevent users with 'administer workflow' permission from using workflow and state names containing XSS.

Because these changes fix bugs in the installation sequence, 6.x-1.1 is released soon after 6.x-1.0.

Changes since DRUPAL-6--1-0:

• #353798 by smoothstr: add missing table name brackets
• #353860 by NickSI, lusid: remove unneeded default value declaration from schema

Changes since DRUPAL-6--1-0-RC3:

• #310439 by awmckinley: fine-tune menu_alter() and rebuild menu when type is mapped.
• #327405: add settings to control whether the workflow comment log field is displayed on node edit or workflow tab forms.
• #326688 by deekayen: remove notices

Changes since DRUPAL-6--1-0-BETA2:

The big change is that now, when the Views module is enabled, the workflow module will provide two default views. One shows an overview of the states and nodes are in (filterable by state and by node type) and the other provides a view of pending state changes for nodes that have state changes scheduled using the "scheduled state change" option on the workflow tab.

• #290095 by rastatt: updated German translation
• #290263 by Eaton: Views 2 integration for workflow states
• #288650 split page callbacks from workflow.module into workflow.admin.inc and workflow.pages.inc
• add a default Workflow Summary view showing nodes and states for those with 'access workflow summary view' permission
• patch by Eaton: add default view for pending state changes
• combine summary view permissions and simplify view paths

This is pretty much a straight port from workflow 5.x-2.3.

One difference is that for convenience, workflow now has the functionality of the triggerunlock module built in, so people don't keep asking "where are all the actions".

Please test and report issues in the issue queue.

• updated README
• added a preference to display the workflow form on either the node editing form (which we've always had) or when adding a comment to a node
• refactored nodeapi implementation into workflow_transition() so we can reuse code from either the nodeapi or comment hook
• uninstall now deletes the two actions provided by workflow.module (workflow_select_given_state_action and workflow_select_next_state_action) from actions table if actions is enabled
• only show node type/workflow assignment if a workflow has been defined
• #236908 ignore hook_hook_info() if no workflows are defined
• #250480 enable workflow hook support for any op for workflow actions
• #250244 by v1nce: enable editing of state name by including status field
• Display message when user displays trigger page but no transitions havebeen allowed
• #250391 query should not return transition if no valid target state

This release brings compatibility with actions 5.x-2.x (the backport of Drupal-6-style actions).

It also moves actions assignment from the workflow module administrative interface to the triggers interface.

This is a "point-zero" release; please report bugs in the issue queue.

Changes since workflow 5.x-1.2:

• #247568 by snoble: remove primary key from Postgres workflow_access table
• #247617 by snoble: add stamp field to workflow_node table for Postgres
• added status field to workflow_states table so deleted states are not deleted; they are just flagged as deleted. This preserves workflow node history even if a state the node has been in is deleted.
• workflow tab page now themes current, regular and deleted states differently
• #128874 approach by JacobSingh: reassign soon-to-be-orphaned nodes to a different state when a state is deleted
• added autoincrement field hid to workflow_node_history table
• added force parameter to workflow_execute_transition(); disregards permissions when true
• added advanced action: Change workflow state of post to new state
• convert Change workflow state of post to next state action to D6 style
• remove code related to actions assignment; actions module provides this

Small fix to actually fix the small fix in the last release :)
Just fixes an XSS vulnerability in 4.7.x-1.1, see SA-2008-009 for details.

Infinite thanks to Gabor Hojtsy: Workflow Access has been upgrade to 5.x and is now a part of the workflow package!

Many thanks also to Earl Miles for the original workflow_access.module.

From the README:

WORKFLOW ACCESS

The workflow package contains an additional module, workflow access. This
module allows workflow administrators to set which roles can access nodes
based on their state. You can also set edit and delete permissions by state.

To use workflow access, visit admin -> build -> modules and enable the
"Workflow access" module. The visit admin -> build -> workflows and select the
workflow on which you would like to enable access control.

Each state has it's own set of permissions, where you can edit which roles
may view, edit or delete a given node. By default, both anonymous and authenticated
users may view. No roles have edit permissions. Make the security changes for your
site and click "Submit." Workflow Access will automatically reset the permissions
on any nodes in that workflow.

You may use Workflow Access with other node access systems (such as Organic Groups).
Be aware, however, that Drupal uses an explicit allow system, so if a user has
access through Organic Groups, he/she will be able to view a node, even if the workflow
permissions would not otherwise allow it.