{"issue":{"title":"Acl","user":{"login":"rmsint","id":1230229,"url":"https://api.github.com/users/rmsint","avatar_url":"https://secure.gravatar.com/avatar/451f18eb7ad71135e34d425336e4840e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"451f18eb7ad71135e34d425336e4840e"},"created_at":"2011-12-19T21:28:37Z","milestone":null,"labels":[],"state":"open","updated_at":"2011-12-26T12:42:41Z","id":2606020,"closed_at":null,"html_url":"https://github.com/sonata-project/SonataAdminBundle/issues/461","pull_request":{"patch_url":"https://github.com/sonata-project/SonataAdminBundle/pull/461.patch","html_url":"https://github.com/sonata-project/SonataAdminBundle/pull/461","diff_url":"https://github.com/sonata-project/SonataAdminBundle/pull/461.diff"},"body":"Changes:\r\n\r\n- added RoleSecurity handler to be backwards compatible with previous Acl implementation + provide quick security possibility for admins\r\n- changed object ACLs: I made a mistake: each object ACL had the Admin ACL as parent, now a custom parent can be choosen. Fe. a comment object that inherits the permissions from its Post object:\r\n  - Post Object 1 ACL\r\n      - Comment Object 1 ACL\r\n- pass object to isGranted check in the controllers and templates\r\n- updated docs\r\n- for existing objects, generate the object ACLs using sonate:admin:generate-object-acl command\r\n- UserBundle:\r\n  - split user form in editable roles and readonly roles\r\n  - implement custom voter to deny access for __normal users__ to __super-admin__ users\r\n\r\nQuestions:\r\n\r\n1. checking permissions for batch delete action: where do you think this should be done? In the modelmanager or before, in the CRUDController? I think the check should filter the objects with no DELETE access granted. And if objects are filtered, add the amount of filtered messages in a flash message warning or notice.\r\n2. the code to create the object ACL is now devided between the admin class and the security handler, how to decouple this? What would be the best place for custom ACL inheritance rules? In the domain object class, in a listener, or connected to the admin (current implementation)?\r\n  - for objects created using the Admin, the \"createObjectSecurity\" method is used. It is a proxy for the security handler method and allows to customize the inheritance;\r\n  - the security handler has several helper methods used by its \"createObjectSecurity\" method;\r\n  - the __sonata:admin:generate-object-acl__ uses the security handler methods directly because of efficiency, however custom inheritance is now skipped\r\n  - objects created outside the admin do not get an object ACL, if the object ACL logic can be decoupled, perhaps a listener can be placed on the domain objects handled by an admin","number":461,"url":"https://api.github.com/repos/sonata-project/SonataAdminBundle/issues/461","comments":3,"assignee":null},"comment":{"user":{"login":"rande","id":14672,"url":"https://api.github.com/users/rande","avatar_url":"https://secure.gravatar.com/avatar/dc68b58a2a42134405a48c008598a4f2?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"dc68b58a2a42134405a48c008598a4f2"},"created_at":"2011-12-26T12:42:41Z","updated_at":"2011-12-26T12:42:41Z","id":3274324,"body":"@rmsint : do you mind writing a blog post that can be publish on sonata-project.org ? the idea is to explain the change (the benefit of it, what need to be changed, etc ...?","url":"https://api.github.com/repos/sonata-project/SonataAdminBundle/issues/comments/3274324"},"action":"created"}