Stuck in Post Installation when using ACL manager

Hello

the ACL manager should not reset:

the category assets of the TOP-level categories if it detects that they point to the asset of the FLEXIContent Component

Hello,

seeing this issue myself for some time now, I contacted the ACL manager dev and got the following reply:

I think that is caused because Flexicontent is making use of the Joomla articles as base, but try to store the article assets as nested items of Flexicontent. This is not correct, as the parent of articles in the Joomla articles database table should always be stored with the Articles Manager in the assets table. This is why ACL Manager detects the issue.
This is not something I can solve, and should be addressed by the developers of Flexicontent.

For my part, I think I can live with these "errors", as until now they never caused real problems for me.

The only question is:
What if other assets have to be repaired by ACL manager?
In this case, I can only fix them together with the FC asset entries in one go, and I will have to restore the initial permissions by FC each time afterwards.

Hope this procedure will work reliable also in future versions - or there will be a better solution.

Regards

Hello

please forward this message to ACL manager

- when FLEXIcontent is installed,

FLEXIcontent manages the Joomla articles, and not the Joomla article manager so inheriting permission from com_content component, is inappropriate

so the top-level categories are made to point to FLEXIcontent component asset


thus ACL manager should not be "fixing" the top-level categories, simply because as said above FLEXIcontent is managing the content and not Joomla article manager,


it 10x simpler for ACL manager to detect that FLEXIcontent is installed and avoid "fixing" the top-level categories


it is possible to allow Joomla top-level categories to point to com_content component asset but the extra ACL permissions that FLEXIcontent adds will no longer be inherited,


but we will examine and implmenet a workaround in a future release but now:


it 10x simpler for ACL manager to detect that FLEXIcontent is installed and avoid "fixing" the top-level categories


Regards

Hi there,

I'm the developer of ACL Manager and replied this in my ticket system to HillWoody:

I'm sorry you are in the middle of two developers...

I will never built-in any specific 3rd party extension support in ACL Manager because an extension is not using the Joomla ACL correctly. So it is indeed simpler for Flexicontent if ACL Manager detects Flexicontent, but that is not the correct way to move forward.

Let me try to provide a bit more technical background:
1) Flexicontent is stores categories is the #__categories table. The "extension" column is filled with "com_content", so the Joomla article manager.
2) In this table a reference is made to the #__assets table, in the assets table you will find the categories listed as "com_content.category.81". This means that in this example this asset is related to a category with ID 81, that belongs to "com_content".
3) The parent ID of this asset entry should always point to the component where it belongs, so "com_content".
4) Flexicontent is changing this parent ID to their "com_flexicontent" entry in the assets table. This is not correct, and detected by ACL Manager.

I think Flexicontent can solve this in two ways:
1) Correctly use the Joomla ACL system and respect that an asset like "com_content.category.81" belongs to the extension "com_content"
2) Store categories under their own extension name, so in the categories table with "com_flexicontent" and the assets should be names like "com_flexicontent.category.81". In that way the parent ID of this asset should indeed point to "com_flexicontent".

As their developer already said:
"FLEXIcontent manages the Joomla articles, and not the Joomla article manager so inheriting permission from com_content component, is inappropriate"
Suggestion 2 is the way to move forward. If it should not inherit the com_content permissions, they should store the assets under their own component name as well.

So I'm confident that ACL Manager is behaving correctly and that Flexicontent needs changes on this area to solve this issue.

Hopefully this helps you and the Flexicontent developers further.

thanks for this big reply we will check it !

Hello,

having compatibility with ACL manager (and any similar extension not willing to do little to support FLEXIcontent) and loosing compatibility with hundrends or thousands other extensions is not a viable suggestion,

so what was suggested above will not happen,

-- not only because of being asked to do 10x or 100x work on our part instead of 1x work on the other part

-- but also because we will win too little and loose too much