[Checkins] SVN: Products.DCWorkflow/branches/2.1/ - pinning GS to 1.3.3

Jens Vagelpohl jens at dataflake.org
Tue Aug 26 07:24:37 EDT 2008

Log message for revision 90301:
  - pinning GS to 1.3.3
  - reformat README for PyPI prettiness
  - synthesized CHANGES.txt from the monolithic file at

  _U  Products.DCWorkflow/branches/2.1/
  A   Products.DCWorkflow/branches/2.1/Products/DCWorkflow/CHANGES.txt
  U   Products.DCWorkflow/branches/2.1/Products/DCWorkflow/README.txt
  U   Products.DCWorkflow/branches/2.1/setup.py


Property changes on: Products.DCWorkflow/branches/2.1
Name: svn:ignore
   + Products.DCWorkflow.egg-info

Copied: Products.DCWorkflow/branches/2.1/Products/DCWorkflow/CHANGES.txt (from rev 90278, Products.DCWorkflow/trunk/Products/DCWorkflow/CHANGES.txt)
--- Products.DCWorkflow/branches/2.1/Products/DCWorkflow/CHANGES.txt	                        (rev 0)
+++ Products.DCWorkflow/branches/2.1/Products/DCWorkflow/CHANGES.txt	2008-08-26 11:24:37 UTC (rev 90301)
@@ -0,0 +1,109 @@
+Products.DCWorkflow Changelog
+2.1.2 (2008-08-26)
+- completed devolution from monolithic CMF package into its component
+  products that are distributed as eggs from PyPI.
+2.1.1 (2008-01-06)
+- no changes
+- Testing: Derive test layers from ZopeLite layer if available.
+- exportimport: Scripts with invalid types imported
+  after scripts with valid types will no longer place the valid
+  script twice.  Scripts can also now be specified with meta_types
+  other than the hard-coded meta_types.
+- AfterTransitionEvent now passes along the new status of the
+  object, just as StateChangeInfo passes on the new status to
+  after-transition scripts.
+  (http://www.zope.org/Collectors/CMF/490)
+2.1.0 (2007-08-08)
+- Fixed all componentregistry.xml files to use plain object paths and strip
+  and slashes. GenericSetup does only support registering objects which are
+  in the site root.
+2.1.0-beta2 (2007-07-12)
+- moved the Zope dependency to version 2.10.4
+- Remove antique usage of marker attributes in favor of interfaces,
+  leaving BBB behind for places potentially affecting third-party code.
+  (http://www.zope.org/Collectors/CMF/440)
+- Add POST-only protections to security critical methods.
+  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0240)
+- Workflow definition instances now have a description field
+  (http://www.zope.org/Collectors/CMF/480)
+2.1.0-beta (2007-03-09)
+- moved the Zope dependency to verson 2.10.2
+- Tool lookup and registration is now done "the Zope 3 way" as utilities, see
+  http://svn.zope.org/CMF/branches/2.1/docs/ToolsAreUtilities.stx?view=auto
+- Merged patches from Martin Aspeli to enable generating events before
+  and after DCWorkflow transitions, and in the 'notify' methods of the
+  workflow tool (http://www.zope.org/Collectors/CMF/461).
+2.1.0-alpha2 (2006-11-23)
+- moved the Zope dependency to version 2.10.1
+- Fixed test breakage induced by use of Z3 pagetemplates in Zope 2.10+.
+- browser views: Added some zope.formlib based forms.
+- testing: Added test layers for setting up ZCML.
+2.1.0-alpha (2006-10-09)
+- skins: Changed encoding of translated portal_status_messages.
+  Now getBrowserCharset is used to play nice with Five forms. Customized
+  setRedirect and getMainGlobals scripts have to be updated.
+- Profiles: All profiles are now registered by ZCML.
+- ZClasses: Removed unmaintained support for ZClasses.
+  Marked the 'initializeBases*' methods as deprecated.
+- Content: Added IFactory utilities for all content classes.
+  They are now used by default instead of the old constructor methods.
+- Content: All content classes are now registered by ZCML.
+  ContentInit is still used to register oldstyle constructors.
+- setup handlers: Removed support for CMF 1.5 CMFSetup profiles.
+Earlier releases
+For a complete list of changes before version 2.1.0-alpha, see the HISTORY.txt
+file on the CMF-2.1 branch:

Modified: Products.DCWorkflow/branches/2.1/Products/DCWorkflow/README.txt
--- Products.DCWorkflow/branches/2.1/Products/DCWorkflow/README.txt	2008-08-26 11:24:23 UTC (rev 90300)
+++ Products.DCWorkflow/branches/2.1/Products/DCWorkflow/README.txt	2008-08-26 11:24:37 UTC (rev 90301)
@@ -1,10 +1,66 @@
+ Products.DCWorkflow
-There is some documentation in the 'doc' directory.
+This product provides fully customizable workflows for the CMF 
+portal_workflow tool.
-I encourage you to experiment with what's available and invite you to
-ask questions about the tool on zope-cmf at zope.org.  Future development
-depends entirely on people's needs, so speak up!
-Shane Hathaway
-Zope Corporation
-shane at zope.com
+To see an example, after installing DCWorkflow, using the "Contents"
+tab of your portal_workflow instance add a "CMF default workflow (rev 2)"
+Developing a workflow
+This tool is easiest to use if you draw a state diagram first.  Your
+diagram should have:
+- States (bubbles)
+- Transitions (arrows)
+- Variables (both in states and transitions)
+Remember to consider all the states your content can be in.  Consider
+the actions users will perform to make the transitions between states.
+And consider not only who will be allowed to perform what functions,
+but also who will be *required* to perform certain functions.
+On the "States" tab, add a state with a simple ID for each state on
+your diagram.  On the "Transitions" tab, add a transition with a simple
+ID for each group of arrows that point to the same state and have
+similar characteristics.  Then for each state choose which transitions
+are allowed to leave that state.
+Variables are useful for keeping track of things that aren't very well
+represented as separate states, such as counters or information about
+the action that was last performed.  You can create variables that get
+stored alongside the workflow state and you can make those variables
+available in catalog searches.  Some variables, such as the review
+history, should not be stored at all.  Those variables are accessible
+through the getInfoFor() interface.
+Worklists are a way to make people aware of tasks they are required
+to perform.  Worklists are implemented as a catalog query that puts
+actions in the actions box when there is some task the user needs to
+perform.  Most of the time you just need to enter a state ID,
+a role name, and the information to put in the actions box.
+You can manage all of the actions a user can perform on an object by
+setting up permissions to be managed by the workflow.  Using the
+"Permissions" tab, select which permissions should be state-dependent.
+Then in each state, using the "permissions" tab, set up the
+role to permission mappings appropriate for that state.
+Finally, you can extend the workflow with scripts.  Scripts can be
+External Methods, Python Scripts, DTML methods, or any other callable
+Zope object.  They are accessible by name in expressions.  Scripts
+are invoked with a state_change object as the first argument; see
+Once you've crafted your workflow, you hook it up with a content type
+by using the portal_workflow top-level "Workflows" tab.  Specify the
+workflow name in the target content type's box.

Modified: Products.DCWorkflow/branches/2.1/setup.py
--- Products.DCWorkflow/branches/2.1/setup.py	2008-08-26 11:24:23 UTC (rev 90300)
+++ Products.DCWorkflow/branches/2.1/setup.py	2008-08-26 11:24:37 UTC (rev 90301)
@@ -46,7 +46,7 @@
           #'Zope >= 2.10.4',
-          'Products.GenericSetup',
+          'Products.GenericSetup==1.3.3',

More information about the Checkins mailing list