Revision history for Perl extension Workflow

# $Id: Changes 526 2010-08-06 06:25:51Z jonasbn $

1.34 Fri Aug 6 08:24:54 CEST 2010 (update not required)

The issue demonstrated here, which can be observed in perl versions newer than 5.10.0 seems to be related to a issue mentioned here:

http://rt.perl.org/rt3/Public/Bug/Display.html?id=70171

RT #53909 is based on blead perl, in which also a fix has now been implemented, but we still have issues with a lot of perl releases currently out there, see:

http://matrix.cpantesters.org/?dist=Workflow+1.33

So this work-around seems to fix the issue, since I can no longer replicate the error. The problem seem to be the clearing of a package scoped variable, the array @observations in t/SomeObserver.pm

1.33 Sat Jan 30 11:51:18 CET 2010 (update recommended)

        Workflow::Config, bumped up to version 1.13
        Workflow::Persister, bumped up to version 1.10
        Workflow::Factory, bumped up to version 1.19
        
        - Adding ability to control initial state name via workflow config

        - Adding ability to control initial history record details via Persister
      subclass code

1.32 Mon 26 Jan 2009 (Update not necessary)

Removed VERSION file, this has now been obsoleted

We are now resolving the version number for the distribution from Workflow.pm the main module, this mean a jump from 0.31 to 1.32, but it does mean that an installation can be traced back to a given distribution

Example workflow foo and bar can have a condition baz, but baz are two different implementations in foo and bar respectively

0.31 Wed Sep 26 20:26:49 CEST 2007 (update not required)

0.30 Tue Sep 25 12:28:12 CEST 2007 (update not required)

The patch also addresses RT #29037

https://rt.cpan.org/Public/Bug/Display.html?id=29037

which is related to a failing test:

http://www.nntp.perl.org/group/perl.cpan.testers/2007/08/msg582727.html

0.29 Mon Sep 24 23:09:12 CEST 2007 (update not required)

0.28 Fri Jul 6 16:42:30 CEST 2007 (update not required)

We now have a POD coverage of 100%, this does however not say anything about the quality of the spelling or POD. All POD will however be revisited at some point.

Please remember to document changes and additions.

This should address the failing test, ref: http://www.nntp.perl.org/group/perl.cpan.testers/2007/07/msg527994.html

0.27 Tue Jul 3 16:50:15 CEST 2007
(update not required unless you are using 0.26 or 0.25)

Action::Mailer 1.01
Workflow 1.32
Workflow::Action 1.09
Workflow::Action::InputField 1.09
Workflow::Action::Null 1.03
Workflow::Base 1.08
Workflow::Condition 1.07
Workflow::Condition::Evaluate 1.02
Workflow::Condition::HasUser 1.05
Workflow::Config 1.11
Workflow::Config::Perl 1.02
Workflow::Config::XML 1.04
Workflow::Context 1.05
Workflow::Exception 1.08
Workflow::Factory 1.18
Workflow::History 1.09
Workflow::Persister 1.09
Workflow::Persister::DBI 1.19
Workflow::Persister::DBI::AutoGeneratedId 1.06 Workflow::Persister::DBI::ExtraData 1.05 Workflow::Persister::DBI::SequenceId 1.05 Workflow::Persister::File 1.10
Workflow::Persister::RandomId 1.03
Workflow::Persister::SPOPS 1.07
Workflow::Persister::UUID 1.03
Workflow::State 1.13
Workflow::Validator 1.05
Workflow::Validator::HasRequiredField 1.04 Workflow::Validator::InEnumeratedType 1.04 Workflow::Validator::MatchesDateFormat 1.06

This should address the 'N/A' status, ref: http://www.nntp.perl.org/group/perl.cpan.testers/2007/05/msg492425.html

Currently we have BAD POD coverage so the test fails.

0.26 Wed Mar 7 09:25:06 CET 2007 (update not required unless you are using 0.25)

0.25 Thu Dec 14 09:11:57 CET 2006 (update not required)

0.24 Thu Dec 14 08:55:05 CET 2006 (update not required)

