create new tag
, view all tags

WorkflowPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on WorkflowPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on WorkflowPlugin

-- ThomasHartkens - 16 Feb 2005

Feature Requests

Suggestion Proposed Status
Generate table to show which topics are in which state AndyBush Available via MakeCtrlTopicsListAddOn
Fix retrieval of revisions EdMcDonagh Implemented
Fix documentation of %APPROVALSTATEMESSAGE%   Implemented
%APPROVALLASTTIME_APPROVED% gives date that is a month out EdMcDonagh Implemented
Store WikiName of user changing state SteveKostecke See LastWho.diff
Publish approved topics. System displays list of all approved topics that have not yet been published. User selects those to publish. System copies the topics to another web (where security prevents users from modifying them), or publish them using PublishContrib. (March 2007) DenisBallant  
Display last approved version to general audience
The requirements are murky: Do you show the last approved version to all, or to just those who cannot edit? Should we show the last approved version, with a link to the current version undergoing revision? Etc. -- TW
Item superceeded by previous one -- DenisBallant
I clarified a little down below, but to summarize, I was orginally looking at only showing the last approved version to those who cannot edit. Otherwise, its nice to know that a version is approved, but a user can see a 'non' approved version, so it seems to be a rubber stamp process, rather than a mechanism to show the world the approved version while drafting the next version. --Main.EricHanson
Integrate change of attached form based on state as in WorkFlowAddOn as option ThomasWeigert Implemented
Support display of complete action history as in WorkFlowAddOn as option ThomasWeigert Implemented
Allow free ordering of states. Indicate initial state, e.g., by blank state name ThomasWeigert  
An approval system is that an unauthorized member should not see the unapproved topic until it is approved. Support setting that would prevent viewing of document by unauthorized users in certain states. SteveStark  
Add a variable %WORKFLOWSTATE{}% with topic and web parameters, to allow the state be displayed as part of a SEARCH result JohnFitzpatrick Implemented
Allow a topic to require approval by multiple distinct people before it can move on to the next state. SteveTraylen Patch available by AndrewRJones, see below
Allow the state machine to affect the value of arbitrary variables in addition to the form. ThomasWeigert Work in progress.


Thomas, thank you for contributing this Plugin! It is very much in line with the TWikiMission.

Small feedback:

-- PeterThoeny - 20 Feb 2005

Feedback re: plugin on Cygwin and XP

