[#20715] - Do we need empty permission rules for #__ucm_content table?
- Closed
- 2 Aug 2018
- Medium
- Build: staging
- # 20715
Steps to reproduce the issue
I would like to ask a technical question to people who know how #__assets table works.
When we have at least one tag in the article.
Do we have to create records in #__assets table for rows from #__ucm_content table?
Wnen adding a new article, joomla creates one row in #__content and another in #__ucm_content and a few others in #__ucm....
It is temporary OK.
The issue is that the #__ucm_content table has asset_id column and therefore creates another row in #__assets table, which always has empty rules {}.
Why do we need to store such unnecessary row in #__assets table?
The way to fast fix it.
Example
diff --git a/libraries/src/Table/CoreContent.php b/libraries/src/Table/CoreContent.php
index 41e8f035a4..08f277e2c4 100644
--- a/libraries/src/Table/CoreContent.php
+++ b/libraries/src/Table/CoreContent.php
@@ -31,6 +31,9 @@ class CoreContent extends Table
public function __construct($db)
{
parent::__construct('#__ucm_content', 'core_content_id', $db);
+
+ // Skip creating an asset row (with empty rules) for ucm_content table
+ $this->_trackAssets = false;
}
/**To reduce the size of #__assets table, we can also run below query:
DELETE FROM `#__assets` WHERE name LIKE "#__ucm_content.%" AND `rules` IN ('[]', '{}', '');without IMO any negative effects.
Is anyone interested and would help in testing?
joomla-cms-bot
- 
franz-wohlkoenig
- | Status | New | ⇒ | Information Required |
| Status | Information Required | ⇒ | Discussion |
If you intend on something having ACL, it has to have its own assets table record. A UCM table record is not necessarily the same as a record in another table and the code shouldn't be blindly changed (with a B/C breaking behavior at that) because the one practical use case in core doesn't really make sense to have ACL support.
I introduced a quick fix, I do not want to merge it.
I would like to interest more people with this case.
My solution is wrong, I know that but it works in my case.
I wanted to know more ideas.
We can't run the arbitrary DELETE query you specified. The table is a nested tree table, without correctly updating the tree after deleting records you will break the table's structure.
It's just like a temporary bandage, it does not fix the main problem,
but for me it does not break table structure.
In this case all deleted rows (level 1) has root parent (parent_id=1).
It generates gaps between siblings. Inheritance between assets is not broken.
The way I see it, either UCM records support ACL or they don't. If they do, there's no change to make. If they don't, make the change in the Table class and be done with it (if you're concerned about the size of the assets table introduce a utility script that can correctly remove the asset records while preserving the tree structure, even if it is all level 1 items whose deletion would only create gaps it's still better to do it all the right way).
I still say the right way to deal with this is get rid of UCM. Or, actually use the damn model and work out whatever needs to be worked out to make it usable and not just shove some data into those tables because it's convenient.
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-08-02 16:21:04 |
| Closed_By | ⇒ | brianteeman |
I am going to close this as it looks like the question has been answered
If you intend on something having ACL, it has to have its own assets table record. A UCM table record is not necessarily the same as a record in another table and the code shouldn't be blindly changed (with a B/C breaking behavior at that) because the one practical use case in core doesn't really make sense to have ACL support.
We can't run the arbitrary
DELETEquery you specified. The table is a nested tree table, without correctly updating the tree after deleting records you will break the table's structure.Truthfully, our time is better spent working out how to move the stuff using UCM to a non-UCM based solution and killing that code off once and for all.