Path

ez projects / attributeedit_policy


AttributeEdit policy

UNIX name Owner Status Version Compatible with
attributeedit_policy Kristof Coomans planning 0.3 3.7.5, trunk - 3.9

Define edit permissions on attribute level.

If you don't want to let the current user change specific attributes of
a content object, then you hide the edit controls for those
attributes, e.g. the "Sticky" flag for forum topics. This solution is
not secure, because the input for the attribute will still be
processed. If the user knows which variables he has to post, then he
can still manipulate the attribute.
This hack introduces a new policy: content/attributeedit. With this
policy, you can define which attributes are editable, in a secure
way.
This policy function currently has three limitations:
- Class: select classes (to make all their attributes editable)
- Attribute: select specific class attributes
- Owner: any or self
The trunk has these extra function limitations:
- Language
- ObjectStatus: Draft or Published
Avoid to use Class and Attribute limitations in the same policy, because
they could neutralize each other, e.g. when you select Class 'Folder'
and Attribute 'File/Name' then this policy never will be
allowed.
You still need a policy content/edit to edit an object. Make sure you
have a policy content/attributeedit for each class that can be
edited, otherwise you can edit the object but not any attributes of
the object (and that's pretty useless I think).
At the moment, only a replacement for content/attribute_edit.tpl for
the admin interface is provided. But you can easily check in your own
templates if an object attribute is editable:
{if $attribute.can_edit}
...
{/if}
Please use this forum topic for discussion/bug reports/comments: .

 

Screenshot

This project has no reviews yet. Be the first one to review it!

No forum messages yet.