You could be forgiven for thinking that I've not been up to much lately, after all it's a month or so since I wrote something on my blog. However that's not the case, and I have in fact been quite busy making changes here and there.
New Cakeforge Project
One of the things I have been looking at is how to better manage the content of this site, as the cost of progress is that bugs can creep into code. Some of these bugs have manifested themselves in such a way as to debilitate completely the interesting contents of this site for visitors. To ensure that there is always a version of the ACL admin plugin available to download, I have created the acl-admin cakeforge project to host the files. As such the online demo and download from this site will be a preview of changes that may appear in the cakeforge project.
Current differences
With a safe version of the code available on cakeforge, you can expect changes to the acl demo code in a rather more piecemeal manner. The next task sizable task for this plugin is to add the possibility to apply ACL to admin (routed) methods. The goal being to allow flexibility to be able to say that the user bob can access the admin functions of a plugin, without granting access to the admin functions of the whole site (or any other granular permutation desired). The code for this is still in progress, it shouldn't affect existing functionality and will just mean some links don't do anything until they are fully implemented.
Going forwards
With the birth of the cakeforge project, I will be using that as a means to mention new functionality and fixing/handling bugs. If you are using the ACL admin plugin and are finding problems or success please use the forum on the cakeforge project to let me know :).
Robert Meisner on 
Palaniappan on 
Martz on 
DamirSecki (Lion30) on 
headbiznatch on 
User Tom can edit only his post where as users Dick and Harry can edit theirs. An efficient way to define and in turn check these has to be created... I am not sure if AXOs will solve this problem. Thoughts?
1) Complicated rules (read making rules for each row in the DB)
or 2) Putting access control logic in the application itself - akin to how the Bakery does it. For clarification, I'm not saying the way the bakery handles access control is bad/wrong, but having ACL AND access control logic in the code doesn't seem the best idea.
The problem as I see it becomes a chicken and egg issue: you can't (transparently or semi-transparently) check access to a function such as edit, without some method-specific logic for testing what is going to be edited and whether or not the current user is the owner/editor. You wouldn't really want to read what was going to be edited, if the user doesn't have access. So after stating the obvious for anyone else reading ( :) ) I am not sure what solution is the best approach.
I am wondering if this can be solved making use of custom return values from the ACL system - that's something I would propose the Cake ACL system implements to permit easier conflict resolution in the case of User HABTM Groups anyway. To vaguely describe what I am meaning with regards to your question, at the moment ACL returns true or false - which is what you would want in terms of access or not of course; but if, for example, the return value for edit was 2 - that could be used to do the "only for owner" logic and if all models that had an edit method with this custom return value have the same structure ( contain user_id ) then the check for this could be built into the AC component keeping the checks transparent. What are your thoughts on conflict resolution, custom return values, and a way to answer your own question without creating 1 million rules for a model/table with 1 million rows?
Thanks for your thought provoking comment :)
There *has to be* some better and more generic method. Have there been any similar threads in the mailing list? Guess time we started picking brains of the master bakers for *best practice*