Wichert Akkerman wrote:
> I have a use case where I need to put additional restrictions on object
> creation, in particular I need to restrict the maximum depth of items
> inside of a container of a specific type. The ideal place to put such a
> restriction seems to be the isConstructionAllowed method on the FTI.
> Currently this method is not very extensible, which leads to complicated
> code in various FTI types.
> I am considering to add an extension point here, something like this:
> class ITypeConstructionFilter(Interface):
> def __init__(fti, container):
> """Adapt on the FTI of the object being created and the target
> def allowed():
> """Check if construction is allowed."""
> current checks such as the workflow check that was added in CMF 2.2, or
> the type constraint logic Plone has in ATContentTypes could be moved to
> such an adapter. The standard isConstructionAllowed method could then
> query all registered adapters to check if construction should be possible.
> Does this sound sensible?
After (re)reading all the comments and having a closer look at the code
I came to these conclusions:
1.) CMF 2.1 checks two different restrictions: allowType() and
isConstructionAllowed(). PortalFolderBase._verifyObjectPaste just checks
allowType() because in CMF 2.1 isConstructionAllowed() does basically
the same permission check as CopyContainer._verifyObjectPaste. Changing
isConstructionAllowed() without changing
PortalFolderBase._verifyObjectPaste creates inconsistent behavior. The
_checkWorkflowAllowed change and your branch are both broken.
2.) The distinction between allowType() and isConstructionAllowed() was
clear in CMF 2.1: allowType() checked a cheap, not permission related
CMF specific restriction. isConstructionAllowed() checked generic
permission related restictions. The new restrictions
_checkWorkflowAllowed and ITypeConstructionFilter don't fit in one of
these two categories.
3.) I was wrong about comparing isConstructionAllowed with checkFactory
and checkObject. These are used for checking general container
constraints, not for checking user specific permissions. checkFactory
doesn't work for CMF because it doesn't take the portal type as argument.
allowType() and isConstructionAllowed() are both the wrong place for
checking additional restrictions. But allowType() could become part of a
more general precondition that could be checked by checkObject and a new
checkPortalType (=CMF specific checkFactory) function.
Plone could use its own precondition that checks registered
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests