Recently on various lists and in the trackers the question of handling more
complex ACL structures and expected behaviors has  come up. This is
something that obviously partly the responsibility of the platform and
partly the responsibility of the application, but I think to make the
application work we need to clarify about what the platform classes are
expecting.

There are two related scenarios in which this has become an issue.
1. When an application wants to have multiple types of assets but not use
categories.
2. When an application wants to have multiple types of categories using the
dot separated names offered by JCategory.

The short version of what happens in these cases is that the assets always
are set to be children of the root asset. This means that they cannot
inherit permissions from their extension in the way that developers are
expecting.

This is going to look long but I have narrowed it down to 4 specific
questions and the rest is just explaining the background to each question.

So, as we know, JAccess is the key class but there are a lot of
relationships including to JTable, JTableAssets, JCategories,
JTableCategory, JTableExtensions, JFormFieldRules, Even  though some of
them are in now in legacy they actually in the real world of applications
have a lot of dependencies and are typical of the kinds of things
developers on the platform want to do.

Let's look at JTableContent which is  probably the example most developers
use if they want an example table that tracks assets and see why this is
happening.
The important code is here:
https://github.com/joomla/joomla-platform/blob/staging/libraries/lega...

To get the parent we check the catid. If there is no catid we use the
default. The default is to use the root asset  (parent_id=1).

Question 1: Why is it that the default is not to parent to the extension
given that the extension is already specified in _getAssetName()?

I believe this is why the CMS ended up mandating that all items in its
content type extensions require categories.  However I don't really
understand the logic that says that because you are not in a category we
don't have any information on permissions based on the component.

If there is no extension of course it makes sense to fall back to the root.
That means that in a simple platform application there won't be a problem,
you just fall back to the base permissions where ever you have figured out
to save those--I guess you can just use a string that could be stored in
the configuration.

Question 2: Would it be reasonable for us to add a fall back layer in
JTableContent that goes to component as a parent if no catid is present? Or
does that violate something in the JAccess model?
This would be fine in JTableContent as far as I know and would make a
better example asset tracking table class in my opinion.

Now thinking about the second group, those that want to use categories but
want to have multiple types of categories.  As mentioned above in principle
this is done by created a dot separated name to be used as the extension in
the categories table. So for example if in the CMS I wanted to create
categories for banners clients in addition to categories for banners I
would use com_banners.clients as the extension. In doing this I would add a
category.clients section to the xml. If I did this, I would notice a few
things.
When I go to create a category.clients category it at first appears to work
perfectly until I notice that the category permissions are inheriting only
from global configuration not from com_banners. This is because the asset
for the new category has an asset name
like: com_banners.clients.category.78 and is parented to the global
configuration.  This is a variation of the issue above except that
categories usually is well behaved and has the code to find the extension
name and use that as the parent. But in this case it is looking for an
extension named com_banners.clients.  

It is easy enough to make the asset name for a specific category.clients
asset not include the .clients string but that creates other issues, for
example the rules field then does not know to use category.clients for the
rules since it uses the asset name for that.  So, it's easy enough to
change the asset name but that has other ramifications for the classes I
listed above.  Again these are fixable but not without knowing the answer
to Question 3.

Question 3:  What is the expected asset name when an application wants to
allow multiple subtypes of an asset type within an "extension" (the three
or more levels are important)? In my example is it com_banners.category.xx
or is it com_banners.category.clients.xx but it does not have to be
categories.

I know all the categories classes are legacy but the same issue will apply
if a developer tries to do something similar (have an asset type with
multiple variations or have nested assets or have multiple "extensions"
whatever they end up being called). For example any application using user
permissions will have users and is still going to need a user manager and a
way to set the global permissions (a concept that is built in all over the
place) and we are still going to need a way to set permissions for who can
do those things) in any platform application. Even if it is a separate
application that does user management there still need to be rules about
who makes rules.

I also wanted to mention that although it will never happen if people use
the API correctly in practice we have found that in many cases for various
reasons having to do with the messiness of data and the ability of users to
directly modify the database this query:
https://github.com/joomla/joomla-platform/blob/staging/libraries/joom...

                        $query = $db->getQuery(true);
                        $query->select('rules');
                        $query->from('#__assets');
                        $query->where('parent_id = 0');
                        $db->setQuery($query);
                        $result = $db->loadColumn();

