Custom permissions for modules and more

[Fusseldieb]

I was thinking that it would eventually be interesting to add a feature in which an Admin could add a custom permission to Directus to then control who has access to certain things or not, but I'm not talking about Collections;
I'm talking about custom permissions that could be added inside the "Roles & Permissions" page without being tied to any collection.
A custom name that the user could give his permission and a checkbox if ☑️ or ⬜.

What do I mean by that:

Let's say I want to expand Directus and thus I build a custom module.
Done that, I want only Admins with a certain exclusive permission to see and access this module that I've created.
Right now (at the time of writing) the only way to archieve this would be to create a dummy table with fields that each represent a custom module permission.
And in my module I would implement a check to see if the user has permission to that dummy field, and if yes, would load my custom module.
It probably works, however, it just doesn't look right, does it? 😅

What do you think?

[benhaynes]

I like it. It makes sense to have a place for extension permissions, we'll just need to look into how the values should be saved. KVPs seems easy enough, but it's important to maintain flexibility for extensions as well as their permissions. It might be best to allow extensions to import their own settings pane... which could be saved as key value pairs, JSON, or custom data (in custom collections).

[Fusseldieb]

Those are interesting approachs 🙂

[cah4a]

Is there any progress on this?

[rijkvanzanten]

Unfortunately, we can not provide estimates on features or fixes. As of now, the only way to get an accurate timeline or release date is to sponsor this task. We recognize that this may be an important feature/fix, but we are a small open-source organization with a lot to triage and complete. If you can't sponsor this ticket, then the next best thing is to increase its priority by giving it a 👍 . Or contribute a pull-request... after all, this is OSS!

---

This is an automated response.

[danieljwestman]

This is an important aspect of custom module development. Often we don't want every user to have access to every module/functionality. Which also leads me in to something that has been discussed in some other issue/discussion; we still need a way to customize the module bar navigation for different roles - as it was before the setting was moved from roles & permissions to the general project settings. Any more thoughts or progress on this, @benhaynes ?

[benhaynes]

Module (and collection) setup (config, sorting, grouping, nesting) has been moved to the global Project Settings, and then Roles will have more simple options for disabling them. That second bit is planned, but not on our immediate docket. Could come in the next month or so, but it all depends on how requested it is by the community (how we prioritize our docket).

[danieljwestman]

@benhaynes
I understand. Hope this functionality will get some more traction within the community!

[martijnboland]

@benhaynes is there something we can do to bring back module and collection filtering per role? We use that extensively to dramatically simplify the Directus experience for non-admin users together with role-specific dashboards.
Perhaps a simple option to disable some of the modules for a specific role on the role management page will already be enough.

[benhaynes]

There are many options for how we will officially handle this, the problem is what works now as a stop-gap solution. We can't push a half-implemented feature, so we'll have to discuss and align on the ideal way to handle this... then implement. All of that takes time.

In the meantime, I'm trying to think of ways that we can use something like Project Settings > CSS Overrides to show/hide modules/collections based on role. However, I don't know if we have any selectors (eg: classes) in the App for the current user role.

Also, it goes without mentioning, but the best way to make this happen sooner than our internal triaging is to "Sponsor" it.

[martijnboland]

That makes sense, especially the fact that you can't push a half-implemented feature.

[peauc]

For anyone looking at this thread, this feature is preRegisterCheck as shown here https://docs.directus.io/extensions/modules.html#extension-entrypoint

[rafarc21]

Hello @benhaynes, Since it's been a while, I'd be interested to know if you figured out if the user role selector is available or not. A custom CSS solution would be a good workaround for now while it seems the feature isn't yet live...

[martijnboland]

Alternatively, you could use a read hook to hide specific menu items, see https://blogs.taiga.nl/martijn/2022/04/29/use-a-hook-to-hide-modules-for-non-admin-roles-in-directus/.

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[pintoderian]

Hi, for anyone looking at this thread, the following helped me.

module.exports = function registerHook({ filter }, { services }) {
  filter('settings.read', async (items, meta, { database: knex, schema, accountability }) => {
    if (accountability && !accountability.admin) {
      const { ItemsService } = services;
      const service = new ItemsService('directus_roles', { knex, schema, accountability });
      const rol = accountability.role;
      const rolFind = await service.knex.from('directus_roles').where({ id: rol }).first();
      const rolName = rolFind?.name?.toLowerCase();
      var settings = items[0];
      settings.module_bar = items[0].module_bar.map(module => {
        if (module.id === 'users') {
          module.enabled = false;
        }
        if (module.id === 'reports' && rolName != 'reports') {
          module.enabled = false;
        }
        return module;
      });
    }
    return items;
  });
};

[kevincam3]

Can I do this if I'm using the docker image of directus?

[u12206050]

You should be able to add this as a custom extension which then gets mounted into the docker image as part of the extensions directory

[u12206050]

For anyone looking for the proper way to check permissions in a custom extension, you can add a preRegisterCheck function to the defineModule or what ever custom extension you have:

Example:

import { defineModule } from '@directus/extensions-sdk';
…

export default defineModule({
	id: 'custom-manager',
	name: 'Manage Custom Stuff',
	icon: 'attractions',
	preferBuiltins: false,
	routes: […],
	preRegisterCheck(user, permissions) {
		if (user.role.admin_access) return true;

		const permission = permissions.find(
			permission => permission.collection === 'stuff' && permission.action === 'create'
		);

		return !!permission;
	},
});

[kevincam3]

Is there a way, from the Directus Studio to hide modules/navigation based on a users' role?

[u12206050]

No, not unless you have included the preRegisterCheck before hand.

[kevincam3]

Can I do a custom extension that will always run that can include this preRegisterCheck? I guess I need to understand how the extensions are executed.

[nchatu]

Any update of this request? This is a real important one hence most of the extensions at some point requires user authentication.

[peauc]

@kevincam3 module filtering depending on an user's role.
I've looked at Directus' sources because I couldn't find documentation.

Note: This exemple is working because i've also added a type column to users

async function preRegisterCheck(user, _): Promise<boolean> {
  return user.role.admin_access || ["data", "integration"].includes(user.type);
}

[kevincam3]

Thanks when I get a minute i'm going to try to implement this idea

[nchatu]

Hi @peauc, I tried your workaround and it worked well. Thanks for sharing. Basically I added a new column named "role_name" (using sql) and copied the value of role into it (in the admin). The newly added column was included in the first argument to the preRegisterCheck. So it was just a simple check for the desired role name.

preRegisterCheck: (user, _) => {
		// Check if the user has the necessary permissions to access the extension
		console.log('preRegisterCheck', user);
		if(user.role.admin_access || user.role_name === 'Manager') {
			return true;
		}
		return false;
	}

I call it a workaround since we have to manually add a new column and have to copy the role name in to it. It would be nicer if Directus provides the role name out of the box with the preRegisterCheck.

[peauc]

@nchatu check both parameters of the function, the information about role name is available.
You can also access database there.

[nchatu]

@peauc Thanks for letting that know. I will check that out.