There is a note that to use this plugin Twiki needs to know who you are. As I'm running Apache on Cygwin I've used pass through domain authentication just to view the site (i.e. no login as such but Apache "knows" that you are an authorised domain user, see TWiki:Codev.WindowsInstallModNTLM for details) and login to edit. Passthrough authentication is enough that the plugin works without using the custom .htaccess file (now if only I can get %ACCESSTRANSITION% to show a button I'll be laughing;-) )

-- SteveMayes - 03 Mar 2005

This looks great and I am hoping to use this to ensure quality information is maintained.

One question. Is there a way of generating a table to show which topics are in which state etc

-- AndyBush - 31 Mar 2005

Should the plugin fail to show up under "activated plugins", your TWiki core may be too old. For example, the 01-Feb-2003 production release is too old.

-- DetlefMarxsen - 13 Apr 2005

The content of the variable APPROVALLASTVERSION_APPROVED is not correct: The appendix (e. g. ?rev=1.3) is missing. Can this be fixed? Thanks!

-- DetlefMarxsen - 09 Jun 2005

There is a new AddOn which does what AndyBush wants. See MakeCtrlTopicsListAddOn

-- DetlefMarxsen - 10 Jun 2005

added .zip to CVS

-- WillNorris - 27 Jun 2005

Quick fix for the problem with APPROVALLASTVERSION_APPROVED is to edit lib/TWiki/Plugins/ApprovalPlugin.pm and find the following section:

        # show last version tags
     foreach my $key (keys %{$globCurrentState}) {
         if ($key =~ /^LASTVERSION_/) {
        my $url = TWiki::Func::getScriptUrl( $web,$topic,"view" );
        my $foo = "<a href='$url'?rev=".$globCurrentState->{$key}.">revision ".
        $_[0] =~ s!%APPROVAL$key%!$foo!g;

and edit the line:

my $foo = "<a href='$url'?rev=".$globCurrentState->{$key}.">revision ". 

to be:

my $foo = "<a href=$url?rev=".$globCurrentState->{$key}.">revision ".

i.e. remove the single quotes either side of the $url variable.

If this is the correct way to do it, can this be changed in the original?

-- EdMcDonagh - 02 Aug 2005

The following statement in ApprovalPlugin is incorrect:

Additionally, you can place the tag %APPROVALMESSAGE% in your document which will be replaced by the corresponding message in the state table.

The tag you need is actually %nop>APPROVALSTATEMESSAGE%

-- EdMcDonagh - 02 Aug 2005

This plugin is an absolute dream now I have it working right!

Another small problem though, %APPROVALLASTTIME_APPROVED% gives me a date that is a month out, i.e. when it should say 08 it has 07 instead.

I have fixed it for now with a crude change to ApprovalPlugin.pm sub Timestamp by changing $mon to 1+$mon.

Anyone have any better ideas?

-- EdMcDonagh - 25 Aug 2005

I've modified ApprovalPlugin to store/display the WikiName of the user changing the state. Please see LastWho.diff in the attachments table.

-- SteveKostecke - 31 Aug 2005

I have a small problem that I cannot work out how to solve. The access control is working correctly however, the APPROVALTRANSITION variable is not replaced with a button. Any help would be much appreciated.

Also, what is the best way of allowing anyone to change a document from one state to another?

-- ChrisSBrown - 14 Sep 2005

HAve you looked at the link to existing questions at the top of this page? I had a similar problem where the button did not appear, although the send for approval link did: ApprovalPluginStateDoesntChange The solution to my problem was that I had made a spelling mistake in the workflow tables.

-- EdMcDonagh - 16 Sep 2005

Thank you for the suggestion. I had already looked on the support forum, but had not found the link to existing questions. I've checked and rechecked my spelling and it's correct. I must have got something wrong with the configuration as other people seem to be running this ok. I'll keep investigating.

-- ChrisSBrown - 19 Sep 2005

It would be really nice to have multiple independent concurrent approvers so that each could approve independent of order, but the final state wouldn't be reached until all had approved. Also, is there some way to automatically add rev= tags into %include sections so that changes to the referenced pages couldn't affect "approved" context. Finally, it would also be great to have some way to approve multiple topics in parallel (for instance, the case where one document includes others).

-- MarioNigrovic - 10 Oct 2005

I've done some more investigation on why I'm not getting the approval button shown. At the top of the commonTagsHandler subroutine there are the following lines of code

      if (NeedsApproval() && (my $query = TWiki::Func::getCgiQuery())) {
          my $action = $query->param( 'APPROVALACTION' );
          my $state = $query->param( 'APPROVALSTATE' );

I've put some debug trace on the variables and both action and state are unset. the result of this is that the nuber of actions is set to 0 and the if statement containing the button code is never entered.

Does anyone have any ideas as to what could be causing this? Or suggestions on other aspects I need to investigate?

-- ChrisSBrown - 19 Oct 2005

I would like to show the current "approval state" of a topic in a formatted search. For example, I have a list of topics each managed by the same workflow with the same form data. I can use to search for the form data and display it in a table, but I have yet to find a way to display the current "approval state". Any suggestions?

-- EricSorton - 20 Oct 2005

Currently $debug = 1; is hardcoded into Plugins/ApprovalPlugin.pm and it's flooding the data/debug.txt. In Plugins/ApprovalPlugin.pm replace $debug = 1; with $debug = TWiki::Func::getPreferencesFlag( "\U$pluginName\E_DEBUG" ); to make it follow the setting in ApprovalPlugin topic (copied blindly from SessionPlugin.pm)

-- PetriLievonen - 09 Dec 2005

This plugin works as advertised, however, it seems to take the document out of the twiki versioning system as the document I made approval on was updatable but the twiki revision froze at 1.4. Is this the intended behavior?

In addition, my requirements are such that I need to have the current, approved document remain available while the revision is approved. There doesn't seem to be the ability to 'branch' the revision while it is being approved. The document being updated and approved simply gets a warning notice. Is this the case?

-- DavidPrimmer - 25 Jan 2006

I can't get it work with 4.0.0.

similar problems as described in ApprovalTransitionVariableNotAppearing

BTW .htaccess uses absolute address in

insead of

  • ErrorDocument 401 {!ScriptUrlPath}/view
-- FerdinandGassauer - 04 Feb 2006

To the Plugin maintainer: If possible, please keep this Plugin compatible with Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 08 Feb 2006

In October 2005 I was trying to setup the Approval plugin - see my comments above. The reason that the approval controls were not being displayed was because I had not configured the system to require authentication for users when viewing pages. In the process of sorting this out I worked out a solution where users are not required to authenticate themselves unless they want to change the approval status. I setup a variable as follows

    * Set APPROVALNOTICE = This topic is under document control. Last approval on %APPROVALLASTTIME_APPROVED%: %APPROVALLASTVERSION_APPROVED% <br>Current Status: %APPROVALSTATEMESSAGE%&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[%SCRIPTURL%/viewauth/%WEB%/%TOPIC%][Change Status]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;%APPROVALTRANSITION%

This requires the user to click on the Change Status link which takes the user to the same topic using the viewauth acript which requires authentication and therefore shows the controls to modify the approval status.

-- ChrisSBrown - 21 Feb 2006

I was wondering if someone had found a way to display the last approved version to people who can edit the page?

-- EricHanson - 05 May 2006

AFAIK the maintainer is no longer involved. The last version it works on is Cairo.

-- MeredithLesly - 05 May 2006

I sent an e-mail to ThomasHartkens asking if he would update the Plugin.

-- PeterThoeny - 05 May 2006

Thanks Meredith, I should have stated my question more clearly smile

I actually meant, is there a way to have a non-approver see the lastest approved version instead of merely a link saying "Lastest version is", in essence hide the un-approved version?

Otherwise, it doesn't seem to really be doing anything except tagging a certain version as approved, but that has to be honored by the user (since the user can see the latest 'unapproved' version).

I am basically looking for a way to remove the onus from the user whether they are seeing the latest approved version. Any information is very welcome.

-- EricHanson - 15 May 2006

Sorry, I'll have to leave that to someone else, since I started using TWiki with Dakar. Having looked at the code some, however, I don't think so.

-- MeredithLesly - 16 May 2006

Thanks for the response. I did manage this, it was a smallish code change, basically check the meta data for the approved tag, then fetch that version of the page and proceed.

-- EricHanson - 23 Jun 2006

Eric, if you are able to upload your working plugin I'm sure it would be appreciated by others. I would be happy to take back the changes to SVN and release a new version from there.

-- SteffenPoulsen - 23 Jun 2006

When I checked the plugin, there were seven violations listed. Please verify that all of them have been fixed before releasing it to svn, etc.

-- MeredithLesly - 24 Jun 2006

Has anyone got this working on Dakar? I use it extensively on Cairo, but now I have a new server I want to start using Dakar.

-- EdMcDonagh - 07 Jul 2006

Yes, I have it working on Dakar, which I have uploaded to the plugin topic. I have integrated above change suggestions per the table of suggested enhancement at the top of this page.

However, regarding this plugin, the nomenclature is somewhat awkward. This plugin implements generic work flow features (as it was inspired by the WorkFlowAddOn). Rather than confusing users with the approval special case, I would prefer to present it in a generic manner. Than people would not be tempted to make a literal copy of this plugin as in WorkflowPlugin....

-- ThomasWeigert - 24 Jul 2006

WorkflowPlugin is marked PleaseFeelFreeToModify, so maybe you could get the name back from Meredith as soon as you integrated your work from WorkFlowAddOn, which of course does absolutely make sense.

-- FranzJosefSilli - 24 Jul 2006

That makes sense, in particular, as he just copied the plugin, globally replace "approval" with "workflow", commented out some stuff, lifted some functions out, and moved some things from commonTagsHandler to registered handlers (not actually a good idea in this case)... at least, as far as I could tell... I don't think it is actually working yet either...

-- ThomasWeigert - 24 Jul 2006

Added key features from WorkFlowAddOn, in particular, history trace and form manipulation through work flows. These are optional and backwards compatible.

-- ThomasWeigert - 25 Jul 2006

Renamed to WorkflowPlugin after consultation with Meredith.

-- ThomasWeigert - 07 Aug 2006

Thanks Thomas for porting this Plugin to TWiki 4. Some suggestions:

  • Escape the WikiWord in the heading (better not to link to oneself)
  • To avoid broken links when this Plugin is installed, use Interwiki links consistently (also for WikiNames)
  • How about measuring and documenting the PluginBenchmarks numbers?
-- PeterThoeny - 07 Aug 2006

I have updated this plugin on SVN where there was an old out of date version. This enables the community to test the plugin on pseudo-installs and actually quite many use the SVN to keep their running production TWiki's updated. These Thomas Weigert plugins are all very cool and of high quality and it would be nice if they were kept up to date on SVN

-- KennethLavrsen - 07 Aug 2006

Is there an easy way to convert all current Approval controlled documents to the new WorkFlow plugin?

-- EdMcDonagh - 09 Aug 2006

Hmmm.... I am embarassed to confess that I did not consider this when I changed the names of the tags. Options:

  1. Leave the name of the tags "APPROVALxxxxx" albeit that is a little confusing to new users
  2. Add tags "APPROVALxxxxx" in addition to the existing "WORKFLOWxxxxx" tags
  3. Provide a script that renames "APPROVALxxxxx" to "WORKFLOWxxxxx" tags, thus converting old topics.
Option (3) is easy enough to produce. Would that be sufficient?

-- ThomasWeigert - 09 Aug 2006

If you could do the script, that would be great... smile

-- EdMcDonagh - 09 Aug 2006

Added the above discussed conversion script. Please test first on a copy of your data...

-- ThomasWeigert - 11 Aug 2006

I just started using this plugin and it looks very good. One problem I found is that members of the TWikiAdminGroup are not controlled. If I set the approved state allow edit to nobody, then I expect that nobody can edit the topic in that state; however, if I am a member of the TWikiAdminGroup I am still able to edit the topic.

-- ChrisPurves - 31 Aug 2006

This is actually the spec of TWiki, like in Unix, TWikiAdminGroup members have super admin rights.

-- PeterThoeny - 31 Aug 2006

The problem is that it becomes too easy for members of the TWikiAdminGroup to make a change to a controlled topic without going through the proper approvals. It is a weakness of this plugin, but fairly minor.

-- ChrisPurves - 01 Sep 2006

On the main plugin page it says:

Furthermore, the plugin replaces any variable starting with %WORKFLOW...% defined in the workflow file. Finally, it removes all other tags in the document which start with %WORKFLOW...%. (You can use this behaviour to place these tags in the header or footer. They appear only if the currently displayed document is controlled! Otherwise, these tags are just removed and do not disturb the layout)

Could someone elaborate on how I would go about modifying the header? Ideally I would like to have the state transition button on the Edit WYSIWYG Attach Printable line.

-- ChrisPurves - 01 Sep 2006

Look into how the templates/view.pattern.tmpl is assembled from included templates (I assume you are using the PatternSkin). You might want to look at the example templates included with this plugin, which modify the bottom actions bar, you can just mirror that for the top action bar....

-- ThomasWeigert - 02 Sep 2006

On the question regarding the permissions for AdminGroup, that is just how the TWiki spec works. I recommend not to treat this plugin any different from the basic TWiki system, as this seems more confusing...

-- ThomasWeigert - 02 Sep 2006

I had played with view.pattern.tmpl and read the templates pages in the manual for a few hours before posting and asking for help. I found the template to be quite confusing with TMPL:P commands inside TMPL:DEF commands. I'll keep at it until I figure it out...

-- ChrisPurves - 05 Sep 2006

Here is what I did to put %WORKFLOWTRANSITION% into the header and footer:

  1. Edit viewtopicactionbuttons.pattern.tmpl to create template definition:
    %TMPL:DEF{"activatable_workflow"}%<span class="patternButton">%WORKFLOWTRANSITIO
  2. Edit view.pattern.tmpl and modifed topicactionbuttons definition to create workflow button in bottom bar:
    led" then="activatable_edit_wysiwyg"}%%TMPL:P{context="WysiwygPluginEnabled" the
  3. Edit viewtoolbar.pattern.tmpl and edit top bar buttons:
    "WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%<span class="patternButt
    on">%TMPL:P{"activatable_attach"}%</span><span class="patternButton">%TMPL:P{"pr
The results are not pretty, but they work:

top.png bottom.png

A problem is for documents where set WORKFLOW = ... is not present. The following happens to the header and footer:

top_no_set.png bottom_no_set.png

Hopefully someone might have some ideas as how to make this a little better.

-- ChrisPurves - 21 Sep 2006

You just need to mirror what Crawford did with the button for the WYSIWYG plugin.... If it is activated the button shows, if not, it does not show... There is an if-then-else construct in the template language....

-- ThomasWeigert - 22 Sep 2006

That works for removing the button if the plugin is not enabled, but I need to remove the button for pages where the workflow is not set. The main plugin page says this should happen automatically, but it's not happening for me.

-- ChrisPurves - 22 Sep 2006

Chris, I just checked this in my installation. I modified viewtoolbar.pattern.tmpl as follows:

*** /e/www/twiki-dakar-4.0.2/templates/viewtoolbar.pattern.tmpl   Fri Mar 31 23:44:56 2006
--- /e/www/twiki-dakar-4.0.2/templates/Test/viewtoolbar.pattern.tmpl   Fri Sep 22 20:05:25 2006
*** 1,5 ****
  %TMPL:DEF{toolbar_buttons}%<div class="patternToolBarButtons">
! %TMPL:P{"activatable_raw_edit"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%<span class="patternButton">%TMPL:P{"activatable_attach"}%</span><span class="patternButton">%TMPL:P{"printable"}%</span>
--- 1,5 ----
  %TMPL:DEF{toolbar_buttons}%<div class="patternToolBarButtons">
! <span class="patternButton"> %WORKFLOWTRANSITION% </span> %TMPL:P{"activatable_raw_edit"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%<span class="patternButton">%TMPL:P{"activatable_attach"}%</span><span class="patternButton">%TMPL:P{"printable"}%</span>

In other words, I just put the %WORKFLOWTRANSITION% tag into the toolbar. The span is not necessary, but it forces the result on the same line as the other buttons.

In my installation this works as expected. If there is a workflow, the button shows. If there is no workflow, it does not show.

However, I don't think this is a good idea. Note that more work would be required to make the button look exactly like the other buttons on the tool bar (maybe I need to make the appearance of the button configurable). But what is worse, if there are multiple state transitions, there will be a drop down menu, which may look awkward in the tool bar?

But back to your problem. Something must be wrong in your installation as I don't see this issue. Here is an idea: Maybe Crawford's recent changes, which I have not integrated in my version yet, might have changed something.

-- ThomasWeigert - 23 Sep 2006

I have installed Crawford's version in my installation and can confirm that I see the behavior you describe. You can see my original version at this demo site. Look at any other page in Sandbox to see that the tag does not appear when it should not...

-- ThomasWeigert - 23 Sep 2006

I have updated this plugin to allow putting the tags into templates etc. and removing them when a page is not under workflow control (i.e., the previous behavior which is promised in the doco).

I have played around with the appearance. It is not hard to get the link to look like the other toolbar buttons when there is only one action. But it does not work as well when there are more actions.

I added the ability to adjust the appearance of the control with either applying a style or a class in the preferences. You can achieve reasonable appearance, but my suggestion would be to put the controls into the bottom action bar, not into the top tools bar, as there you have more freedom to configure it.

-- ThomasWeigert - 24 Sep 2006

Hi Thomas, the new revision works great. Thank you for such a fast response.

Another thing I noticed is that this plugin doesn't work with PublishContrib. That would be a wishlist item for me.

-- ChrisPurves - 25 Sep 2006

Chris, what do you mean by "does not work with PublishContrib "? Can you please explain what you expect that it would be doing?

-- ThomasWeigert - 25 Sep 2006

If I use PublishContrib to generate HTML pages, none of the %WORKFLOW...% variables expand. They are just removed from the topic. My expectation is that I would be able to see that information when I publish. I tried publishing with several different skins (text,plain,print,export,publish,pattern) all with the same results.

From PublishContribDev:

Chris, I'm sure WorkflowPlugin isn't the only plugin that doesn't play nicely 
with publishing. Most plugin authors assume you are always viewing. Drive back onto 
the author of WorkflowPlugin, and get them to honour the "publishing" context identifier.

Sorry for the lack of detail before.

-- ChrisPurves - 26 Sep 2006

Hi, I'm evaluating this plugin (with Dakar 4.0.4 on Solaris), and have two things to bring up - one a resolved problem and the other a problem I need help with.

First, I discovered that values for the State field in the workflow description table apparently need to be one word; I haven't seen that documented. I had a State value of 'ON HOLD', but it was causing problems for %WORKFLOWHISTORY% - I was getting multiple entries per transition to that State, and %WORKFLOWSTATEMESSAGE% never changed to the value for ON HOLD. Here is an example of what happened to %WORKFLOWHISTORY% with just one transition to ON HOLD:

%META:WORKFLOWHISTORY{value="   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD
%0d%0a   * 04 Oct 2006 - 16:35 -- Main.JohnWorsley changed to ON HOLD

I tried 'ON-HOLD' as well, but the behavior didn't change. Once I made it 'ONHOLD' the problem cleared up. Just wanted to let someone know.

The second thing is, I'm still figuring out TWiki forms, and when I defined a form for one of my States, and applied that workflow to a topic that already had a form, the workflow form replaced the topic's existing form when I changed to that State. Since the existing form was the whole point of the topic (automatically generated unique topic names via a template), this is a problem for me. Is that a basic TWiki limitation, or is there a way around it?

-- JohnWorsley - 05 Oct 2006

You can only have one form. You can solve your problem by all the state-based form sharing the content that you have in your original form. Then this content will be maintained across state transitions. E.g., you have a form with a field "topicname" attached initially to your workflow controlled topics. Just make sure that all your state-based forms (which would collect additional information) have that field "topicname" also.

Further, I do not see the behavior you describe. I used the example workflow DocumentApprovalWorkflow and changed UNDERREVISION to UNDER REVISION. Everything works as expected... Can you please send me your work flow definition that causes the problem?

The one unclean thing is that variables are being generated that are not strictly speaking TWikiVariables. For example, we will get %%WORKFLOWLASTVERSION_UNDER REVISION% . This works due to how perl handles hashes, but is not following TWiki syntax.

So all that said, I agree that states should be single words. Alternatively, we can allow multiple words, but should say that the variables generated obey TWiki syntax.

But I am concerned why you are getting the behavior you describe...

-- ThomasWeigert - 05 Oct 2006

I need a site wide approval system. Can the 'edit' button be replaced with an 'need approval' button. Also, I have noticed that the unapproved post is displayed for everyone to see.

-- SteveStark - 25 Oct 2006

On the edit button, that is easy. Just change the view template.

On the "unapproved post" question, I don't understand what you are saying. Can you clarify?

-- ThomasWeigert - 26 Oct 2006

When the topic is edited and then saved, it is still displayed for members to see and regardless that the topic is still waiting for approval. My idea of an approval system is that an unauthorized member should not see the unapproved topic until it is approved. I would like that option to be available and I am hoping that it is my mistake and that it is.

-- SteveStark - 30 Oct 2006

Steve, I understand your suggestion now. First please remember that the WorkflowPlugin focus is primarily the management of a work flow, not security related. The use of document approval is just an example. Second, TWiki is not very good at preventing users who have access to a web from seeing a topic (read TWikiAccessControl) for more detail.

All that said, your idea is a good one and I will consider how to support. However, this is not possible now other than by manually changing the access control settings in TWiki.

-- ThomasWeigert - 30 Oct 2006

If that option could be implemented, then I believe Twiki would be the first open source wiki to have that option.

-- SteveStark - 30 Oct 2006


I have been modifying this Plugin to allow concurrent reviewing of a state and thought I would post my changes here for people to look at.

It uses an extra column in the transition table that holds a percentage (i.e. 50%). It will then look up how many people are in the allowed column. If there are four users allowed, then two of them will need to review the current state for the next state to be reached. If the user has reviewed the current state, they will not be able to review it again.

This also works with groups, so if you have groups in the allowed column and you are in one of those groups when you review the state, it is assumed you are reviewing on behalf of the group and that group is recorded as the reviewer.

Obviously you can set it to 0% to keep the current behaviour, or just leaving the column empty has the same effect.

I have also made a couple of random minor changes, such as:

  • It prevents attachments to topics if the user is not allowed
  • Respects the debug setting in the Plugin topic
Anyway, its attached if you want to look at it. I thought about posting it direct to the plugin topic but noticed the modification policy was ContactAuthorFirst. Feel free to use this in a new release if you want it and I'll be happy to update the documentation as well (since I have already done it on our local plugin topic).

-- AndrewRJones - 28 Nov 2006

I am embarrased to say that I have only just got back to converting to Workflow from Approval, and I am not sure how to use the conversion script (see 9th August 06).

I have tried saving the script as an executable file, then running it in the web with all the approval docs as perl scriptname *

It spews the contents of all the files onto the terminal, but doesn't seem to do anything!

Am I using it wrong? Any ideas?


-- EdMcDonagh - 29 Nov 2006

perl convert.pl < infile > outfile

-- ThomasWeigert - 30 Nov 2006

Thanks Thomas.

For anyone else who has several hundred files to convert, and as little knowledge of either perl or bash as me, the following might be useful!

  • Updated the script below -- TW
1. use the script attached below rather than the one on the main page - that one adds a new line every line, which screws up the formatting. Open it in the browser, then copy it and save it into a text file named convert.pl (or whatever).

2. Use bash to do the work for you:

for i in `ls *.txt*`; do perl convert.pl < $i > $i.mod; done
for i in *.mod; do mv $i `basename $i .mod`; done

-- EdMcDonagh - 30 Nov 2006

I second the feature request to "Add a variable %WORKFLOWSTATE{}% with topic and web parameters, to allow the state be displayed as part of a SEARCH result". I haven't been able to find any way to generate a list of which documents are in which state. That will be a pain in the butt for one portion of the change request workflow I'm trying to develop for my company: if a change request sits in the SUBMITTED state more than 48 hours without any comment from the group, then it gets approved. Without a way to generate a list of documents in the SUBMITTED state, I'm not sure how the person responsible for approvals will track which documents were submitted 48 hours ago.

If anyone has an idea how to accomplish that, to get me through till that feature request is completed and available, that would be lovely. Thanks!

-- JohnWorsley - 08 Dec 2006

OK. Will handle within the week....

-- ThomasWeigert - 08 Dec 2006

Thanks Thomas!
A secondary request: SEARCHing would be easier to perform were the workflow metadata created the first time the document is saved. Currently, the initial state is implied: only when the transition button is activated does metadata get created.

-- JohnFitzpatrick - 08 Dec 2006

I have a question on the WORKFLOWSTATE variable. I have implemented this so that it shows the state of the current document. Rereading above, I get the feeling that you want the state of some other document, as otherwise the web/topic parameter is not required. Can you please clarify the use case?

-- ThomasWeigert - 11 Dec 2006

Yes, the state in another document! I use a regular expression in a SEARCH to display a table of topics, based on a combination of WORKFLOW and FORMFIELD fields. In the table, I can display the content of the FORMFIELDs, but not of the workflow state.

-- JohnFitzpatrick - 11 Dec 2006

OK. Done. This is actually not that straightforward. The tag =%WORKFLOWSTATE% also returns the correct state, when the topic is in the initial state (even though the metadata is not written yet). Hopefully that solves also the secondary request. Writing the metadata into such topic is not right, as when you impose a workflow on all topics via putting it into the WebPreferences, you would have to go through and suddenly write all topics.

-- ThomasWeigert - 12 Dec 2006

Thank you Thomas - the new version does exactly what I need (once I figured out that the topic in which I do the search needs to be under workflow control for this to work). In case anybody else is interested, here's the formatted search that I perform:

    header="| *CCR#* | *State* | *Supplier* | *Title* | *Commodity* | *Plants* | *Buyer* | *Age* | *Last*|"
    format="| [[$web.$topic][$topic]]  | $percntWORKFLOWSTATE{topic=\"$topic\"}$percnt | $formfield(SupplierName) | $formfield(TopicTitle) | [[$formfield(ComponentCommodity)][$percntCALC{$SUBSTITUTE($formfield(ComponentCommodity),Commodity,)}$percnt]] | $formfield(ManufacturingPlant) | $formfield(LeadBuyer) | $percntCALC{$INT($TIMEDIFF($TIME($createdate), $TIME(), days), 1)}$percnt %BR% $createwikiusername | $percntCALC{$INT($TIMEDIFF($TIME($date), $TIME(), days), 1)}$percnt %BR% $wikiusername  |"

This search will not catch the topics that do not yet have metadata. So I do a second search for this case, and then manually perform a workflow transition.

-- JohnFitzpatrick - 12 Dec 2006

ThomasWeigert, this is my second message as someone deleted my first. How is the progression of the approval system?

-- SteveStark - 12 Dec 2006

In June 2006 EricHanson modified the plugin so that users only see the last approved version... has this ever been posted anywhere or does anybody know how to do this.... I am a newbie to perl and twiki so would need the help aimed at that level.... thanks in advance.

-- AdamPatrick - 21 Dec 2006

This Plugin does not show up in twiki/bin/view/TWiki/InstalledPlugins following the installation and enabling WorkflowPlugin with bin/configure). The plugin's files do exist as expected. We are having difficulty getting it to work. How can we tell that we have a successfull installation?

-- PeterJones - 21 Dec 2006

Peter, what version of TWiki are you using? I verified that it shows up in my installation. Are you sure you have properly installed the plugin? Please check that the .pm file has the right permissions.

-- ThomasWeigert - 21 Dec 2006

I am running Dakar 4.0.5. The plugin has been put here https://twiki.cern.ch/twiki/bin/view/TWiki/WorkflowPlugin

The .pm file had the same rights as the other .pm files in /lib/TWiki/Plugins and I get the same results if I chmod 777

-- PeterJones - 21 Dec 2006

Peter, I have this plugin installed at 4.0.4 and on the 4.1 beta, and in both situations it shows up.

-- ThomasWeigert - 21 Dec 2006

There is nothing obvious in the logs. If I manually set $debug=1 then I get many OK entries in debug.txt. However we still cant see it on the Plugins list and cant get any joy using the plugin. What else can I do to check that it is successfully installed?

-- PeterJones - 22 Dec 2006

To be honest, I cannot image what else could be going on. I assume that other plugins come up fine? I won't be able to look at this as I am away from my computer until first week in Jan.

I have installed the latest twiki at my demo site for you to experiment with. You can also experiment with a TWiki 4.0.5 installation.

-- ThomasWeigert - 23 Dec 2006

I noticed that in %WORKFLOWHISTORY%, the user who is making the state change is not logged. Instead, it is the TWiki name of the user who last made a revision to the topic. I find that misleading so I modified WorkflowPlugin.pm to instead log the TWiki name of the user making the state change to %WORKFLOWHISTORY%. Here is what I did:

Under the changeWorkflowState subroutine I deleted the following line:

$fmt =~ s/\$wikiusername/$revuser->webDotWikiName()/geo;

and replaced it with:

    my $twikiuser = $TWiki::Plugins::SESSION->{user}->{web} . '.' . $TWiki::Plugins::SESSION->{user}->{wikiname};
    $fmt =~ s/\$wikiusername/$twikiuser/geo;

Is this change out of line with the intention of the plugin?

-- CharlesJohnson - 17 Jan 2007

Thanks, Charles. Will take into the code base asap...

-- ThomasWeigert - 17 Jan 2007

If I have a topic template under workflow and then generate a normal topic from this template, the new topic gets the workflowhistory from the topictemplate. I think this isn't the rigth behaviour

-- WilhelmMeier - 07 Feb 2007

Whatever is in the topic template will show up in a topic derived from the template, per TWiki specification. Therefore, it is probably not a good idea to have the topic template under a work flow, as that would mean that whatever state the template is in would be the state the generated topic is in, ditto with history, etc. I assume that is the situation you are describing? That behavior is, as I said, per TWiki spec and is not easily changed.

-- ThomasWeigert - 07 Mar 2007

Apologies for being a code tease, I didn't think people were interested in only allowing people to view the approved version. I have uploaded the Cairo plugin as viewLatestVerApprovalPlugin.pm. It has been too long for me to remember what I changed, beyond seeing if the user can 'approve' the topic, if not, get the last approved version and display that.

Update The reason I never posted my code back to this forum, is because I never modified the code. My apologies for the misleading comments above. I used the PublishContrib (PublishAddOn ?) plugin in conjunction with the Approval plugin to only publish 'Approved' pages, by looking at the metadata tags. I am removing my attachment, since it is unaltered from the original ApprovalPlugin from Feb 05.

-- EricHanson - 08 Mar 2007

Is there a way of getting %WORKFLOWHISTORY% to output the data in a table format ? That would make the revision history much neater.

-- ScottDitter - 19 Mar 2007

To output as a table, just use the wiki syntax for table. Something like this:

   * Set WORKFLOWHISTORYFORMAT = "| $state | $wikiusername | $date |"

You may also wan't to use this:

| State | Name | Date |

-- AndrewRJones - 19 Mar 2007

thanks Andrew but I tried that and it didn't work, will try again if it worked for you ?

Also how are people generating revision histories ? the WORKFLOWHISTORY expansion is close but doesn't allow for adding any comments relating to the document changes (?)

-- ScottDitter - 20 Mar 2007

Also if anyone is interested I added this line below at line number 313 in the plugin script to be able to incorporate the wiki version in the workflowhistory output:

$fmt =~ s/\$rev/$globCurrentState->{"LASTVERSION_$state"}/go;

now you can have:

Set WORKFLOWHISTORYFORMAT = " * Wiki revision $rev, $state, $wikiusername, $date"

-- ScottDitter - 20 Mar 2007

Thanks Andrew it does work now - not sure what I was doing wrong last time smile Now I have a nice table with links to each wiki version with this format setup:

* Set WORKFLOWHISTORYFORMAT = "| <a href="ProcessTemplate?rev=$rev">$rev</a> | $state | $wikiusername | $date |"


Wiki Version Status Name Date
1 UNDERREVISION ScottDitter 20 Mar 2007 - 14:11
-- ScottDitter - 20 Mar 2007

Overall I am quite happy with this plugin! I have run into what seems like an oddity that I'm hoping to get help with. In short, when I use %WORKFLOWTRANSITION% to change the state, IF statements in the same topic that are dependent on the value of %WORKFLOWSTATE% do not update even though the value of %WORKFLOWSTATE% clearly does change.

In the topics I am using the %WORKFLOWTRANSITION% variable in, I also have IF statements that are intended to display different text depending on state the topic is in (this template works well for a test:

%IF{"$ WORKFLOWSTATE = 'REVISING'" then="This topic is in the REVISING state." else="This topic is *not* in the REVISING state."}%

Here, using the above example IF statement, is what happens:

  1. I choose REVISING from the dropdown list provided by %WORKFLOWTRANSITION%.
  2. I hit the 'Change status' button.
  3. The status changes, and the value of %WORKFLOWSTATE%, %WORKFLOWTRANSITION%, and %WORKFLOWMESSAGE% all update.
  4. The revision number increments if appropriate.
  5. The IF statements, however, continue to resolve based on the previous value of %WORKFLOWSTATE%. The text "This topic is not in the REVISING state." appears in the topic.
  6. I cannot reload the document using the browser's reload button because it warns me that will repost data from a form action.
  7. If I reload the document by e.g. choosing it from the recent changes list, then the IF statements resolve with the current value of %WORKFLOWSTATE%. The text "This topic is in the REVISING state." appears in the topic.
-- JohnWorsley - 05 Apr 2007

A bit more information that would probably help: I am using the latest version of WorkflowPlugin, dated Jan 05, 2007, and have encountered this problem on TWiki 4.1.1 and 4.1.2.

-- JohnWorsley - 24 Apr 2007

There appears to be a negative interaction between TreeBrowserPlugin and WorkflowPlugin, in that as soon as I enabled TreeBrowserPlugin the state transistions stop working in WorkflowPlugin. Being neither a perl nor css program, I have no idea were to start looking. Both are great plugins and I want them both.

-- KenLockhart - 04 May 2007

Is there a way to display the latest approved revision number from a different topic? %WORKFLOWLASTVERSION_APPROVED% doesn't support topic="..." the way %WORKFLOWSTATE% does and using == doesn't expand the WORKFLOW variables.

-- ChrisPurves - 09 May 2007

I have found a problem when using the Workflow Plugin with the URLPARAM TWiki varaible. If I use the URLPARAM in a sandbox topic to update a table based on a form input everything works normally. If I workflow control the same topic, when I send the topic for approval, the URLPARAM variable resolves to the calculated value and replaces the variable when I view the raw text.

-- ChrisPurves - 26 Jun 2007

Hi. I developped new functionnalities in the Workflow Plugin for my project requirement such as an automatic notification by email when the workflow state changes, the possibility of having different topics interacting in terms of workflow (a topic called workflow master when changing state can force another topic to change its state) and the possibility of opening directly a link when the state changes (interesting to automatically create topics in using the TopicCreatePlugin. I'd like to know if people are interested in this version of the plugin. If i want to publish it, since the modifications are quite major, do i have to change the name of the plugin and create a new page ? Thx

-- GuillaumeBardy - 02 Jul 2007

Guillaume, I for one would be very interested in having e-mail notification and hope you decide to publish your version! Do you maintain backward compatibility with the original plugin?

-- JohnFitzpatrick - 05 Jul 2007

Until now it's not compatible : I mean you'd have to modify your topics describing the workflow to be compliant with my plugin... but it's not really an issue and i can manage to have compatibility with the original plugin. I'll publish my version a bit later when i'm less in a rush in my work... thx

-- GuillaumeBardy - 06 Jul 2007

Hi Guillaume and John. I have also been working on a variation of the WorkflowPlugin, which I have called ApprovalPlugin. This version has email notifications and allows concurrent reviewing. The plugin has been implemented slightly differently than the WorkflowPlugin (code wise), and uses a slightly different syntax (%APPROVAL....%).

I plan to publish this on twiki.org either Monday or Tuesday next week, once it has been properly tested. If you can not put your changes into the WorkflowPlugin, you will be more than welcome to implement them in the ApprovalPlugin, providing it keeps the current functionality.

With regards to backwards compatibility, the ApprovalPlugin comes with a script to convert the syntax, and provides similar functionality except a couple of variables ( %WORKFLOWLASTTIME_State%, %WORKFLOWLASTVERSION_State%) and the use of TWikiForms, though if someone had the motivation they could easily add this.

-- AndrewRJones - 06 Jul 2007

Andrew, there used to be an ApprovalPlugin, which is obsoleted. Please feel free to re-purpose this namespace for your plugin.

-- PeterThoeny - 14 Jul 2007

Andrew or Guillaume : any progress on sharing your plugins?

-- JohnFitzpatrick - 30 Jul 2007

My plugin is complete and available in subversion (Bugs:Item4422), but for some reason it only works on TWiki 4.2 (Freetown, as yet unreleased), and I can't get it working on 4.1. There must be a bug in 4.1, which has been fixed since. Until it works on 4.1 there is little point releasing it. However, your more than welcome to check it out of subversion and have a look at it, provide some feedback or enhance it.

-- AndrewRJones - 30 Jul 2007

My plugin has been tested and is working with no problem... Still need some time to publish it (clear the code and put more comments, create the plugin topic...). I have no date yet but in less than one month it'll be released... The thing is i don't know if i have the right to create a new plugin since i have been using the code of the Workflow plugin : in my plugin, half of it has been written by workflow plugin's author.

-- GuillaumeBardy - 02 Aug 2007

Guillaurne, if your plugin is not 100% backward compatible with WorkflowPlugin,you may create a new plugin as long as the licence is compatible and you acknoledge the original author.

BUT if you can invest a little more time making it backward compatible, then you can (with the plugin author's approval) make your code into the latest version of WorkflowPlugin. The advantage is that you get a "wider" installed base, and the efforts to improve are focused.

OTOH, given that there are 3 different Workflow initiatives (well... 4, but mine is still for private consumption), perhaps we should think about taking the comonalities out into WorkflowEngineContrib or something, and build our plugins on top of that (seriously, how many ways are to represent a state machine).

-- RafaelAlvarez - 02 Aug 2007

I agree, having a contrib would be very useful. I have had to substantially modify WorkflowPlugin for use at my company, primarily to add email notifications on certain state changes.

The fact that this many people have come up with variations on WorkflowPlugin tells me that there's a need for a more flexible approach, and that's what a contrib would provide.

-- JohnWorsley - 03 Aug 2007

I agree too with this idea. Actually i think the best idea would to document our different versions well to provide all the informations needed to create this contribution. From my side, it's already kinda compatible with the Workflow plugin, only some changes to do but not that much. So my thing is just providing capabilities in terms of email notifications, controlling Workflow from one topic from another (when a state change in the topic controlling it'll put the controlled topic in another state, it can be done on several topics on several levels), and it has been customized to open specified links when reaching specified states (this is very usefull to create topics from a template for example when reaching some states). Although the management of the states is still the same with the workflow plugin : i need the same variables and the topic describing the workflow plus a few new variables and a few new columns in the table describing the workflow. But do we really need a contrib for that ? Or could we just build a WorkflowPlugin with better capabilities from our different customizations ? Actually i don't really know what is the difference between a contrib and a plugin... I think the contrib doesn't give you a directly usable tool... I don't see why we couldn't work together to build a new plugin.

-- GuillaumeBardy - 06 Aug 2007

Sounds like a good idea to put all our changes in one place. The documentation for mine is already in SVN (http://svn.twiki.org/svn/twiki/trunk/ApprovalPlugin/data/TWiki/ApprovalPlugin.txt). The way I have represented the state machine in my plugin is different than in the WorkflowPlugin, as I found it a lot easier the way I did it.

-- AndrewRJones - 06 Aug 2007

Guillaume, the purpose of Contribs is to provide a "common ground" for other extensions: EditContrib is the common code behind SectionalEditPlugin and MultiEditContrib, TwistyContrib and other javascript-related contribs provide a package for javascript libraries so plugins can use them without each one distributing it's own version, LdapContrib provides services that plugins can use to query an LDAP system, etc.

In that light, it make sense to take the commonalities, and abstract them into a WorkflowContrib, and then use that contrib in each of our plugins. When our plugins are developed and mature, and if they converge in functionality, we can consolidate them. From the experience with XpTrackerPlugin and with our product, I can tell you that is very, very difficult to build a "one-size-fit-all" plugin for complex functionalities.

Our (internal) variation of WorkflowPlugin has the following differences:

  • Database Backend, provided by another unreleased contrib.
  • Uses the same topic format to describe the workflows.
  • The topic is translated into a workflow definition object.
  • Does not change the form of the controlled topic.
  • Topics are put into Workflow control setting the WORKFLOW variable
  • Does not support (yet) WORKFLOWLASTTIME_State and WORKFLOWLASTVERSION_State
  • Uses a rest interface to change the state.
  • In the workflow definition, the variable DEVSTATUS to the name of a form field. When the topic changes state, if it has an attached form with that field, it will get updated with the new status.
For the email notification, currently I just use the mailnotify script from MailerContrib in combination with the SubscribePlugin.

-- RafaelAlvarez - 07 Aug 2007

Rafael, off topic, WhyNotReleaseThoseContribs wink

-- KeithHelfrich - 07 Aug 2007

I'm answering there smile

-- RafaelAlvarez - 08 Aug 2007

This is a great plugin!

-- JonSukarangsan - 15 Aug 2007

GuillaumeBardy: 02 Aug 2007: "My plugin has been tested and is working with no problem... in less than one month it'll be released.."

Any news when?

-- MartinCleaver - 02 Oct 2007

Doesn't seem to work with TWiki 4.2 at the moment, bombing out in lib/TWiki/Plugins/WorkflowPlugin.pm at line 445:

if ( $User->isAdmin() ) {

See bug item 4726

-- SueBlake - 16 Jan 2008

Hey guys, How do you reset the history for a topic? I want to "clear" some of my testing workflows.

-- PeterStephens - 16 Jan 2008

I think it is in META:WORKFLOWHISTORY which means you probably need to manually edit the topic.txt file.

-- LarsEik - 17 Jan 2008

Thanks Lars. That is exactly what I was looking for. - Pete

-- PeterStephens - 17 Jan 2008

I attached a small patch ( WorkflowPlugin_v420_patch.txt) which is needed by the current TWiki::Plugins::SESSION interface ($TWiki::Plugins::VERSION >= 1.2)

-- MarkusUeberall - 26 Jan 2008

Does the patch also work with 4.1.X?

-- KennethLavrsen - 26 Jan 2008

I get this after updating the plugin, is it my setup somehow? Fresh 4.2 install: Undefined subroutine &TWiki::Func::IsAnAdmin called at /var/www/twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 446.

-- LarsEik - 28 Jan 2008

Lars, this is a typo in the 'packaged' plugin--the subroutine in question starts with a lowercase letter ("isAnAdmin").

-- MarkusUeberall - 28 Jan 2008

Ooops. I have uploaded a corrected version and also done some additional fixing so that the build script can upload the plugin to twiki.org.

-- KennethLavrsen - 28 Jan 2008

I just installed Workflow on a clean 4.2.0, and get the following error when trying to view a controlled document:

Can't locate object method "isInList" via package "username" (perhaps you forgot to load "username"?) at /path/to/twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 457.

Did the installer UI download an unpatched version, or should I report a bug?

-- AaronFuleki - 14 Feb 2008

The above patch has been applied but was actually incomplete (it only worked for administrators); the attached second patch WorkflowPlugin_v420_patch2.txt contains the missing changes needed for normal users (cf. Bugs:Item5369).

-- MarkusUeberall - 15 Feb 2008

Thanks Markus - I applied patch #2, but now the Workflow plugin seems to have died - none of its TWiki variable are being parsed/replaced, even though the plugin is enabled in configure.

-- AaronFuleki - 15 Feb 2008

Unfortunately I can see this, too. If I log out, close the browser, restart the webserver and retry it (i.e., open the browser again and log in), I sometimes see unresolved variables or even strange error messages about missing subroutines. If you keep reloading the page, it eventually seems to work as expected. Until now I thought that this might be a problem with my configuration, but I'll file a bug report and try to look into this during the next days.

Could you give some details about your setup (OS, Web server, Perl version, installed Plugins) under Bugs:Item5371 ?

-- MarkusUeberall - 15 Feb 2008

My bad - I had changed the file permissions such that Apache couldn't read WorkFlowPlugin.pm smile

The plugin runs now, but I still get:

Can't locate object method "webDotWikiName" via package "{USERNAME}" (perhaps you forgot to load "{USERNAME}"?) at /twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 314

Whenever I click the "start" button on the example topic "DefectOne"

Any ideas?

-- AaronFuleki - 27 Feb 2008

I can reproduce this error (looks like yet another API change) but am currently unable to come up with a solution. It seems that without a working v4.0.x/v4.1.x TWiki installation and a detailed list of API changes (including at least rudimentary comments), there is little to no hope to get this plugin working correctly with v4.2.x in the near future. And it will definitely take more than just a few hours to conduct a thorough code inspection in order to either rule out side effects of the previous patches as the cause of the observed 'erratic behaviour' and/or come up with cleaner modifications. frown

-- MarkusUeberall - 27 Feb 2008

I'm curious if there is any update on incorporating email notifications into this plugin or into a new plugin. There are comments above from July/August 07 about an imminent release of new plugins by GuillaumeBardy and AndrewRJones, but that conversation seems to have died off.

Also, RafaelAlvarez mentions that he uses MailerContrib and SubscribePlugin to achieve the necessary email notifications. I'm wondering if those notifications automatically include information on the workflow state changes in either the change summaries or complete topics format.

-- GarySprague - 28 Feb 2008

I just installed the plugin and successfully created my workflow definition topic and a first controlled topic. The transitions work fine when I am logged in as a user who has rights to edit in all states, but when I log out and try and look at the controlled topic, I get the following error:

"Can't locate object method "isInList" via package "BaseUserMapping_666" (perhaps you forgot to load "BaseUserMapping_666"?) at /var/www/twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 457."

If anyone has an idea about what is causing this, I would be most appreciative of the help.

-- GarySprague - 12 Mar 2008

Okay, so I just realized that my error has already been addressed by the second patch from mid-February.

My question is then whether the plugin creator or anyone else is working on stabilizing it for use in Twiki v4.2?

-- GarySprague - 12 Mar 2008

The plugin seems to support only one run with a document. If pressing revise after one pass if the Workflow is complete, the documents content shows like the the initial content, even if several additions are made during the workflow process. Is this a bug or a feature? Any comments are welcome.

-- StephanMenger - 14 Mar 2008

I'm on Twiki 4.2 and I have the following problem too :

Can't locate object method "webDotWikiName" via package "{USERNAME}" (perhaps you forgot to load "{USERNAME}"?) at /twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 314

Is there any solution ? Any ideas ?

-- EmmanuelHUMBERT - 17 Mar 2008

Hi, we've been using this plugin for managing SOPs (Standard Operating Procedures) in a life-science research lab, and it works great. I hacked-up the code a little to add some extra variables - specifically variables to display which user changed the status last. The tags look like: %WORKFLOWLASTUSER_STATENAME%.

I also added a beforeAttachmentSaveHandler subroutine to check if the user has edit privilege before attaching a file to the topic. If the user does not have edit privilege at this point in the workflow, they get an error page.

Is there any interest in incorporating my hacks? It would make upgrades easier for us!

-- DaveThompsonAnother - 01 Apr 2008

Huh. No matter where or how I set WORKFLOWHISTORYFORMAT, it never takes - I always get the same "$state -- $date".

Anyone else seeing that on 4.2?

-- AaronFuleki - 01 Apr 2008

DaveThompsonAnother, please bring on updates to this plugin. It is listed as "feelfreetomodify". Your updates sounds like a good enhancement to me.

-- LarsEik - 01 Apr 2008

I'm new to the Twiki dev scene, what should I do to incorporate my changes? Do I just attach a .diff?

-- DaveThompsonAnother - 30 Apr 2008

Working in subversion is highly recommended/wanted. See ReadmeFirst and SoYouWantToBeATWikiDeveloper is linked from the readme page, here's instructions for write access to subversion.

-- LarsEik - 01 May 2008

Thanks Lars, absolutely. Dave and others: We have an active plugins community, you are invited to join us if you are an active Perl programmer!

-- PeterThoeny - 01 May 2008

Patch below to fix the 4.2 error "Can't locate object method "webDotWikiName" via package ..." noted above. This is only an issue if you change WORKFLOWHISTORYFORMAT to include a user.

--- WorkflowPlugin.pm   2008-05-15 16:23:59.000000000 -0400 +++ /home/esorton/tmp/WorkflowPlugin/lib/TWiki/Plugins/WorkflowPlugin.pm   2008-04-23 07:51:30.000000000 -0400 @@ -284,7 +284,6 @@      $text = TWiki::Func::expandVariablesOnTopicCreation(          $text ); #TW: really needed?      my ($revdate, $revuser, $version, $revcmt) =  $meta->getRevisionInfo(); -    my $wikiuser = TWiki::Func::getWikiUserName();        #print STDERR("changeWorkflowState from $globCurrentState->{name} to $state");   @@ -305,7 +304,7 @@      $fmt =~ s/\$n\(\)/
/go;      $fmt =~ s/\$n([^$mixedAlpha]|$)/\n$1/gos;      $fmt =~ s/\$state/$globCurrentState->{name}/go; -    $fmt =~ s/\$wikiusername/$wikiuser/geo; +    $fmt =~ s/\$wikiusername/$revuser->webDotWikiName()/geo;      $fmt =~ s/\$date/$globCurrentState->{"LASTTIME_$state"}/geo;      $globHistory .= "\r\n" if $globHistory;      $globHistory .= $fmt; 

-- EricSorton - 15 May 2008

Oops, just noticed the patch above is reversed. Use the -R or --reverse option!

-- EricSorton - 15 May 2008

Is there a way to give a transition permission to the user who created the topic? Something like TopicOwner to the permission column.

Second, I haven't yet figured how can we get a list with the topics in a workflow needing our action. It would be something like a list showing topics for approval which I would have permission to approve and not showing topics already aproved. Is it possible?

And, thanks for the great plugin.

-- NunoAntunes - 23 May 2008

Does CrawfordCurrie 's update from 28 April 2008 address the following error received when attempting to view a controlled topic as an anonymous user?

"Can't locate object method "isInList" via package "BaseUserMapping_666" (perhaps you forgot to load "BaseUserMapping_666"?) at /var/www/twiki/lib/TWiki/Plugins/WorkflowPlugin.pm line 457."

-- GarySprague - 05 Jun 2008

Is anyone working on AndrewRJones 's ApprovalPlugin that's in SVN? Apart from having to comment out one line in a log subroutine, it seems to be fine here with TWiki 4.2, including mail notifications.

-- SergeiKlink - 09 Jun 2008

After some hiccups, I have the plugin working on TWiki 4.2. I am very interested in Dave Thompson's addition of a variable to capture the user who last changed the status: %WORKFLOWLASTUSER_STATENAME%. Could this be provided as a patch or is there a way I could add this into the plugin module without having to wait for a whole new version?

-- GarySprague - 21 Jun 2008

I have an issue with state transitions that change the TWikiForm. See Bug 6036.

-- DeanSpicer - 01 Oct 2008

TWikibug:Item6281 submitted:

The plugin seems to attempt to include the login name of whomever last edited the wiki page as some sort of Perl package? This is pretty serious as it stops a functioning applications and any further use of it.

-- AJAlfieriCrispin - 2009-06-15

This plugin needs to be updated to the latest TWiki plugin API. The fault you mention is due to a change in TWiki API on how users are handled, so the parameters of this function call are out of order.

-- ThomasWeigert - 2009-06-16

I installed the plugin into TWiki 4.1 (un-tar and fixing some permissions/ownerships instead of using installer). As soon as I enable the plugin, every attempt to access a page of the Wiki results in an internal error message complaining that the subroutine &TWiki::Func::pushTopicContext were undefined. What went wrong?

-- DetlefMarxsen - 2010-09-23

Detlef, I am not sure whether TWiki::Func::pushTopicContext is available in 4.1. I don't have an old installation, so please check in your file lib/TWiki/Func.pm for this subroutine.

Independent of this, I highly recommend you upgrade at least to 4.3.1, but I believe you do know that 5.0 is out as well?

-- ThomasWeigert - 2010-09-23

No, the function is missing there. But why is this plugin stated as being compatible with 4.1 on the WorkflowPlugin page?

Concerning the upgrade: I haven't got much time to put aside for that (Wiki is just one task of many here at work). I did an upgrade on another TWiki installation some years ago and it consumed quite some hours until everything worked. Has the upgrade procedure approved meanwhile?

-- DetlefMarxsen - 2010-09-24

The upgrade from 4.1 to 4.3.1 should be much more painless than earlier upgrades, as should be the upgrade to 5.0. However, there are still a few places where one has to be careful as to regards your preexisting configuration, in particular, if you have not been diligent about keeping your customization separate from the TWiki web.

I am not sure why the plugin states that it is compatible with 4.1., as these changes were not made by me. I will take this out, based on your feedback.

-- ThomasWeigert - 2010-09-24

Plugin not working, red icon next "{Plugins}{WorkflowPlugin}{Enabled}" ... Did a manual installation which resulted in the above problem. Then I discovered that the installation can be made via the Extensions section of "configure" (sorry, last plugin installation is a while ago). I removed all manually installed files and chose the above method. But alas, still no function (for example %WORFLOWBUTTON% is not interpreted) and still the strange red icon. What has gone wrong?

-- Detlef Marxsen - 2013-04-08

What a great plugin! However ...
The documentation of the plugin states that the WORKFLOW-variables take an optional parameter which is the topic which I am interested in.
This works with WORKFLOWSTATE: %WORKFLOWSTATE{"ThatTopic"}%
For getting the revision when the topic was last in "QM-RELEASED" state I use %WORKFLOWLASTREV_QM-RELEASED{"ThatTopic"}%. But, alas, this does not get parsed but stands as is in the rendered text.
WORKFLOWLASTREV_QM-RELEASED works fine without paramater in the topic itself.

What am I doing wrong?

-- Detlef Marxsen - 2017-01-27

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff LastWho.diff r1 manage 1.4 K 2005-08-31 - 13:53 SteveKostecke Store/Display who changed the state
Perl source code filepm WorkflowPlugin.pm r1 manage 18.4 K 2006-11-28 - 15:50 AndrewRJones Modified to allow concurrent reviewing of a state
Texttxt WorkflowPlugin_v420_patch.txt r3 r2 r1 manage 0.4 K 2008-01-27 - 01:24 MarkusUeberall Small patch needed for TWiki::Plugins v1.2 (i.e., TWiki 4.2)
Texttxt WorkflowPlugin_v420_patch2.txt r1 manage 0.5 K 2008-02-15 - 11:51 MarkusUeberall Changes for non-admin users missing in patch WorkflowPlugin_v420_patch.txt
PNGpng bottom.png r1 manage 1.5 K 2006-09-21 - 19:46 ChrisPurves transition inserted in footer
PNGpng bottom_no_set.png r1 manage 1.0 K 2006-09-21 - 19:47 ChrisPurves footer with no set workflow
Texttxt convert.pl.txt r1 manage 0.3 K 2006-11-30 - 16:12 EdMcDonagh Modified conversion script without the final newline command
PNGpng top.png r1 manage 12.5 K 2006-09-21 - 19:45 ChrisPurves transition inserted in top header
PNGpng top_no_set.png r1 manage 4.8 K 2006-09-21 - 19:46 ChrisPurves header with no set workflow
Edit | Attach | Watch | Print version | History: r181 < r180 < r179 < r178 < r177 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r181 - 2017-01-27 - DetlefMarxsen
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.