eZ Community » Forums » Setup & design » Is it possible to edit only 1...

Is it possible to edit only 1 attribute of a contentobject?

Is it possible to edit only 1 attribute of a contentobject?

Friday 21 September 2007 1:40:07 pm - 12 replies


I want a user to be able to change a status-attribute quick and easy for a content-object, without going into normal edit-mode where all the attributes show up. The content object has several content attributes.

Anybody know a sensible way of doing this in eZp?

I tried with this tpl-code, but it won't work:

{def $edit_version=inc( $node.contentobject_version )}

<form name="editform" id="editform" enctype="multipart/form-data" method="post" action={concat( "content/edit/", $node.contentobject_id, "/", $edit_version, "/", "nor-NO" )|ezurl}>

{attribute_edit_gui attribute=$node.object.data_map.status}

<input type="hidden" name="ContentObjectAttribute_id[]" value="{$node.object.data_map.status.id}" />
<input class="button" type="submit" name="PublishButton" value="Publish" />


Is the problem that a new content object version need new versions of all attributes to become a valid content object version?


Friday 21 September 2007 3:14:58 pm

Doing this from php (module/view) is probably easier, as I don't know of a way to go around the normal edit workflow by just using some form variables.

include_once( 'kernel/classes/ezcontentobject.php' );
include_once( 'kernel/classes/ezcontentcachemanager.php' );

$Module = $Params['Module'];
$objectId = (int) $Params['contentobject_id'];
$attributeIdentifier = trim( $Params['attribute_identifier'] );
$value = (int) $Params['attribute_value'];

$contentObject = $objectId ? eZContentObject::fetch( $objectId ) : false;
$dataMap = $contentObject ? $contentObject->attribute('data_map') : false;

// Check if we got a object and if user has edit access to it
if ( !isset( $dataMap[$attributeIdentifier] ) or 
     !$contentObject->checkAccess('edit') )
    echo 'There was something wrong with the object, or you don\' have access to edit it..';

//$dataTypeString = $dataMap[$attributeIdentifier]->attribute('data_type_string');
//$content = $dataMap[$attributeIdentifier]->attribute('content');
$dataMap[$attributeIdentifier]->setContent( $value );

// clear view cache
eZContentCacheManager::clearObjectViewCache( $objectId, true, false );

$redirectUrl =  '/content/view/full/' . $contentObject->attribute('main_node_id');

return $Module->redirectTo( $redirectUrl );

Modified on Friday 21 September 2007 3:16:00 pm by André R

Friday 21 September 2007 3:20:19 pm

Have a look at this

Friday 21 September 2007 5:38:28 pm

I don't think he want to restrict permission on attribute level, but edit one attribute quick and easy whithout having to go true the full eZ Publish edit workflow (versions and so on).

Monday 05 November 2007 8:00:55 pm

What's the policy under eZ Publish 4.0?

As far as I remember, in 3.x I had to operate on the complete set of object attributes in order to change values of just few of them (without hacks). Today we tried similar scenario (eZ 4.0alpha2) and to our surprise a new object version was created after only editing one object attribute (the rest kept their former values).

Is that how it is supposed to work? I'd say, it would as convenient as potentially dangerous if there is no way to limit edit access based on attributes... Am I right?

Where can I find out what is the intentional behavior for versions 3.8-4.0?

Sunday 25 November 2007 8:07:07 pm

<b>I would be grateful if an experienced member of the community or eZ Crew could relate somehow to my questions...</b> I wouldn't like to have to draw final conclusions from code analysis at this level, and it seems like a key thing to know whether one should always edit complete set of content object's attributes or not, especially in light of <b>eZ Publish 4.0</b> testing...

Thanks in advance!

Monday 28 January 2008 11:55:02 pm


I had a similar problem and I just posted my simple workaround extension for this:
see http://ez.no/developer/contribs/hacks/dynamic_modify_attribute_value

Tuesday 29 January 2008 5:50:39 pm

Piotrek, what exactly do you mean with "operate on the complete set of object attributes in order to change values of just few of them" ? Can you clarify yourself? Thanks!

Tuesday 29 January 2008 7:51:03 pm

Yes, I'm sorry, that wasn't precise. By <b>complete set</b> I meant <b>all attributes belonging to a content object of given content class</b>.

Since my last post, we have found out that we might had been wrong about some assumptions regarding this issue. It might be, that the behavior between 3.x and 4.0 hasn't changed that much after all.

Still, it would be of great value to have a descriptive documentation of what is the intended behavior/good practice. Content object attribute seems the smallest possible entity that you can play with, you have attribute-focused functions in the template language (for example attribute_edit_gui), you have edit templates that are iterations around that function, which means you can easily modify them. It should be very clear: you're (not) allowed to edit content object by editing just one of its five attributes and why and how datatypes affect that.

I'm way into reading attribute_edit.php and contentobject class, so maybe in a few days I'll know the rule... blunk.gif Emoticon

Modified on Tuesday 29 January 2008 8:38:53 pm by Piotr Karaś

Tuesday 29 January 2008 8:21:41 pm

You can remove some attribute edit fields from content/edit, indeed, but of course this is not a safe solution in case you want to use it to to disallow a user from changing certain attributes. If you want a safe solution, use this hack then: http://ez.no/developer/contribs/hacks/attributeedit_policy

Tuesday 29 January 2008 8:53:59 pm

<i>You can remove some attribute edit fields from content/edit, indeed, but of course this is not a safe solution in case you want to use it to to disallow a user from changing certain attributes.</i>
Indeed, but disallowing to edit is not the only reason for hiding an attribute, especially with custom datatype-based ones.

<i>If you want a safe solution, use this hack then...</i>
Thanks. I might have already taken a look, or maybe it was something similar. Do you plan to make it work with 4.x? Also, maybe the kernel class override 'feature' in 4.0 could prevent direct kernel modification?

Yet, that's the point. When you want to use eZ Publish for a more advanced purpose than just storing content which a user can entirely access or not, this becomes much of an issue. Does eZ plan to incorporate some sort of attribute-level policy as an out-of-the-box feature? If it is a matter of a four file hack, why wouldn't you? blunk.gif Emoticon


Modified on Tuesday 29 January 2008 8:55:06 pm by Piotr Karaś

Wednesday 30 January 2008 1:24:30 pm

Hi Piotrek

In its current state, the attribute-edit policy hack is not very comfortable what concerns the assignment of policies to roles. As far as I remember, you need to add both content/edit and content/edit_attribute before you're able to edit attributes. However, I have a possible solution for this in the back of my head and will try to get some time to implement it.

Wednesday 30 January 2008 6:09:24 pm

Kristof, I'm looking forward to that solution and already can't wait blunk.gif Emoticon That would make eZ Publish so much more powerful and flexible!


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

36 542 Users on board!

Forums menu

Proudly Developed with from