Previously yuppie wrote:
> 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.

That sounds like there is some opportunity for code sharing there.

> 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.

Is there a reason that the two have to be separate? What is the downside
of one call that does all necessary checks?

> 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.


> My conclusion:
> 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.

How do you see this working? If it's simple enough I might have enough
time to work on it this week.


Wichert Akkerman <>    It is simple to make things.                   It is hard to make things simple.
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to