Administrator/components/com_modules/models/modules.php has 5 new lines to check authorizations (line 315 to 319).

To see "guest access" modules, you need to update "guest access" and add "super user" group to the group list.

Not sure if it is a "Work as designed" or not.

Pascal

That's a PR #18335

Pascal

Adding Super User to Guest access will allow Super Users access to see the module in the back end, but it does create weird frontend behavior for Super Users logged into the frontend.

As I told you, I'm not sure PR is doing what it should.

Pascal

add Super User to the Guest assigned user groups as it should

@Chaosxmk

but it does create weird frontend behavior for Super Users logged into the frontend.

can you elaborate ?

IMO on backend super user should always see all modules.
The where query added in #18335 should be in something like
if ($user->authorise('core.admin') !== true) { ... }

is questionable imho, but i can agree..
the main issue, in this matter is:
How it should behave ?

No, super users shouldn’t see everything if their ACL says not to.

In the backend administration I would recommend guest is ignored since guest isn’t a valid ACL group usage case as you need to login to use the backend.

Guest default ACL behaviour does not includ superuser access.

So, each time a superuser add a "guest" module, it is created but disappears.

I agree with csthomas: super user should see everything.

I have doubts whether the view levels can be called ACLs.
The view levels probably can only be used on the frontend.

BTW. Why the view levels is not deprecated?

We have a real ACL at module tab "Permissions".
There could be a conflict when admin can edit module but can not see it.

This is exactly why viewlevels were created to be separate from acl.

Viewlevels are essential "read" permissions. They are the "ACL" in that regard and you don't want to replace it with the full ACL system because that one is much more complex and slower.

Except now you have issues like this one where you're trying to use the ACL system to do one thing and another system which is disconnected from ACL to do ACL like actions. We really should just make core.view an ACL permission and migrate off of view levels.

We say everywhere that super user has access to all the things. View levels have no notion of a super user.

If you do a core.view, you will have to rewrite the current ACL system first.

Using the viewlevels, we can do a database query where we fetch eg the first 20 articles that the user is allowed to see. I don't see how you could do that using an ACL system where you have to run a $user->authorise('core.view', 'com_content.item.' . $item->id) on each tupel.

Afaik we already have some performance issues when the frontend module/menu editing is enabled due to the many ACL checks involved with that.

Imho, it's only the "Guest" view level which can produce such unexpected results. That view level is sort of a hack to begin with. I don't think we should drop the viewlevels just to "fix" that special case. There has to be better ways.

No, super users shouldn’t see everything if their ACL says not to.

Technically, ACL is bypassed for Super Users. You can't say "NO" to a Super User by its design.

The guest group just highlights the flaw in the system.

And yes, I realize adding such an ACL action requires major internal changes. Never said it would be an easy change, but it would be an architecturally correct change to make and would put all of our ACL issues into one system instead of having two competing systems with two different approaches overruling one another.

Just to add here that this happened to me too. It's a recent change because this was fine before. Superusers should have zero restrictions on them - they should have access to everything. At the moment to get my modules visivle again I've had to give my superusers access to "guest" group which is utter madness but at least I can carry on working until this is fixed properly.

just to add though to what I just said... it's no workaround really because it gives me other issues now in the frontend where modules that should only show for guests are now showing when my superusers are logged in... ugh!

Exactly why my suggestion to show guest modules to super users in the backend is valid

On 10 Nov 2017, 17:08 +0000, Mark Taylor notifications@github.com, wrote:

just to add though to what I just said... it's no workaround really because it gives me other issues now in the frontend where modules that should only show for guests are now showing when my superusers are logged in... ugh!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18542.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Yup, whatever was recently changed needs to be reversed because this was working before without issue.

Have a look at my first post, it tells you what's new and where....

The comment by @csthomas already said what has to be done.
One doesn't have to revert the PR, just add a conditional so the where clause is only applied if no Super User is requesting it.

Yes, I can see it was added to J3.8.2 - J3.8.1 was fine before this change. Personally I don't care if it get's reverted or a conditional added - I just need it fixed - for now I am just going to comment out those lines so my sites are not broken.

@Bakual : in both cases, it's just a temporary fix, waiting for an official one, if everyone agrees something's wrong...

even if i'm not a big fan of ,
test #18548 for

• #18542 (comment)
• #18542 (comment)

Ideally, backend behavior for the Guest Access settings should be to function as if they were Public Access. I'm not sure how difficult it would be to setup, but this would allow specific user groups to only be able to access what they can see in the backend as per the current setup.

#18548 is ok if you are a super user, but,....

If you are just admin, you may create modules with "guest access", or even "Super User access". And when it's done, admin can't see the module he'd just created...

@pmleconte Yep, that will be the case. It's likely also the case in other places, not only for modules.

feeling like when you discover just another Pandora's box
😃

@Bakual Ok, I never noticed it....

Just did it as admin on one menu, and, ...... it disappeared...that's magic...

If you are just admin, you may create modules with "guest access", or even "Super User access". And when it's done, admin can't see the module he'd just created...

yes as i was saying here: #17913, the guest level is just the most common case

The idea of using 'access' to limit views meant for managing is problematic

• my suggestion would be to add 'access_manage' property to the records

The reason for not adding 'access_manage' as ACL e.g. 'core.access_manage' is if you see discussion above by @Bakual and @mbabker and as i mention in #17913 the performance on calculating it would be simply not acceptable

1. In backend, list records (that current user has)
   access -OR- access_manage

2. In frontend list records with
   access

3. In frontend if 'manage' filtering flag is set in the DB model via e.g. the menu item then we list
   access -OR- access_manage, or some other way the frontend administrator switches to seeing items that can be managed

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18542

closed as having Pull Request #18548

This seems very similar to the bug I reported on 3.8 https://issues.joomla.org/tracker/joomla-cms/18000

Of course administrator should display all site modules, how else can it edit them?

Is it possible to comment out the change that gave this bug in 3.8.2
If so can someone detail what needs to be changed?

@ramblerswebs i suggest to comment at #18000 as this Issue is closed and get low Notice.