Item9088: WORKFLOWLASTVERSION_State returns wrong rev number
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
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:
- Topic FooTopic is created with no content (r1)
- FooTopic is attached to a workflow (seting a preference in "More topic actions") (r2, STATUS_0)
- FooTopic is edited by user A (r3, STATUS_0)
- FooTopic is edited by user B (r4, STATUS_0)
- user B performs a state transition (r5, STATUS_1)
- 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