PVS For Plone 2 (0.1.3)
- PVS For Plone 2 download link: http://plone.org/products/pvs-for-plone-2/releases
- Homepage of PVS For Plone 2: http://plone.org/products/pvs-for-plone-2
- Description source: http://www.emergence.com/WhatWeOffer/products/PVS
Our solution was to extend the
workflow mechanism with versioning capabilities. The basic idea is to
let low-level (or mid-level) users make their changes to a copy of the
published object, while leaving the original published version
untouched. When the new version is approved and
published, it takes
the place of the previously published version. This allows a "quiet"
workflow to take place behind the published version, without the need
to retract it.
This product introduces a new permission, 'Create
version'. Users with this permission can still bring up the edit form
of an object even though they do not have the permission to modify it
(such as in 'published' or 'pending' state). When the edit form is
submitted, the changes are not saved to the original object, but saved
to a new copy instead, created transparently by this product.
This
copy is a new version of the original object, and will go through the
same publishing workflow process as the original. When the new version
is approved and published, the system will again transparently replace
the original object with the new version.
This product also
extends CMF objects with version management functionality, providing a
complete versioning service. Users can see the evolution of a certain
object, and Manager/Reviewer users can republish a previous version at
any time. Further, anyone who can see the previous versions can choose
to create a new version based on any of the old ones.
The
product should work right out of the box, and by default, allow owners
to create versions. It also works on most non-folderish content types.
Developers
familiar with workflow creation will find this product helpful for
creating some interesting workflows, such as the one we developed for a
government agency to preserve the paper trails of their documents.
However, the following should be kept in mind during workflow
development:
- All versions, other than the one with the original id, are hidden
from the 'folder contents' view, the ZMI and so on. Users can delete or
move an object without the fear of leaving hidden versions dangling
behind; but when copying, only the 'published' (or 'curent') version is
copied.
- The system will not create versions for folder-like objects.
- When the system creates a new version, the system will set the
current user as the owner, so it's possible to let users of different
roles join the editing process.
- It expects that the object's associated workflow has a defined transition called 'publish'.
- As a published object being replaced by another version, the
system will first look for a transition called 'archive' in the
object's workflow definition, and perform that transition. If no such
transition is found, it will put the object into the default state.
- It expects the script which performs the actual save action to be a a python script, whose id ends with '_edit'.
- The 'Modify content' permission overrides 'Create versions' permission. So if a user has both 'modify content' permission and 'create versions' permission over an object, no versioning feature is provided.