Integration with Revisioning module: Workflow for new revisions of published nodes

Thanks for your reply, and my apologies for taking a while to respond. Unfortunately, I've been able to recreate the problem in version 2.5, but I'm using Workflow Field. I'll try using Workflow Node to see if that plays better with revisions and report back.

I changed my configuration to use Workflow Node instead of Workflow Field but I didn't get very far unfortunately. After saving a node of a content type with an associated workflow, I got a nasty EntityMetadataWrapperException, which pretty much ended my exploration of that option!

I've updated the module to version 2.5, but the problem I described in my original post is still occurring. I'm keen to find a solution to this, as Workflow combined with Revisioning and Rules has the potential to produce a great content authoring experience. I've done a bit more digging, and I've identified something that might be related to the cause of the problem. If I describe my findings, hopefully someone who knows the module a little better than me will be able to suggest a solution.

I decided to start by looking at the widget provided by Workflow Field first. I assumed that the problem is being caused by incorrect entity information (i.e. not using the correct/latest revision for state transitions), so I added a watchdog call to dump out the contents of $entity in the constructor of the WorkflowD7Base class at various points during the workflow. I've included a summary of the contents of $entity at the various stages below:

1. (creation) -> 'For review' (Skipped the 'In draft' state to get to the problem faster!)

stdClass Object
(
    [nid] => 1
    [vid] => 1

    [revision] => 1
    [revision_moderation] => 1

    [is_new] => 1

    [status] => 0
    [current_status] => 0

    [timestamp] => 1421401510
    [created] => 1421401510
    [changed] => 1421401510
    
    ...

    [field_workflow] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [value] => 3    // 'For review'
                        )

                )

        )
)

2. 'For review' -> 'Live'

stdClass Object
(
    [nid] => 1
    [vid] => 2
    [old_vid] => 1

    [revision] => 1
    [revision_moderation] => 1
    [revision_timestamp] => 1421401510
    [num_revisions] => 1
    [current_revision_id] => 1

    [is_new] => 
    [is_current] => 1
    [is_pending] => 1

    [status] => 0
    [current_status] => 0

    [timestamp] => 1421401601
    [created] => 1421401510
    [changed] => 1421401601
    
    ...

    [field_workflow] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [value] => 4    // 'Live'
                        )

                )

        )

    ...

    [original] => stdClass Object
        (
            [nid] => 1
            [vid] => 1

            [revision_moderation] => 1
            [revision_timestamp] => 1421401510
            [num_revisions] => 1
            [current_revision_id] => 1

            [is_current] => 1
            [is_pending] => 1
            
            [status] => 0
            
            [created] => 1421401510
            [changed] => 1421401510

            ...

            [field_workflow] => Array
                (
                    [und] => Array
                        (
                            [0] => Array
                                (
                                    [value] => 3    // 'For review'
                                )

                        )

                )
        )
)

3. 'Live' -> 'In draft'

stdClass Object
(
    [nid] => 1
    [vid] => 3
    [old_vid] => 2
    
    [revision] => 1
    [revision_moderation] => 1
    [revision_timestamp] => 1421401601
    [num_revisions] => 2
    [current_revision_id] => 1

    [is_new] => 
    [is_current] => 
    [is_pending] => 1
    
    [status] => 0
    [current_status] => 0
    
    [timestamp] => 1421401849
    [created] => 1421401510
    [changed] => 1421401849

    ...

    [field_workflow] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [value] => 2    // 'In draft'
                        )

                )

        )

    ...

    [original] => stdClass Object
        (
            [nid] => 1
            [vid] => 1    // Should be 2!

            [revision_moderation] => 1
            [revision_timestamp] => 1421401510
            [num_revisions] => 2
            [current_revision_id] => 1

            [is_current] => 1
            [is_pending] => 

            [status] => 0

            [created] => 1421401510
            [changed] => 1421401601
            
            ...

            [field_workflow] => Array
                (
                    [und] => Array
                        (
                            [0] => Array
                                (
                                    [value] => 3    // 'For review'
                                )

                        )

                )
        )
)

At this point, the error occurs. From what I can see, the contents of [original] in step 3 is incorrect. [old_vid] refers to the correct revision (vid = 2), but the previous revision is included in [original] - vid = 1. The value of [field_workflow] is therefore 'for review' rather than 'live', and attempting to transition from 'for review' to 'in draft' is not permitted and results in the error.

(NB: The configuration of transition states have changed from my original post, and rules were disabled for this test so the node never actually gets published, which is why [status] => 0.)

Any thoughts? Thanks for your help!

Postponed while I investigate if the Revisioning module is having any effect on the contents of [original].

I've discovered that the source of the problem I've been experiencing is within the workflow_node_previous_state function in workflow.module. It isn't a bug, as without the Revisioning module in the mix, the functionality provided by the Workflow module works as expected.

Due to the way the Revisioning module manages revisions, there is no guarantee that the contents of $entity->original is the latest revision. Depending on how revisioning is configured, and based on the testing I've done, $entity->original appears to contain the current revision, i.e. the revision that is currently published. This means that using $entity->original to retrieve the previous workflow state will cause the error I described above when using the Revisioning module.

In order to get things working (and in an attempt to get back on track with my sprint!), I've implemented a hacky fix which simply provides an alter hook before $sid is returned (approx. line 1015):

// Allow other modules alter $sid.
$context = array(
  'entity' => clone $entity,
  'entity_type' => $entity_type,
  'field_name' => $field_name,
);
drupal_alter('workflow_node_previous_state', $sid, $context);

I've implemented the hook in a custom module, which will then check for the latest revision, and change the value of $sid. Not very pretty to say the least, but it'll let me get on with what I need to do for the time being!

Unfortunately, I don't know the module well enough to answer this question: could there be a more elegant solution for this issue?

Thanks!

Thanks for your reply. I'm not sure if that behaviour is necessarily a bug in the Revisioning module. I think the value of $entity->original varies depending on exactly how revisions are configured - I'll need to do more exploring to confirm that and possibly post a question in the issue queue for the Revisioning module, so I'll postpone this issue again for the time being.

Would using entries stored in the workflow_node_history table be feasible for rewriting workflow_node_previous_state()? I assume an entry is written to the table after a state transition is successfully completed, and as the nid and revision_id is stored, it looks as though all the information needed to determine the previous state is available in that table. If that's the case, I'm happy to have a go at making a patch.