[Checkins] SVN: Products.DCWorkflow/trunk/Products/DCWorkflow/ - reformat README and CHANGES files to render as reST for pretty PyPI page
jens at dataflake.org
Tue Aug 26 05:41:56 EDT 2008
Log message for revision 90278:
- reformat README and CHANGES files to render as reST for pretty PyPI page
- merge all 2.1.x changes from the monolithic CHANGES file at
--- Products.DCWorkflow/trunk/Products/DCWorkflow/CHANGES.txt 2008-08-26 09:41:39 UTC (rev 90277)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/CHANGES.txt 2008-08-26 09:41:56 UTC (rev 90278)
@@ -1,7 +1,117 @@
- Products.DCWorkflow 2.2.0 (unreleased)
- - Fixed an import error (Products.PageTemplates.TALES is gone on
- Zope trunk). Because we require Zope >= 2.10, we don't need a
- BBB conditional import.
+- Fixed an import error (Products.PageTemplates.TALES is gone on
+ Zope trunk). Because we require Zope >= 2.10, we don't need a
+ BBB conditional import.
+- completed devolution from monolithic CMF package into its component
+ products that are distributed as eggs from PyPI.
+- 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.
+- 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.
+- 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.
+- Add POST-only protections to security critical methods.
+- Workflow definition instances now have a description field
+- moved the Zope dependency to verson 2.10.2
+- Tool lookup and registration is now done "the Zope 3 way" as utilities, see
+- 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).
+- 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.
+- 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.
+For a complete list of changes before version 2.1.0-alpha, see the HISTORY.txt
+file on the CMF-2.1 branch:
--- Products.DCWorkflow/trunk/Products/DCWorkflow/README.txt 2008-08-26 09:41:39 UTC (rev 90277)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/README.txt 2008-08-26 09:41:56 UTC (rev 90278)
@@ -1,10 +1,66 @@
-There is some documentation in the 'doc' directory.
+This product provides fully customizable workflows for the CMF
-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 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.
More information about the Checkins