This is why this patch introduces the "may_stop" property for a state, which means that Workflow won't complain if the state is autorun and no or too many activities are present.

0.23 Tue Sep 12 16:54:25 CEST 2006 (update not required)

0.22 Fri Aug 18 23:26:55 CEST 2006 (update not required)

So subs are now marked with head3 instead of B<>, I am of the opinion that titles should be marked as titles and B<> (bold) should be used to emphasize important information in the POD.

0.21 Fri Jul 7 23:25:35 CEST 2006 (update not required)

0.20 Fri Jul 7 22:29:19 CEST 2006 (update not required)

0.19 Fri Jul 7 20:40:33 CEST 2006 (update not required)

0.18 Fri Jul 7 14:47:00 CEST 2006 (update not required)

coverage of Workflow::Config::Perl has gone from 0 to 89.0 with this release

0.17 Wed Nov 30 21:51:31 EST 2005

lib/Workflow/Persister/DBI.pm:

0.16 Tue Nov 29 22:12:25 EST 2005

META.yml:

lib/Workflow.pm:

lib/Workflow/Factory.pm:

lib/Workflow/Persister/DBI.pm:

POTENTIAL BACKWARD INCOMPATIBILITY:

lib/Workflow/Persister/DBI/SequenceId.pm:

0.15 Sun Oct 17 11:17:44 EDT 2004

CPAN/Install notes:

     Also thanks to Michael Roberts for releasing the 'Workflow'
     namespace to this module. If you're interested in workflows I
     strongly encourage you to check out his wftk (Workflow Toolkit)
     project along with the Perl interface when it's released.

       http://www.vivtek.com/wftk.html

Build.PL/Makefile.PL:

eg/ticket/ticket.pl:

t/TestUtil.pm:

Workflow::Factory:

0.10 Tue Oct 12 01:02:11 EDT 2004

Workflow

       Since we've now got 'resulting_state' in a state's action that is
     dependent on the action results of the previous action being run
     (see Workflow::State change), we cannot set the 'new' workflow
     state before executing the action.

       One result: you shouldn't set the 'state' property of any created
     Workflow::History objects -- we'll modify the state of any
     history objects with an empty state before saving them (see
     changes for Workflow::Factory)

       Another result: the value of '$wf->state' inside your
     Action now refers to the EXISTING state of the workflow not the
     SOON TO BE state. Earlier versions had the SOON TO BE state set
     into the workflow before executing the action to make things less
     confusing. Now that it's changed any code you have using the
     state of the workflow (such as in our example 'Trouble Ticket'
     application in eg/ticket/) will give a different value than the
     previous Workflow version.

       This behavior seems more consistent, but comments/suggestions
     are welcome.

     - In 'execute_action()' -- once we're done executing the main
     action, check to see if our new state is an autorun state, and if
     so run it.

Workflow::Action::Null

Workflow::Condition::Evaluate

Workflow::Factory

Workflow::State

     <state name="create user">
         <action name="create">
           <resulting_state return="admin"    state="assign as admin" />
           <resulting_state return="helpdesk" state="assign as helpdesk" />
           <resulting_state return="*"        state="assign as luser" />
         </action>
        ....

       So if the action 'create' returns 'admin', the new state will be
     'assign as admin'; on 'helpdesk' it will be 'assign as helpdesk',
     and all other values will go to state 'assign as luser'.

       Existing behavior (actions returning nothing for a single
     'resulting_state') is unchanged.

0.05 Thu Sep 30 23:11:01 EDT 2004

Workflow::Persister::DBI

0.04 Sun Sep 12 22:17:48 EDT 2004

eg (example application):

Workflow::Config

Workflow::Config::Perl

Workflow::Config::XML

Workflow::Factory

Workflow::Persister::DBI::AutoGeneratedId:

0.03 Mon May 24 19:16:40 EDT 2004

0.02 Sat May 22 00:34:43 EDT 2004

      Updates to test scripts and files they require from CPAN tester
      report -- thanks Barbie!

0.01 Thu May 13 22:08:29 EDT 2004

First CPAN release -- everything is new!