[Zope3-dev] Workflow Usecase

Casey Duncan casey@zope.com
Tue, 7 May 2002 09:26:08 -0400


On Tuesday 07 May 2002 04:15 am, Chris Withers allegedly wrote:
> Casey Duncan wrote:
> >=20
> > However, you could accomplish almost the same thing in Zope2 by turni=
ng=20
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=20
that
> > user's roles. In general most content acquires all their permissions =
from
> > their parent folder, so this isn't much of an issue.
>=20
> You're missing the point ;-)
>=20
> In Zope 2, you can only control whether _any_ object can be deleted by=20
manipulating the
> 'Delete Objects' permission on the object's container.
>=20
> I want to be able to control whether a _specific_ object can be deleted=
=2E

Well, as I think Tres already said, deletion is an operation done by a=20
container (just like creation). What you can do, though is abstract this=20
functionality in some way so that some application defined flag affects t=
he=20
behavior on a per object basis, and/or hook manage_beforeDelete on the=20
object(s) to raise an exception when the object should not be deleted.

I suppose a neater solution would be to have the container consult the ob=
ject=20
before removing it. This could involve calling a hook like "isRemovable"=20
which would return true if the object deemed that it could be removed. Th=
is=20
could be part of one of the base OFS interfaces for any object that can b=
e=20
contained in a folder. Alternately, the container could just check permis=
sion=20
settings on the object before removing it. This would be simpler if less=20
flexible.

-Casey