Item8002: WORKFLOWHISTORY is stored as an preformatted string

The plugin stores the WORKFLOWHISTORY as a string pre-formatted by the WORKFLOWHISTORYFORMAT live at the time the state transition was executed. This has two impacts:

1. A nasty TML string is packed into a form field value, making it hard to search
2. If the format changes, it doesn't apply to old entries. So once you have decided the format, you can't change it after the first transition.

It would be much better if the WORKFLOWHISTORY stored the data and only expanded it when required.

Unfortunately there is a compatibility issue here, as existing workflows will have histories recorded using the "old style". This could be addressed by storing the data with a "string" first entry which can store the "old" history.

-- CrawfordCurrie - 12 Nov 2008

Dropping to Enhancement status, as no-one seems too bothered.

-- CrawfordCurrie - 20 May 2010

Now I'm bothered

I'm currently working on Item9088 and I need this solved in order to complete that task properly.

The WORKFLOWHISTORY has the value as preformatted string. I propose to add a data field to store transition information (I'm not quite sure yet about the format, but from key:value to Json should work). The tag handler should render the value (for compatibility) and then data field, expanding it according to the current value of WORKFLOWHISTORYFORMAT.

Foswiki::Plugins::WorkflowPlugin::ControlledTopic::changeState should also be modified to not fill WORKFLOWHISTORY:value anymore and populate data field instead.

If there's no objection with this approach, I'm going to implement it.

-- GilmarSantosJr - 08 Dec 2011

Sounds good to me so far but... what will the data field look like? A CSV list? Would it be easier to use the "list" style of meta-data (c.f. META:FILEATTACMENT, META:FIELD), with each entry keyed by date?

-- CrawfordCurrie - 09 Dec 2011

Well, I was thinking about problem #2 only, about format changes. But the "list" idea is great! What about something like:

%META:WORKFLOWHISTORY{name="$rev|$state" author="$wikiusername" date="$date"}%

%META:WORKFLOWHISTORY{name="4|REVISION" author="WikiUserName" date="1323422573"}%
%META:WORKFLOWHISTORY{name="5|PENDING" author="WikiUserName" date="1323422624"}%
%META:WORKFLOWHISTORY{name="6|REVISION" author="WikiUserName" date="1323429172"}%
%META:WORKFLOWHISTORY{name="9|PENDING" author="WikiUserName" date="1323429264"}%
%META:WORKFLOWHISTORY{name="10|APPROVED" author="WikiUserName" date="1323430123"}%

It would solve both problems. The key in this way $rev|$state maybe will make searches easier than date and since | is not valid neither in $rev nor $state, I think we won't have problems. And the legacy %META:WORKFLOWHISTORY{value="$string"}% should be rendered first, if it exists.

Is this OK?

-- GilmarSantosJr - 09 Dec 2011

It's a bit lumpy, crushing together the revision and the state. Consider a QUERY for a specific revision:

%SEARCH{type="query" "META:WORKFLOWHISTORY.name=~'3.*'}%

Because the state and the rev are crushed together, you have to use a regex search, which we know is pretty inefficient in DB queries. If you split the rev and the state, it would make such queries cleaner.

%SEARCH{type="query" "META:WORKFLOWHISTORY.name='3'}% %SEARCH{type="query" "META:WORKFLOWHISTORY.state='APPROVED'}%

%META:WORKFLOWHISTORY{name="4" state="REVISION" author="WikiUserName" date="1323422573"}%
%META:WORKFLOWHISTORY{name="5" state="PENDING" author="WikiUserName" date="1323422624"}%
%META:WORKFLOWHISTORY{name="6" state="REVISION" author="WikiUserName" date="1323429172"}%
%META:WORKFLOWHISTORY{name="9" state="PENDING" author="WikiUserName" date="1323429264"}%
%META:WORKFLOWHISTORY{name="10" state="APPROVED" author="WikiUserName" date="1323430123"}%

Since the $rev (the name field) will always be unique, I think this works.

-- CrawfordCurrie - 09 Dec 2011

You're right. Also, using the format I proposed it's dificult to handle forks. Maybe something like:

%META:WORKFLOWHISTORY{name="4" state="REVISION" author="WikiUserName" date="1323422573"}%
%META:WORKFLOWHISTORY{name="5" state="PENDING" author="WikiUserName" date="1323422624"}%
%META:WORKFLOWHISTORY{name="6" state="REVISION" author="WikiUserName" date="1323429172"}%
%META:WORKFLOWHISTORY{name="7" forkto="Web.Topic1, Web.Topic2" author="WikiUserName" date="1323429200"}%
%META:WORKFLOWHISTORY{name="9" state="PENDING" author="WikiUserName" date="1323429264"}%
%META:WORKFLOWHISTORY{name="10" state="APPROVED" author="WikiUserName" date="1323430123"}%

And in child topics:

%META:WORKFLOWHISTORY{name="1" forkfrom="Web.Parent" author="WikiUserName" date="1323429200"}%

-- GilmarSantosJr - 09 Dec 2011

y, forkto and forkfrom make sense. But don't you have to record the rev that was forked? Or are you relying on being able to find that from the forkto in the forked topic? In that case, what happens if you fork to the same topic twice?

-- CrawfordCurrie - 10 Dec 2011

Actually the current version doesn't log this information, but it makes sense in the case of forkfrom (forkto always will be rev 1).

Probably we also need WORKFLOWHISTORYFORKTOFORMAT and WORKFLOWHISTORYFORKFROMFORMAT besides the existing WORKFLOWHISTORYFORMAT (and maybe make WORKFLOWHISTORY accept a parameter to not show forkto/forkfrom).

I think it's not possible to fork to the same topic more than once. If the topic exists WORKFLOWFORK renders to an error complaining about that...

I'll add a rev to forkfrom entry and let the other things to be done in a future release.

-- GilmarSantosJr - 12 Dec 2011

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

-- GilmarSantosJr - 12 Dec 2011

Commenting is disabled while not logged in