users do not inherit from groups permissions in 2.0.0-rc9

[Keyskeeper]

grav : 2.0.0-rc9 (fresh install with default admin plugins)
Apache php 8.3

I'm using Admin plugin to create users and groups.

First, there is an issue when editing groups.
Permissions can't be set through the admin interface. I have to manually edit groups.yaml one time and set some permissions and then it works again.

Second, users do not inherit permissions from groups.
I have to set specific permissions for each user.

[rhukster]

Thanks for the detailed report. I dug into both points and want to separate them, because they have different causes.

Permission inheritance itself is working

I tested the regular-account inheritance path directly:

• Group editors with access: { admin: { login: true, pages: { list: true } } }
  • a user in that group → authorize('admin.login') = true
  • → authorize('admin.pages.list') = true
  • → authorize('admin.users.create') = false (correctly not granted)
• Group with an empty access: {}
  • user in that group → authorize('admin.login') = false (nothing to inherit)

So users do inherit from their groups, as long as the group actually has permissions stored in access. The "users aren't inheriting" symptom is really a downstream effect of the first problem: if the group saves with an empty access, there is nothing for the user to inherit, and it looks like inheritance is broken when it isn't.

The real issue: the group saves with an empty access

This is the one to focus on. A couple of things I confirmed:

• The save-time filtering is fine. With the group blueprint's access field (type: array, value_type: bool, ignore_empty: true), a permission set to Allowed or Denied is preserved; only the Not set state is dropped, which is intended (an absent key means "inherit / neutral"). So toggling a permission to Allowed and saving does persist it.
• An empty access therefore means the form submitted no Allowed/Denied values at all, i.e. the permission toggles were not actually populated when you saved.

That also matches your workaround. The permissions field renders its toggles from the registered permissions list, with a fallback that only renders rows for permission keys already present in the saved data. So if the list comes up empty, you see no toggles and can't set anything; once you seed one permission by hand in groups.yaml, that row renders and the field becomes editable from then on. That is the behavior you described.

To narrow it down, two quick questions

1. Which admin are you using to edit the group, the classic Admin plugin, or the new Admin (admin-next / admin2 + api)?
2. When you open the group edit screen, do the permission toggles appear at all, or is the permissions section blank?

The answers will tell me whether the permissions catalog is failing to populate in your setup versus a save-path problem, and I can point at the exact fix from there. For what it's worth, group editing is being moved into the new Admin, whose permissions editor loads the full catalog from a dedicated endpoint rather than relying on render-time state, so it should also be a good thing to test against if you have it enabled.