Skip to content
Grav 2.0 is officially stable. Read the announcement →
Support

How to allow non-super users to access custom Flex Objects in Admin2?

Solved by Andy Miller View solution

Started by kskt 6 days ago · 2 replies · 125 views
6 days ago

Hello,

I am trying to grant a non-super user access to custom FlexObjects within the Admin2 panel, but I'm having trouble getting it to display.

Environment:

YAML
Grav: 2.0.8

Admin2: 2.0.12

Flex-objects: 1.4.4

Context:

I have installed both the Admin2 and Flex-objects plugins, and I am using a custom FlexObjects created via Devtools.

When logged in as a Super User, the custom FlexObjects is visible and works perfectly in the Admin2 panel.

However, when I change the user's permissions to the following configuration, the custom FlexObjects completely disappears from the admin panel:

YAML
# user/accounts/my-user-name.yaml
  api:
    super: false
    access: true
    pages: true
    media: true
    flex-objects: true
YAML
# user/config/plugins/flex-objects.yaml
directories:
  - 'blueprints://flex-objects/pages.yaml'
  - 'blueprints://flex-objects/user-accounts.yaml'
  - 'blueprints://flex-objects/user-groups.yaml'
  - 'blueprints://flex-objects/my-custom-flex-objects.yaml'

Question:

What specific permissions are required for a non-super user to manage custom FlexObjects in the Admin2 plugin?

Any insights or examples would be greatly appreciated. Thank you!

6 days ago Solution

Hi,

The short version: flex-objects: true isn't the permission that controls this. In Admin2 the sidebar is built one directory at a time, and each custom directory is only added if the account holds a list grant for it. When you're a Super User that check is skipped, so everything shows. As soon as you set super: false, the account has no per-directory list permission, so the entry gets filtered out and the directory "disappears."

Which key you need depends on whether your directory's blueprint declares its own admin.permissions: block.

  1. If it does NOT (the common case for a simple custom directory), the permission falls back to admin.flex-object (note: singular "flex-object", and this grant is shared across all such directories). Grant it like this in the user account:
YAML
    access:
      admin:
        login: true
        flex-object:
          list: true
          read: true
          create: true
          update: true
          delete: true
  1. If your blueprint DOES declare a permissions block, for example:
YAML
    admin:
      permissions:
        api.my-thing:
          type: crudl

then the grant has to match that prefix instead:

YAML
    access:
      api:
        my-thing:
          list: true
          read: true
          create: true
          update: true
          delete: true

The list action is the important one for visibility. The others control what the user can actually do once inside.

To check which case you're in, open your directory's blueprint and look for an admin.permissions: key. If it's there, use that prefix (case 2). If it isn't, use admin.flex-object.* (case 1).

One heads-up so it doesn't trip you: the generic action name is registered as plural (admin.flex-objects), but the fallback check for a directory without its own permissions block looks for the singular admin.flex-object.list. So if you grant the plural version it will look correct but won't bring the sidebar entry back. Use the singular form for case 1.

Give that a try and let me know if it shows up.

5 days ago

Thank you so much!

Case 2 worked perfectly for me.

YAML
# user/plugins/my-custom-flex-objects/blueprints/flex-objects/my_custom_flex_objects.yaml
        # Permissions
        permissions:
            # Primary permissions
            api.my_custom_flex_objects:
                type: crudl
YAML
# user/accounts/my-user-name.yaml
access:
  api:
    super: false
    access: true
    my_custom_flex_objects:
      list: true
      read: true
      create: true
      update: true
      delete: true
👍 1

Suggested topics

Topic Participants Replies Views Activity
Support · by BenLaKnet, 5 days ago
1 118 2 days ago
Support · by BenLaKnet, 1 week ago
5 194 2 days ago
Support · by kskt, 2 days ago
0 42 2 days ago
Support · by David Meissner, 2 days ago
0 39 2 days ago
Support · by David Meissner, 3 days ago
3 88 3 days ago