When the security rules are simple, the sort of thing admin.yml can
handle by itself, things work fine.
However, when privileges vary from object to object, certain features
of the admin generator make implementing correct, secure behavior more
difficult than it has to be. These things would not be hard to change.
One can override save() and delete() in the model class and check the
user's privileges for that particular object at that point (for
instance, some users can only edit things they made, while admins can
edit anything - a common model for things like blog posts). If they
don't have the proper privileges, throw an exception and you're done.
This almost works, except for executeBatchDelete(), which is hardcoded
to use the delete() method at the Doctrine query level (presumably it
does something similar in Propel-land). A delete query bypasses the
delete() methods of the individual objects.
It is possible to write a short, elegant executeBatchDelete() taking
advantage of the delete() convenience method of Doctrine collections,
which *does* call delete() on each object in the collection:
// Calling delete() in the query bypasses delete() in the model class,
// which defeats our security architecture. So get the objects
$q = Doctrine_Query::create()
->from('pkBlogEvent p')
->whereIn('p.id', $ids);
$results = $q->execute();
// However Doctrine has a delete method on the collection, which
calls delete on each element
$results->delete();
Note that the admin generator posts events on delete operations, which
suggests that support for changing delete semantics was intended.
That's nice, but it doesn't do any good if it's only supported by the
single-item delete method, and batch deletes just whack the records
out of the database. (:
I suggest the above as a replacement for the current version of
executeBatchDelete. And if we're serious about posting events on
deletes, it's probably necessary also to loop over the items and send
an event for each one as well as calling delete() on it.
* * *
The second problem is limiting the display of editing and selection
controls to the items the user is allowed to edit.
It's true that if you don't want to show users things they can't edit,
which is a fairly common case, you can take care of that effectively
by extending the filter methods.
But if you want users to see, but not edit, items they can't control -
for instance, to prevent users from creating redundant, unnecessary
objects that duplicate effort already made by other uers (also a
common case) - then things are tougher.
You can override _list_td_actions.php without too much work to remove
the action links from items the user is not allowed to edit. But the
checkboxes for batch actions cannot be hidden without overriding
_list.php completely, which is unfortunate.
A _list_batch_checkbox.php partial would be easy to add, and would be
better here because we wouldn't be stuck taking the entire _list.php
partial into the application level.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
