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!

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

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.

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

How to install?

I placed the extension, activated it, and went to http://mydomain.com/admin/role/policyedit/543 hoping to see the modified edit_attribute.tpl showing up, but none...

Using 3.9.0 with ezwebin

Thanks

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

There is a node on eZpedia on this subject, feel free to add to it!
<i>http://ezpedia.org/wiki/en/ez/attributeedit_policy</i>

//kracker

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

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

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

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.

Thanks

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.

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!!!

You can use the owner limitation (value: self) for user objects too. Also see my comment on http://issues.ez.no/9416

[Solved]
I just forgot that users are objects like any other, works like a charm...
Thanks

Hi,

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

Best regards

Hi,

I'm just testing your hack, but I found an incompatibily error while using at the same time the "Automated user placement" workflow contrib ( http://ez.no/community/contribs/w...ed_user_placement_for_ez_publish_3_8 ).

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

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!

Hi Kristof,

many thanks for your quick answer. I apologized for my mistake...as 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.

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.

Regards

JAE

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: http://pubsvn.ez.no/community/trunk/hacks/attributeedit_policy/3.9.3/.

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!!