Hello,
I think there is already a ACL in development, which covers your requirements. With Joomla 1.5, the table structure in the DB for the ACL is already available and it is very powerful to define anything as wished.
The Problem so far, the Rules for the ACL Check in Joomla are mainly fixed definied in PHP and I also have used this for my developments, because the DB acl tables is not yet really used.
My suggestion
1. Joomla ACL Specification
We need a specification or better definition how developers can restrict commen situations. If we have no common way, it could be really cost a lot of work for all developers.
1. How to restrict general "Read, Write, Change" operations for extensions
If general "Read" is not allowded, the component should be completely unselectable or hidden by the
Joomla Framework itself and not by the extension developer! This allows to give access to the Administration Page for all people using the neccessary rights and also hide elements for such as Managers.
2. How to restrict "Read, Write, Change" operations for different entity elements in a extension.
As Example, my CV Tool Component has following Entities: CV, Skill, Skill Category.
3. How to restrict "tasks" & "view" operations
Allows an overall operation in a component. If not rule is definied, it should be allowded! If the extension is developed right, it should be sufficent using the restriction options before!
4. How to define generic rules for entries of an entity. As Example, the individual "contact" of the entity "contact".
2. Framework Extension
There is already a
JUser::authorize() Method. This method is powerful, but also a little bit confusing for not so well informed developers. It took me some time to understand it myself!
According to my listing, we probably need following additional methods, which indirectly call the authorize method
JUser::authorizeExtension($extension = $mainframe->scope, $userid = [currentUser])
Example
$authorization = JUser::authorizeExtension("com_media", $userid)
This method is always called by the Joomla Framework, if the extension should be shown on the current page. It can be also called by extensions!
JUser::authorizeEntity($entiy, $extension = $mainframe->scope, $userid = [currentUser])
Example
$authorization = JUser::authorizeEntity("category", $userid)
Return value depends on rule definition. In my case, I want a list of "categories", but dependend on the ACL, I can see only my "own" or "all".
if( $authorization == 'own')
{
<handling for own entities>
}
if( $authorization == 'all')
{
<handling for own entities>
}
The optional $userid is provided to simulate the access rights for a specific user if it differs to the current loggedin user. If the $extension is not explicit setted, the $mainframe->scope value will be used.
3. Installation procedure changes
Allow Extensions to define ACL Rules in the Install XML file or in a separated ACL.xml file, which will be evaluated during the install process. If the ACL definition clashes with existing entries, the installation fails. It should be not possible, that a installation overwrites or changes existing rules for other joomla parts!
If a extension is uninstalled, the ACL should be set to "inactive". This needs a editional column, that allows to set a flag! This is imporant for the generic rules for individual entries or in other words, we don't want to loose or timeconsuming work if we only reinstall or update exentsions.
Those changes do not require a change for existing extensions - if nothing is definied for ACL, only the general ACL extension check rule will dynamicly generated and check by the framework.
ACL XML suggestion
<acl-definition section="com_media">
<aro type="entity" value"article">
<axo type="users" value="Administrator" recursive="asc" result="all"/>
<axo type="users" value="Administrator" recursive="dsc" result="own"/>
</aro>
<aro type="entry" value"article-entry">
<axo type="users" value="{owner}" result="write" readonly="true"/>
<axo type="users" value="Registered" recursive="asc" result="read"/>
<axo type="users" value="Ower" recursive="dsc" result="write"/>
<axo type="users" value="Editor" recursive="dsc" result="change"/>
</aro>
</acl-definition>
Rules for individual Users cannot be definied using the XML structure, because the extension can not know anything about exsiting users, but it can be definied by the Administrator using a specific interface (next point).
3. Interface Extension
Provide an Admin Component, which allows to modify the rules.
The attribute "value" of the <axo> element in the definition can be changed by the frontend, if the readonly is not setted. The provided options of the "value" depends on the attribute "type".
Value "users" : provides a list of User Groups or/and individual users.
Placeholders are definied like {owner} or {modified_by}, which are replaced dynamicly by the framework. This allows to define rules for the "owner" of an object, who to not have general rights.
4. Conclusion
With this development, we will be able to get a "reduced" view on the more powerful ACL structure, but it allows us to define a common "simple" process for all extension developer without restricting people to use the full ACL features. This makes it possible to write a common scecurity managment interface. We can easly define rules for articles, contacts, components, ... and provide a interface for it.
Just to demonstrate I read the wiki page 
