The TinyMCE should have a simple set of tools.
The TinyMCE loads "Set 0" (the largest set of tools).
Joomla! 5.2.5 and PHP 8.3.14
In plugins / editors / tinymce / src / PluginTraits / DisplayTrait.php we have (line 133):
$ugroups = array_combine($user->getAuthorisedGroups(), $user->getAuthorisedGroups());
the array contains the current group and all the ancestors
further in the code (line 146):
// Get configuration depend from User group
foreach ($extraOptionsAll as $set => $val) {
$val = (object) $val;
$val->access = empty($val->access) ? [] : $val->access;
//echo '<pre>'; print_r($val->access); echo '</pre>';
// Check whether User in one of allowed group
foreach ($val->access as $group) {
if (isset($ugroups[$group])) {
$extraOptions = $val;
$toolbarParams = (object) $toolbarParamsAll[$set];
}
}
}
Looping over TinyMCE sets and its access groups, it does not stops on the current logged user group, but considers also its ancestors, giving a wrong result.
Labels |
Removed:
?
|
Labels |
Added:
No Code Attached Yet
|
Labels |
Added:
bug
|
It is probably a side effect of re-ordering that were made for groups, sometime in past.
When each following group had higher rights than previous.
@andreamusico can you please check the following and report back
I've tested on a fresh 5.2.3 install updated to 5.2.5.
Set 0 [administrator, editor, super users] and set 1 [manager, registered] are the default ones. I've added "publisher" to set 2 [public].
In the default installation "publisher" and "author" groups are missing in TinyMCE sets.
they are NOT missing - they are child groups of registered
Set 1 has a higher priority than set 2 and i believe what is happening is that the loop is stopping on step 1 because the user is matching the registered group/ You could try and confirm this by swapping the groups in step 1 and step 2
I've tried to follow your hints configuring TinyMCE this way:
In frontend, logging in as "publisher" user, Joomla! loads set 0.
I've tried this, too:
In frontend, logging in as "publisher" user, Joomla! loads set 0.
Am I missing anything? Thanks for all.
publisher is a child of editor so my assumption of the problem is correct - you can confirm (i hope) by removing editor from set 0
Ok, now it works:
Set 0 [administrator, super users]
Set 1 [manager, registered]
Set 2 [public]
In frontend, logging in as "publisher" user, Joomla! loads Set 1.
So Set 1 is for manager (and its child administrator) and registered (and its children author, editor, publisher)
A problem remains:
How can I have two distinct profiles for "registered" (simple set) an "publisher" (advanced set)?
More generally, how to have distinct sets for distinct groups, even for a single group? The plugin TinyMCE allows you to create more sets, so it's unclear how this affects the set loaded relative to assigned group or groups.
great - that at least explains correctly what is happening
A problem remains: How can I have two distinct profiles for "registered" (simple set) an "publisher" (advanced set)?
More generally, how to have distinct sets for distinct groups, even for a single group? The plugin TinyMCE allows you to create more sets, so it's unclear how this affects the set loaded relative to assigned group or groups.
The group with the highest specificity should be in the highest set
eg
Set 0 [super users]
set 1 [publisher]
set 2 [author]
set 3 [registered]
basically the current code is stopping looping through the sets as soon as you get a match and not continuing to look for an exact match
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-03-22 09:02:29 |
Closed_By | ⇒ | Fedik |
I looked again, there is nothing to fix. That is expected behavior.
Looping over TinyMCE sets and its access groups, it does not stops on the current logged user group, but considers also its ancestors, giving a wrong result.
Because user may have multiple groups, the code is looping from lowest to highest, and picking last group with "most access".
joomla-cms/plugins/editors/tinymce/src/PluginTraits/DisplayTrait.php
Lines 142 to 146 in 8cd35f2
I close the issue as not a bug.
confirmed