[Zope3-dev] Workflow Usecase

[Tres Seaver]

On Mon, 2002-05-06 at 09:39, Casey Duncan wrote:
> Since Zope3 has inherently, the concept of denying a particular permission on 
> an object for a particular principal, so this should be more straightforward.
> 
> However, you could accomplish almost the same thing in Zope2 by turning off 
> acquisition for a particular permission (Delete objects in this case), so 
> long as the permission was not set explicitly on that object for any of that 
> user's roles. In general most content acquires all their permissions from 
> their parent folder, so this isn't much of an issue.
> 
> On Monday 06 May 2002 04:54 am, Chris Withers allegedly wrote:
>
> > I thought I'd throw this one out for you guys to think about.
> > 
> > I have some CMF content which I don't want the author to be able to
> > delete when its in a certain workflow state. Of course, they need to
> > be able to delete other stuff in the same folder.
> > 
> > I can see no way of doing this other than a hack in folder_delete to
> > check if the user has the 'Delete objects' permission on the object
> > itself, rather than just the folder.
> > 
> > It would be great if Zope 3 solved this in a nice graceful way :-)

"Delete" is the wrong name for this operation, actually, especially
in Zope 3, where objects may be bound by multiple IDs, and into multiple
containers.  "Remove" is the right name, because it makes clear the
semantics:  it is an operation on the *container*, not on the object.
(The fact that in Zope 2 removal is nearly always followed by deletion
is an accidental side-effect).

An appropriate implementation would need to provide ways to express
policies controlling the "folder" operations (add, clone, rename,
remove) using metadata from the "content" object.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com