Item9088: WORKFLOWLASTVERSION_State returns wrong rev number

pencil
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: WorkflowPlugin
Branches:
Reported By: JohannesHammersen
Waiting For: Main.GilmarSantosJr
Last Change By: GilmarSantosJr
When a Topic is transitiond into a new state a new revision is created. But the old revision number is stored in LASTVERSION_state.

The plugin records the version that it was "last in a state" when the topic is store in that state. However it does it at a time before the new revision number has been allocated, so it records the revision before the change to the new state

A possible solution would be to re-save the topic (storing the correct rev-number) after the state has changed without creating a new revision. (repRev?)

-- JohannesHammersen - 01 Jun 2010

It seems to pick up the revision number before the status change is executed.

I'm sure it's not a proper solution but I hacked ControlledTopic.pm:
--- ControlledTopic.pm.orig     2011-03-01 08:25:44.000000000 +0100
+++ ControlledTopic.pm  2011-08-30 17:01:48.000000000 +0200
@@ -67,7 +67,7 @@
 sub setState {
     my ( $this, $state, $version ) = @_;
     $this->{state}->{name} = $state;
-    $this->{state}->{"LASTVERSION_$state"} = $version;
+    $this->{state}->{"LASTVERSION_$state"} = $version + 1;
     $this->{state}->{"LASTTIME_$state"} =
       Foswiki::Func::formatTime( time(), undef, 'servertime' );
     $this->{meta}->put( "WORKFLOW", $this->{state} );

It now saves the correct revision information in the meta data.

-- MartinKaufmann - 30 Aug 2011

This problem is bigger than +1. Assume the following history:

  1. Topic FooTopic is created with no content (r1)
  2. FooTopic is attached to a workflow (seting a preference in "More topic actions") (r2, STATUS_0)
  3. FooTopic is edited by user A (r3, STATUS_0)
  4. FooTopic is edited by user B (r4, STATUS_0)
  5. user B performs a state transition (r5, STATUS_1)
  6. user C performs another state transition (r6, STATUS_2)

At r6, the correct values should be:
%WORKFLOWLASTREV_STATUS_0% r4
%WORKFLOWLASTREV_STATUS_1% r5
%WORKFLOWLASTREV_STATUS_2% r6

But the values reported are:
%WORKFLOWLASTREV_STATUS_0% empty
%WORKFLOWLASTREV_STATUS_1% r4
%WORKFLOWLASTREV_STATUS_2% r5

When a topic has many versions without state transition, the LASTREV is not updated and the state transition stores the wrong value.

Maybe a way to go is define afterSaveHandler and save the topic again with the updated version number. At beforeSaveHandler it's not easily possible to know the version number the topic will get (it should be current+1, but it may be current, if the save is performed by the same user and Force new revision was not checked and the save occurs before the configured repRev time).

The afterSaveHandler probably will run fast enough to minimize the chance of undesired side effects.

-- GilmarSantosJr - 08 Dec 2011

The %WORKFLOWHISTORY% also show wrong revision numbers. Because of bug described in Item8002, it's not possible to easily fix existing topics, but once that task is solved, I can finish this one properly.

-- GilmarSantosJr - 08 Dec 2011

Fixed in version 13398 (2011-12-12), release 1.12.2.

-- GilmarSantosJr - 12 Dec 2011
 

ItemTemplate edit

Summary WORKFLOWLASTVERSION_State returns wrong rev number
ReportedBy JohannesHammersen
Codebase 1.0.9
SVN Range
AppliesTo Extension
Component WorkflowPlugin
Priority Normal
CurrentState Closed
WaitingFor GilmarSantosJr
Checkins WorkflowPlugin:478e42d8e062
TargetRelease n/a
ReleasedIn n/a
trunkCheckins WorkflowPlugin:478e42d8e062
Release01x01Checkins
Topic revision: r6 - 12 Dec 2011, GilmarSantosJr
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy