No Code Attached Yet bug
avatar andreamusico
andreamusico
20 Mar 2025

Steps to reproduce the issue

  1. Set the default editor to "TinyMCE"
  2. Create a user assigned to a group (Publisher)
  3. Go to System > Plugins > Editor - TinyMCE
  4. Assign "Set 2" to "Publisher" and save (simple set of tools)
  5. Go to frontend and login
  6. Edit an article

Expected result

The TinyMCE should have a simple set of tools.

Actual result

The TinyMCE loads "Set 0" (the largest set of tools).

System information (as much as possible)

Joomla! 5.2.5 and PHP 8.3.14

Additional comments

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.

Votes

# of Users Experiencing Issue
1/1
Average Importance Score
4.00

avatar andreamusico andreamusico - open - 20 Mar 2025
avatar andreamusico andreamusico - change - 20 Mar 2025
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - change - 20 Mar 2025
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 20 Mar 2025
avatar brianteeman
brianteeman - comment - 20 Mar 2025

confirmed

avatar Fedik Fedik - change - 20 Mar 2025
Labels Added: bug
avatar Fedik Fedik - labeled - 20 Mar 2025
avatar Fedik
Fedik - comment - 20 Mar 2025

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.

avatar brianteeman
brianteeman - comment - 20 Mar 2025

yes thats exactly it - it works if you have it set as follows

Image

Image

Image

it does not work if set 1 includes a parent group of authors eg registered

Image

avatar brianteeman
brianteeman - comment - 20 Mar 2025

@andreamusico can you please check the following and report back

  1. What groups are assigned to set 1
  2. What groups is the user assigned to
avatar andreamusico
andreamusico - comment - 21 Mar 2025

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.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45173.

avatar brianteeman
brianteeman - comment - 21 Mar 2025

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

avatar andreamusico
andreamusico - comment - 21 Mar 2025

I've tried to follow your hints configuring TinyMCE this way:

  1. Set 0 [administrator, editor, super users]
  2. Set 1 [manager, publisher]
  3. Set 2 [public]

In frontend, logging in as "publisher" user, Joomla! loads set 0.

I've tried this, too:

  1. Set 0 [administrator, editor, super users]
  2. Set 1 [public]
  3. Set 2 [manager, publisher]

In frontend, logging in as "publisher" user, Joomla! loads set 0.

Am I missing anything? Thanks for all.

avatar brianteeman
brianteeman - comment - 21 Mar 2025

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

avatar andreamusico
andreamusico - comment - 21 Mar 2025

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.

avatar brianteeman
brianteeman - comment - 21 Mar 2025

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]

avatar brianteeman
brianteeman - comment - 21 Mar 2025

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

avatar Fedik Fedik - change - 22 Mar 2025
Status New Closed
Closed_Date 0000-00-00 00:00:00 2025-03-22 09:02:29
Closed_By Fedik
avatar Fedik Fedik - close - 22 Mar 2025
avatar Fedik
Fedik - comment - 22 Mar 2025

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".

// Sort the array in reverse, so the items with the lowest access level goes first
krsort($extraOptionsAll);
// Get configuration depend from User group
foreach ($extraOptionsAll as $set => $val) {

I close the issue as not a bug.

Add a Comment

Login with GitHub to post a comment