will at times return multiple items (or no items).

Question 4: Would it be reasonable to add a test for returning multiple
records here?
And if so would we attempt to select the one where the first 4 letters of
the name are
'root' ? Or use the minimum lft and/or maximum rgt value? Or should it just
throw an
exception and be done?

Normally I would probably just send in pull request for question 4 to add
an exception but in the context of the other questions I feel like I need a
better understanding of what's supposed to be happening.

Thanks for your patience,

Elin

I guess no one is going to answer the four  questions so I'll have to try
my best to make up my own anwers.  This is what I am thinking based on
spending some more time on it and also on a possible generic (non CMS
specific) replacement abstract class for JTableContent.

The version of JAccess in the 11.4 platform is both highly CMS specific
(e.g. it specifies a  component folder as the place to look for the
rules)and yet does not work in the CMS when a component wants to just
inherit from global settings.  The newer APIs are more generic but still
have the some of the same basic issues.
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

Now I initially thought that the problems people not using the categories
system were having were because they were probably failing to set
$recursive to true here:
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

That may be true, but actually I think it is more complex than that or
there is a second issue.

First the root asset has two different ways of being found or set.
Sometimes it is the asset with parent_id of 0 and sometimes it is the asset
with the key of   1, which are obviously not necessarily the same thing.
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...
(that's the query that brings sites down)
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...
Also relevant:
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

If we are going to use the query then I think the answer to question # 4
must be yes and we should also take a look at that hard coding of 1 as
well.  Would it make sense to use  JTableNested's getRootID() method which
already deals with the possibility of this with an unexpected value
exception? Or something like it that can handle 0? Or else address this in
some other way?  
https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

Also it seems to me that this sanity check is totally ignoring the insanity
of having multiple asset records with parent_ids of 0.

https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

For #3

I *think* I have this right.

An asset has  dot separated name. Reading from right to left, the rightmost
level is a unique identifier for the record within the table in which it is
stored, either a numeric key or a string name.
The rest of the name by default is just the table name. However, an
application can make up its own human readable name instead, like "article"
or "category" and these can be more complex and can make searching easier
by using structured naming like users.category.note.117 instead of
#__categories.117, but they are essentially arbitrary from the point of
view of JAccess, all it cares about are lft rgt parent_id and level.

https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

https://github.com/joomla/joomla-platform/blob/master/libraries/jooml...

At the point that the table name is used, we just tack on the id and make
the root asset the parent.

It seems to be that the answer to #4 is that if an application wants to
implement separate acl within a subsection (e.g. different types of
categories within one component or different content types but all stored
in the same #__tablename) this should be managed by the application
probably with extra fields. In the CMS we give you a built in way of doing
that easily with the categories system, but if a developer doesn't want to
use the category system she has to implement some other method of managing
hierarchy because by themselves JTable and JTableContent are not going to
do anything about handling this.  Indeed if you do not extend
_getAssetParentId()  you will always get a parent of 1 no matter what else
you do. So I think neglecting to specifically do that is a second mistake
people are making in attempting to use ACL while extending JTable.

For question #2 my feeling is that a generic content table should help make
this happen correctly by including a property optionally identifying a
parent table (e.g. #__categories or #__extensions but it could be anything)
and a property identifying the field name of the field with key to that
table if needed. (We already use these in the CMS in the form of catid most
places and extension in categories).  That lets us escape categories if we
want to (and developers both inside and outside the CMS very much  want to
do so, which is why we are getting questions on all the  lists about it).

If we did that it would also help to handle question 1.  

So to summarize:
Question 1: Why is it that the default is not to parent to the extension
given that the extension is already specified in _getAssetName()?
Because it is hard coded to 1 unless the extended class does something else.

Question 2: Would it be reasonable for us to add a fall back layer in a
replacement for JTableContent  that goes to something as a parent (and
specifically in the CMS if no catid is present)? Or does that violate
something in the JAccess model?

Yes it would be reasonable (especially since JTableContent it is in legacy)

Question 3:  What is the expected asset name when an application wants to
allow multiple subtypes of an asset type within an "extension" (the three
or more levels are important)?

It's up to the application except that the last part has to be unique
within the table holding the assets.

Question 4: Would it be reasonable to add a test for returning multiple
records here?  (this is the query for parent_id)

yes and it would be good to handle the results properly.

Sorry,

Elin

read more »