Planning a CustomCheck policy limitation hack
December 25th, 2005
I’ve already gathered some experience in hacking the role system of eZ publish by writing the ParentDepth create policy limitation. Now I’m planning to write a similar hack to add limitations to the content/create and content/edit policies. I will call it CustomCheck.
Developers will be able to add their own custom functions (or class functions) to the CustomCheck limitation list by modifying some settings in an INI file. The arguments passed to the custom function will be the content object id, and in some cases also the node id. In the custom function you are free to do whatever you want. To give some examples:
- you can check the value of an attribute of the content object
- you can check the value of an attribute of the current user
- you can find out if the content object’s owner is in the same group as the current user
If you know which limitations for content/create and content/edit are currently possible, you will understand that the CustomCheck limitation will add a lot of flexibility and precision. The practice of hiding edit buttons in some specific cases will belong to the past. At last {if $node.can_edit} will do the whole job for you.
Targets of the CustomCheck hack are the latest releases of the 3.6 & 3.7 eZ publish branches. As soon as the code is in a usable state, I will add it to the contributions on ez.no.
Entry Filed under: eZ Publish
4 Comments Add your own
1. Paul Borgermans | December 26th, 2005 at 2:00 pm
This is a very useful idea and project! It will bring eZ publish more to the enterprise level too.
Keep on coding Kristof
Paul
2. xavier | December 28th, 2005 at 9:58 am
Nice idea.
On the content/edit and content/add, would it be possible with your system to based that on users or groups as related objects ?
What I have in mind is to add a “Pal” attribute as enhancedobjectrelation with a checkable list of users. If I write an article and check Kristof and Paul, you both would be able to modify the article, but Gabriel couldn’t.
Does it make sense ?
Also, would it be possible to use your attribute to set the read right. Same idea, I check Kristof and Paul so you can read the article, but the others can’t.
X+
(Nothing personal Gabriel
3. Administrator | December 28th, 2005 at 10:29 am
Hi Xavier
It would be possible to base content/edit and content/create policies on related objects.
Setting the read rights is another case. I’m afraid this isn’t possible with the hack I had in mind. The read rights are honored by adding additional conditions to the SQL queries in eZContentObjectTreeNode::subTree. See eZContentObjectTreeNode::createPermissionCheckingSQLString. Of course it would be great if you could also use custom checks for content/read, but I’m afrad the possibilities will be very limited because it has to be done with SQL.
4. Gabriel | December 28th, 2005 at 11:30 am
If Kristof does the hack with a somewhat sane interface and I can find the time, I will do something along the lines of groups with related objects for my datatype, I think.
As for read rights: Maybe, just maybe (not sure if different parts in ez might use it directly), one could wrap the SQL stuff in a PHP function and have CustomCheck just overrides this at the end?
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