I’m having some problems with system settings in MODX3.1.2 that I’ve never had in previous versions.
To limit the resources visible to a user group, I’ve always used tree_root_id by entering the IDs, separated by commas, of the resources that a group can see in the manager tree, so only those (and any children) can be viewed and edited.
I would go into the user group and enter a new parameter tree_root_id with fields matching the system settings and only change the IDs.
In 3.1.2, it’s no longer possible to operate as in previous versions.
If I insert the new setting in the group and use the values setting_tree_root_id and setting_tree_root_id_desc for name and description, they also disappear from the general system settings, leaving only the lexicon_key. This happens for any setting I add, and if I manually write the name and description, it replaces the general one.
For the tree_root_id parameter, it is no longer possible to enter IDs separated by commas because it only takes a single numeric value.
Looking at the code, I’m not sure how well supported a comma-separated list for the tree_root_id setting is. At least half the code assumes that this is just a single integer value.
What exactly do you mean by “previous versions”?
What exactly is “no longer possible”?
When I test it to create a new setting tree_root_id in MODX 3.1.2 under “Access Control Lists” → {user_group} → tab “Settings” , this still seems to work.
Do you mean in the User-Group-settings or under → “System Settings”?
It works, but now it’s no longer possible to write multiple IDs separated by commas, only a single ID, just one numerical value.
For me, it was perfect.
I used it, for example, to allow lawyers to only view the Terms of Service page, and editors to see only the “News” and “Blog” collections (I would input the collection IDs and that was it).
I never used Resource Groups for the manager because with multi-context websites with 120-200 pages, it was quite a problem; the restriction might appear at the end when 100 pages were already done.
I wouldn’t know how to do it, and I wouldn’t want to show the entire site to certain user groups that just need to write and have no idea how the MODx management system works.
Yes, if you insert a setting anywhere in the managerial, the system settings no longer take the value of the language phrase, and it is no longer possible to make it take it.
In the image below, the parameter insertion in the User Group is visible along with the respective system settings page.
It is no longer possible to revert even by deleting the setting in the user group; in the system settings, the lexicon_key will always remain. I also tried to replace the language phrases with words, but without effect; the terms inserted replace their respective values in the general settings.
If in the user parameter settings I put “pluto” as a description, this replaces that of the general system settings.
Why did you use “Campo Numerico” for the “Tipo Campo” field here?
If you select “Campo Testo (Textfield)” instead, then you should still be able to insert a comma-separated list as the value.
I don’t see anything that has changed in MODX 3.x compared to MODX 2.x.
To me it looks like this feature was half-heartedly implemented in MODX 2.x, but still works the same in MODX 3.
Using the text field works, it had been a while since I last used it and I copied the one from the general system settings that has the “Field Type” as numeric. Thank you.
So can I continue to use it as a filtering system, or is it a problem since you wrote to me:
“Looking at the code, I’m not sure how well supported a comma-separated list for the tree_root_id setting is. At least half the code assumes that this is just a single integer value”?
Regarding the issue with language phrases, which didn’t seem to exist in versions 2.x.x., to resolve it, simply delete the terms the table creates when you add a new setting that uses existing language phrases.
When creating a new setting, MODX generates the values setting_key and setting_key_desc in the language phrases table. These values are taken from the default.inc.php file and not from the setting.inc.php file, which is used when core is used as namespaces “core”.
Therefore, you either create your own namespace with the two lexicon keys (inside default.inc.php) or you need to delete the two created values from the DB; otherwise, it will always use those.
If it worked for you before, then just continue to use it.
The only problem I see, is that when a user doesn’t have the new_document_in_root permission, they probably will still be able to create resources in some of the root nodes, when multiple are defined in the tree_root_id setting. But I guess that’s pretty much an edge case.
→ “System Settings”?
