Commit 25b1385e authored by Jens Vagelpohl's avatar Jens Vagelpohl

- 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
parent 7229df97
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.
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
- 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.
=====================
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@zope.org. Future development
depends entirely on people's needs, so speak up!
Usage
=====
Shane Hathaway
Zope Corporation
shane@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.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment