This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Developer » attributeedit policy

attributeedit policy

attributeedit policy

Tuesday 11 April 2006 11:12:48 am - 30 replies

Hi guys

I've made a hack to limit the editing of content objects to specific attributes.

You can download the modified files for eZ publish 3.7.5 at

You can now use a new policy content/attributeedit with limitations to full classes or specific attributes. You still need the content/edit policy to edit an object.

Note: only modified template for content/edit_attribute.tpl of the admin interface is provided.

Please test it and let me know what you think about it. Have fun!

Modified on Thursday 13 April 2006 4:13:09 pm by Kristof Coomans

Friday 14 April 2006 5:49:30 pm

This is quite possibly the single most useful hack ever (and something that really SHOULD live in core).

In my limited testing it worked perfectly. Thanks a lot for sharing this!

Friday 14 April 2006 6:28:53 pm

I think this is great. An already expected policy.
I haven't used this but.....How about integrate in ez trunk ?

Sunday 16 April 2006 10:36:55 am

I'll try to make a patch for the trunk this week and send a mail to the sdk mailinglist to see if it can make it's way into the official trunk.

I also had some extra policy function limitations in mind:

- ObjectStatus: Draft (e.g. when the attribute can be filled in once but can never be changed), Published
- ClassGroup (maybe I'll patch the other content policies too)

- Section (like content/read)
- Subtrees (like content/read)
- Nodes (like content/read)

If you know any other useful limitation, please let me know.

Tuesday 18 April 2006 11:23:10 am

The modified files for the trunk were added together with limitations for objectStatus and Language.

Sunday 28 January 2007 11:54:42 am

How to install?

I placed the extension, activated it, and went to hoping to see the modified edit_attribute.tpl showing up, but none...

Using 3.9.0 with ezwebin


Sunday 28 January 2007 1:04:58 pm

This is not an extension. You need to replace the kernel files.

Sunday 28 January 2007 2:48:43 pm

There is a node on eZpedia on this subject, feel free to add to it!


<i>The outro, thebroken--0004--ep4 @ 19:26</i>

Modified on Sunday 28 January 2007 2:50:24 pm by // kracker

Tuesday 20 February 2007 9:29:02 pm

Fixed in rev 1487 : The function fetchInput did not protect from value input or malicious post :

if ( $fetchInput == true &&
$contentObjectAttribute->canEdit() !== 1 )
$fetchInput == false;

Changed "$fetchInput == false;" by "$fetchInput = false;" (only one equal sign) ,
then user inputs or posted values are really discarded.

Modified on Tuesday 20 February 2007 9:41:49 pm by Yves B

Tuesday 13 March 2007 9:01:10 am

Hi Kristof,

I Love the this extzension and would like to uses it in the context of User > Selfedit.
I would like to control, attribute by attribute, what a user can edit about himself

Could you give me some hints how I could achieve it.


Tuesday 13 March 2007 5:27:20 pm

Hi J-A

I think you can use it the same way as you do for other types of content objects, though I haven't tested this.

Tuesday 13 March 2007 9:23:35 pm

What I would like to have is the possibility to allow the user to edit specific attributes of it's own profile, then to link them to a validation workflow.

If I use the 'selfedit' policy of the 'user' module, the user can edit all it's attributes.
I can choose to display only some attributes in the template, but it's not a very secure solution.

If I use your policy under the 'content' module, I can specify which attributes can be edited but I cannot define a 'selfedit' policy (as the user is not the owner of it's object).

What I'm searching is to know how to hack your contrib to have it working under the selfedit policy of the user module.

Like that, If a user change one of it's field, I can launched a validation workflow and your placeusers to securely let the users select their own rights on eZ publish.

Thanks to let me know your feeling, easy, hard or wrong way to do it!!!

Wednesday 14 March 2007 7:52:38 am

You can use the owner limitation (value: self) for user objects too. Also see my comment on

Thursday 15 March 2007 5:06:17 pm

I just forgot that users are objects like any other, works like a charm...

Saturday 28 April 2007 4:18:31 pm


compliments for this wonderful hack! It Hope it will soon included in standard distribution.

Best regards

Saturday 28 April 2007 4:51:31 pm


I'm just testing your hack, but I found an incompatibily error while using at the same time the "Automated user placement" workflow contrib ( ).

In detail, when I overwrite the php file under kernel/content/classes, and try to create new user from public site (with "Automated user placement" active), the system creates a void user (without name, surname, accont data, etc...).

Any idea to fix it?

I'm currently runs with eZ3.9.1 and php4.4

Any suggestion will be very appreciated.

Modified on Saturday 28 April 2007 4:53:18 pm by Maurizio Betti

Sunday 29 April 2007 11:01:24 am

Hi Maurizio

Are you sure this has something to do with the automated user placement workflow event? Did you put your workflow on the post-publish trigger? Please disable the workflow event and let us know if the problem is still there.

Can you give me a detailed list of the policies you assigned to the anonymous user? Maybe the user doesn't have permission to modify the attributes of the user object (like the user account attribute) and the template used for user/register hasn't been modified to take this into account. Use $attribute.can_edit in your template code to check if edit is allowed for a specific object attribute $attribute.

Good luck!

Sunday 29 April 2007 1:38:50 pm

Hi Kristof,

many thanks for your quick answer. I apologized for my your suggestion I didn't assigned to anonymous user the permission to modify the attributes of the user object.

Now everything seems goes right.

Thank you again.

Thursday 23 August 2007 11:27:09 pm

Hi Kristof,

I had you code running in an 3.9.2 version.
I did an upgrade to 3.9.3 and it's looking like that the function name (attributeedit) is not passed to the permission system. All edit screen have an error with
Module = content
Function =

I downgraded it to 3.9.2 and it's working again.



Friday 24 August 2007 10:06:02 am

Hi J-A

It seems to work here. Are you sure you added all required changes?

For your convenience, I've committed the patched files of 3.9.3 to svn:

Saturday 25 August 2007 9:56:10 pm

Hi Kristof,

I did the same operation again, with your new svn files, and it worked.
Did I missed something the first time, is there a tiny difference between both set of files? I may never know...
Thanks for the contrib anyway, pretty usefull and I hope to see it committed to the 3.10!!


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from