Some more practical remarks about the current ACL *implementation*. When
you are now developing a component (in the CMS) using item level access
control you'll have to do quite some things (see list below) in *every *component.
Such repetitive tasks could be done by a framework (or "platform" or
whatever you call it). That could be improved by:
- providing better defaults on which to fall back
- providing a simpler interface.
Example: when implementing item-level access control you now need to
override the _getAssetParentId() method in your JTable:
- if that method checks for item-level access control by default we
wouldn't have to write that same piece of code over and over again. Using
my own JTable extension to provide that for my own components is only half
a solution: then we would need an extension of JTable and one of
JTableNested. Better just fix it in JTable (which I now do with an override
- I like the flexibility so that I can overwrite/extend methods like
that, but in most cases a default parent asset could be provided by the
system (which table does it belong to and does it have categories?).
- _getAssetParentId() provides the AssetParentId by retrieving the id of
the asset's parent and you retrieve that by using the asset's parent name.
If you would simply provide the asset's parent name to the access control
interface, then that access control package can check the asset_id.The
asset_id could be kept internally, behind the interface.
When developing a component with item-level access control you now have to
- provide settings for the component-level permissions in the config.xml
(could be available by default)
- provide a list of actions for various levels (sections) in access.xml
(could be available by default for the core actions)
- add an options toolbar in your view (could be available by default)
- restrict access to the component's backend in the entry file (could be
available by default)
- Add an asset_id to the item's database table (we could make it so,
that the asset_id is not necessary outside the access package)
- Bind and store the permissions in the assets table (could be done by
- Provide the GUI for editing the permissions at the item level if
someone is entitled to manage that (could be done by default)
- add some language strings (some could be more general to fall back on
Providing an overridable/extendible default could save a lot of work and