Classes do not work as explained ..

[Alex-e107nl]

@e107help i have to use classes to give acces to certain parts of a website, i have this in my admin:

class icon No One (inactive)
class iconclass icon [Foundation (Group).]
class iconclass iconclass icon [Foundation CF1]
class iconclass iconclass icon [Foundation CF2]
class iconclass iconclass icon [Foundation CF3]

It looks like this:

The explanation on https://userguide.e107.org/administration/users/user-classes is:

_The 'class parent' allows you to set a hierarchy of classes. If the 'top' of the hierarchy is the 'Everybody/Public' or 'Member' classes, the classes lower down the hierarchy also have the rights of their parent class, and that classes' parent, and so on.

If the 'top' of the hierarchy is the 'No One/Nobody' class, then rights are accumulated in the opposite direction - a class accumlates all the rights of a class below them in the tree. The resulting tree is shown in the lower part of the page; you can expand and contract branches by clicking on the '+' and '-' boxes

Class Parent

• If the top of the tree is 'No One', permissions increase towards the top of the tree
• If the top of the tree is 'Everyone', permissions increase as you go down the tree_

In this case, it should be so that if I assign a user the class Foundation, all pages with CF1 CF2 CF3 should be visible; however, that is not the case. No pages are displayed! If I assign the class CF1 CF2 or CF3, they are displayed, but the intention is precisely to use the root class to grant access to all subordinates. Am I doing something wrong?

And what is the difference between assigning a Type - Group or Standard?

Can you look into this?

I am using PHP 8.3 and the github version 26-08-2026 Version 2.4.0 (git) 10.6.28-MariaDB

[e107help[bot]]

Set the Type of Foundation to Standard, @Alex-e107nl, then open the Options tab of User Classes and, under User Class Maintenance, press Execute on the row "Rebuild class hierarchy". After that a user in Foundation also holds CF1, CF2 and CF3, and the pages restricted to any of them show up. A page reload as that user is enough; the class list is worked out on every request.

I reproduced it in the Codeception harness on master, inserting your four classes with the rows the admin form posts and running the same hooks the page runs. Your 26 August build carries the same code for this. With Foundation as a Group, a user in Foundation holds exactly one class: Foundation. Change the Type to Standard and nothing moves yet. Run the rebuild and Foundation's stored list becomes Foundation, CF1, CF2, CF3.

What Group is. A Standard class takes its rights from its place in the tree, as the user guide describes. A Group was the other way to bundle classes: a hand-picked list, independent of the tree, where whoever is in the group is in every class ticked under "Classes in group". That checkbox list is the one the user guide describes, and it went out with the 2017 rewrite of the admin page. The Type dropdown kept both options (userclass2.php:128), but nothing on a 2.x admin page can put a class into a Group's list, so a Group can only ever contain itself. The walk that fills in each class's rights also stops the moment it meets a Group (userclass_class.php:1568), so nothing below Foundation was collected either. For anything you want to inherit through the tree, use Standard.

Why the rebuild step. Each class's accumulated rights are stored in the database and recomputed only when a class is created (afterCreate) or when you run the rebuild. Editing an existing class only clears the cache (afterUpdate), so changing the Type or the Parent of a class you already have leaves its stored list as it was. The tree drawn at the bottom of the page is built from the Parent field, not from those stored lists, which is why it looked right while the site said no.

Both of those are ours: a Type option nothing can fill, and an edit that does not rebuild. I'll put them in front of Deltik, and what to do about them is his call.

[Alex-e107nl]

Yess, thx, that worked!