ilrt.formalworkflow / PKG-INFO

Metadata-Version: 1.0
Name: ilrt.formalworkflow
Version: 1.8
Summary: Formal workflow is designed to prevent editing, deletion or reversion of published content from skipping review
Home-page: http://bitbucket.org/edcrewe/ilrt.formalworkflow
Author: Internet Development, ILRT, University of Bristol
Author-email: internet-development@bris.ac.uk
License: GPL
Description: ILRT Formal Workflow
        ====================
        
        Overview
        --------
        
        Ed Crewe, `ILRT
        <http://www.ilrt.bris.ac.uk/>`_ at University of Bristol, September 2nd 2010
        
        NOTE: Updated from plone 3.* version 0.6 to plone 4.* compatible version 1.6
        There are no functional changes between 0.6 and 1.6, just a skins install 
        tweak and update of the test suite. 
        
        See http://bitbucket.org/edcrewe/ilrt.formalworkflow for mecurial source 
        repository, issue tracker etc.
        
        Formal workflow is designed for sites where there may be many editors
        for whom unmoderated access to change live published content on the 
        web site is not desired. A typical scenario may be an organistaion's 
        public website which has to comply with certain legal restrictions or
        editorial style for example. To ensure this compliance only a limited
        subset of editors are trusted to review and publish content.
        Whilst content in the private state is available to all editors.
        
        This package applies a workflow definition based on simple publication 
        workflow ... but it ensures that editors cannot modify public content.
        Instead it enables `plone.app.iterate`_  with which users can check out a 
        working copy of a published item to work on and resubmit for review.
        
        .. _`plone.app.iterate`: http://pypi.python.org/pypi/plone.app.iterate
        
        Editors and owners are also restricted from deleting published items or 
        reverting them to past versions, essentially anything that could change 
        published content, without review.
        
        Workflow
        --------
        
        A diagram of the workflow is available in /docs folder   
        
        .. image:: http://mail.ilrt.bris.ac.uk/~cmetc/images/formalworkflow.png
        
        The following walks through a user story::
        
          Editor
          - An editor creates a document
          - They edit and then submit it for review
          - It is now in the pending state
        
          Reviewer
          - The document appears for review in their review list so they click on it
          - They make a few minor ammendments and publish it
        
          Editor
          - A week later some more information needs to be added to the document
          - The editor goes to it, but it there is no workflow menu just 
            State:Published so they cannot retract it. The edit and history tabs
            are also gone. So instead they must click on 'Make changes' from the actions menu.
          - This locks the item and marks it as being edited in a working copy.
          - The editor does their edits then clicks on submit to bring their changes to the
            attention of the reviewer
        
          Reviewer
          - The reviewer sees the page pop up in their review list
          - They click on it and look at the changes the editor has made. 
            They like the changes but decide they want some modifications made to them
            by the editor. They dont want to 'Cancel changes' since the editor has done a
            lot of changes, so they just add a note of the further changes needed and make
            the working copy private again.
        
          Editor
          - The editor reads the comment and re-edits the working copy, once these final changes
            are complete is it resubmitted to the pending state. 
        
          Reviewer
          - The reviewer notices the item is back again in their review list, so realises 
            it has been re-edited.
            They click on it ... see that it is ready and so do the 'Accept changes' to replace 
            the current published version, at which point the working copy is removed.
        
        Notes
        -----
        
        This package is really all just xml config data and reworking skin copy, paste
        and delete security to be object specific rather than folder based.
        However though it contains little python aside from the functional tests, 
        it is a commonly required workflow which does require some time consuming 
        configuration tweaks.
        
        If this workflow is applied in conjunction with a theme egg then the formalworkflow
        skin should be added near the top of the editing layer's skins listing in the 
        portal_skins tool.
        
        If this workflow is applied to an existing site you may require the 
        `ilrt.migrationtool 
        <http://pypi.python.org/pypi/ilrt.migrationtool>`_ to use its utility for mapping  
        existing content states from one workflow to another. Otherwise changing 
        workflow reverts objects to the new workflow's default state.
        
        If you wish to use custom types with this workflow you will need to make them versionable 
        via the 
        `portal_repository tool
        <http://plone.org/documentation/how-to/enabling-versioning-on-your-custom-content-types>`_ or 
        plone.app.iterate will not be available for them. 
        
        If formal workflow is applied to folders (as is the default profile setting) then types 
        without workflow such as images and files cannot be added or deleted by editors.  
        To fix this a slightly adapted version of one_state_workflow is also included for these 
        content types that allows for editors to modify this content unrestricted. 
        
        You can customize which types use formal_worflow, and hence enforce a review process, 
        via the the portal_workflow tool. You could also choose to only apply formal workflow 
        to the high profile parts of your site, via `placeful workflow
        <http://pypi.python.org/pypi/Products.CMFPlacefulWorkflow>`_.
        
        If you dont want users questioned over the location for their checkouts then you can
        specify a checkout locator globally in the site properties. Currently this would be
        global_checkout_locator = 'plone.app.iterate.home' or 'plone.app.iterate.parent'
        If not set then the default behaviour is used.
        
        
        Changelog for ilrt.formalworkflow
        ---------------------------------
        
        ilrt.formalworkflow - 1.7 Released - 1st December 2011
        
           - Modify configure zcml for cmf permissions compatibility with plone 4.1
           - Add some standard content rule email notifiers related to workflow actions
           - Add ContentPanels to workflow configuration
           - Fix some deprecated syntax in tests 
        
           Changes funded by the University of the Highlands and Islands - John McAlpine & Jane Fitzpatrick
        
           [Ed Crewe, R&D - University of Bristol] 
        
        ilrt.formalworkflow - 1.7 Released - 29th September 2011
        
            - Some files missing from the egg
        
           [Ed Crewe, R&D - University of Bristol] 
        
        ilrt.formalworkflow - 1.6 Released - 2nd September 2010
        
            - Tested against plone 4.0 - fixed tests for new default plone skin
            - Modified skin setup to add formalworkflow layer to the two plone skins not create its own
        
            [Ed Crewe, ILRT - University of Bristol]
        
        ilrt.formalworkflow - 0.6 Released - 10th September 2009
        
            - Tested against plone 3.3 - fixed tests
            - Added option to globally set check out location in site properties.
        
            [Ed Crewe, ILRT - University of Bristol]
        
        ilrt.formalworkflow - 0.5 Released - 10th June 2009
        
            - Added a subclass of the iterate info viewlet to redeclare the security so that 
              editors can see it and find existing checkouts.
        
            [Dave Mote, Washtenaw County Government]
        
        ilrt.formalworkflow - 0.4 Released - 20th May 2009
        
            - Added an adapted version of one_state_workflow to allow editors to add 
              and delete images and files. Since the default formalworkflow profile adds 
              formal_workflow to folders - blocking editor modification of unworkflowed types.
        
            [Ed Crewe, ILRT - University of Bristol]
        
        ilrt.formalworkflow - 0.3 Released - 5th April 2009
        
            - Changed action names and templates to be less versioning orientated
              Now uses Make changes, Accept changes and Cancel changes
            - Fixed folder permissions checks blocking delete, copy and paste of objects
              in published folders for editors
            - Cleaned up permissions
            - Removed unnecessary formalworkflow layer
        
            [Ed Crewe, ILRT - University of Bristol]
        
        ilrt.formalworkflow - 0.2 Released - 20th Jan 2009
        
            - Released to pypi with some documentation
        
            [Ed Crewe, ILRT - University of Bristol]
        
        ilrt.formalworkflow - 0.1 Unreleased
        
            - Initial package structure.
        
            [zopeskel]
        
        
        To Do list
        ----------
        
        #. Find a better way to allow permissions of objects to be used rather 
           than those of their containers for delete, copy and paste.
           Currently it uses a workaround that needs proxy manager then does a
           manual permission check, within the skins.
        
        
        
        
Keywords: web zope plone workflow
Platform: UNKNOWN
Classifier: Programming Language :: Python
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Environment :: Web Environment
Classifier: Framework :: Plone
Classifier: Framework :: Zope2
Classifier: Framework :: Zope3
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Other Audience
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
Classifier: Development Status :: 5 - Production/Stable
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.