First version of the CustomCheck policy limitation hack
December 28th, 2005
At Christmas day, I’ve announced that I was planning to hack the eZ publish kernel to allow the use of custom functions for policy limitations. Today I’ve committed an initial version of this hack to the community SVN repository. Please checkout your copy from http://pubsvn.ez.no/community/trunk/hacks/customcheck/ and test it.
The patches directory contains patch files for eZ publish 3.6.4 and 3.7.2. For your convenience I’ve also included the full files with the necessary changes.
The extension directory contains the customchecktest extension. This extension only contains an example class function you can use. The function will check if the content object’s name is “Test”.
First enable the customchecktest extension. Then assign a role with a policy
- content/create CustomCheck( name is Test ) or
- content/edit CustomCheck( name is Test )
to a user.
Then login with that user account and try to
- create a new child under a node called “Test” or
- try to edit a node called “Test”.
Bug reports are welcome as comments on this article. Also feel free to dig into the code yourself and to submit your corrections or enhancements back to the repository. Have fun! 
I will add the CustomCheck hack to the contributions at ez.no as soon as it has been tested thoroughly.
Entry Filed under: eZ Publish
10 Comments Add your own
1. Paul Borgermans | December 28th, 2005 at 3:01 pm
Wow, great work Kristof!
To implement custom policies for read access, the fetch functions can be additionally modified to loop over the result array and call checkaccess (‘read’) for each node/object. Or even leave that to a slower implementation in the templates with a {if $node.object.can_read} and proper cache blocks.
A programmers tale: spending holiday time on cool coding projects
)
2. Gabriel | December 28th, 2005 at 4:22 pm
Can’t we just modify eZContentObjectTreeNode::canRead() for the read permissions? it seems like only a very few functions inside the core actually call the SQL permission stuff. All others seem to make use of the wrappers like they should.
3. Administrator | December 28th, 2005 at 5:59 pm
After almost three weeks of holiday, my fingers started to tingle
I will have a look at the read policy tomorrow.
4. Gabriel | December 28th, 2005 at 6:02 pm
Addicted to coding. It takes longer than a week for me, but occasionally it even happens to me.
5. Paul Borgermans | December 28th, 2005 at 10:21 pm
Or play guitar
… helps with coding (or other mental issues) as well 
6. Administrator | December 29th, 2005 at 11:41 am
I’ve committed a hack for the content/read and content/remove policy to SVN.
The hack for content/read currently won’t have any effect on the subTree and subTreeCount functions of eZContentObjectTreeNode. These functions include the limitations in the SQL queries.
The hack for content/remove won’t have any effect on the authorization to remove a subtree. Even if you are not allowed to remove one of the children because of the CustomCheck limitation, removal of the subtree will be allowed. The check on the children is done with the function subTreeCount of eZContentObjectTreeNode. So it’s the same problem as with the hack for the content/read policy.
As Gabriel mentioned in a comment on an earlier article, we maybe can use another PHP function to return additional SQL conditions. Then I would prefer to only allow classes for the custom check, and let these classes implement an interface with two functions: one for the check on the contentobject and/or node, and one that returns the SQL.
Writing limitations in SQL will of course limit the possibilities.
7. Paul Borgermans | December 29th, 2005 at 1:02 pm
“Writing limitations in SQL will of course limit the possibilities”
I would go for a mixed approach where the class interface indicates the method to use: either SQL, or forcing a loop which calls the check (I know, can be time consuming, but we should try it imho with some caching of node/objectid and currentuserid)
8. Administrator | December 30th, 2005 at 9:32 am
The subTree function will not pose any problems if we go for the mixed approach. But the query constructed by the subTreeCount function will need some facelifting. Now the query always begins with
SELECT count(*) as count FROM ..., but we will need at least a node id when a CustomCheck without additional SQL conditions is used.With some caching of node access rights, I think the mixed approach is possible.
9. Kristof | January 15th, 2006 at 12:04 pm
We should test if there are cases when view caching doesn’t work correctly because of this hack.
10. Kristof | January 16th, 2006 at 7:15 pm
A hack for the view cache will be necessary. The only stuff related to policies that the view cache uses for uniqueness are the id’s of roles and the role assignment limitations.
Actually, view caching can be considered quite buggy since a long time, see bug 2499.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed