[Checkins] SVN: Products.DCWorkflow/trunk/Products/DCWorkflow/ - reformat README and CHANGES files to render as reST for pretty PyPI page
Jens Vagelpohl
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
http://svn.zope.org/CMF/branches/2.1/CHANGES.txt?rev=87755&view=auto
Changed:
U Products.DCWorkflow/trunk/Products/DCWorkflow/CHANGES.txt
U Products.DCWorkflow/trunk/Products/DCWorkflow/README.txt
-=-
Modified: Products.DCWorkflow/trunk/Products/DCWorkflow/CHANGES.txt
===================================================================
--- 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 Changelog
+=============================
- Products.DCWorkflow 2.2.0 (unreleased)
+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.
+
+
+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
+
+
+2.1.1-beta(2007-12/29)
+----------------------
+
+- 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:
+http://svn.zope.org/CMF/branches/2.1/HISTORY.txt?view=auto
+
Modified: Products.DCWorkflow/trunk/Products/DCWorkflow/README.txt
===================================================================
--- 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 @@
+=====================
+ 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!
+Usage
+=====
-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)"
+instance.
+
+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
+expressions.stx.
+
+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
mailing list