|
Author
|
Message
|
|
Jonny Bergkvist
|
Friday 21 September 2007 4:40:07 am
Hi! 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" />
</form>
Is the problem that a new content object version need new versions of all attributes to become a valid content object version? Jonny
|
|
André R.
|
Friday 21 September 2007 6:14:58 am
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..';
eZExecution::cleanExit();
}
//$dataTypeString = $dataMap[$attributeIdentifier]->attribute('data_type_string');
//$content = $dataMap[$attributeIdentifier]->attribute('content');
$dataMap[$attributeIdentifier]->setContent( $value );
$dataMap[$attributeIdentifier]->store();
// clear view cache
eZContentCacheManager::clearObjectViewCache( $objectId, true, false );
$redirectUrl = '/content/view/full/' . $contentObject->attribute('main_node_id');
return $Module->redirectTo( $redirectUrl );
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
J-A Eberhard
|
Friday 21 September 2007 6:20:19 am
Have a look at this
http://ez.no/developer/contribs/hacks/attributeedit_policy
Open Source Solution Provider
Open-Net Ltd Switzerland
http://www.open-net.ch
|
|
André R.
|
Friday 21 September 2007 8:38:28 am
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).
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Piotrek Karaś
|
Monday 05 November 2007 11:00:55 am
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?
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Piotrek Karaś
|
Sunday 25 November 2007 11:07:07 am
<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!
Piotrek
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Maurizio Betti
|
Monday 28 January 2008 2:55:02 pm
Hi,
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
Maurizio Betti
http://www.arsweb.it
http://www.hospes.it
|
|
Kristof Coomans
|
Tuesday 29 January 2008 8:50:39 am
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!
independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org
|
|
Piotrek Karaś
|
Tuesday 29 January 2008 10:51:03 am
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... ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Kristof Coomans
|
Tuesday 29 January 2008 11:21:41 am
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
independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org
|
|
Piotrek Karaś
|
Tuesday 29 January 2008 11:53:59 am
<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? ;)
Thanks,
Piotrek
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Kristof Coomans
|
Wednesday 30 January 2008 4:24:30 am
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.
independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org
|
|
Piotrek Karaś
|
Wednesday 30 January 2008 9:09:24 am
Kristof, I'm looking forward to that solution and already can't wait ;) That would make eZ Publish so much more powerful and flexible!
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
