Split roles for invite and manage to collaborators

[carlos.franca]

Hi everyone, currently the role for create/edit and invite collaborators is present in the same option, allowing users that have this role can self-promote to admin.

Would be possible split it in two roles or ensure that user non admin not promote another users to admin?

[brian1]

I 1000% agree @carlos.franca—this is super important. We were just walking a client through this, and by grouping these two permissions, there’s no separation of concerns between the ability to invite a collaborator and completely rewire the roles and permissions.

We want to allow someone to invite users without giving them the ability to completely upend the security measures in place through permissions and content governance. @roger

[roger]

Hey @brian1,

This is something we’ve been looking at internally (other customers have had the same request) as part of broader improvements to the permissions system, but I don’t have an ETA yet.

I will specifically flag this issue (of the combined permission for two unrelated actions) for dev attention to see if it’s something we can tackle individually, regardless of other improvements.

In the meantime, if this is an urgent need, I think you can kinda fake it with a plugin that acts as a middleman, letting certain users/roles create invitations without actually giving them that problematic permission.

For example, let’s say you have:

• A current role called “team lead”. You want them to be able to invite users but not self-escalate to super-admin.

You can make a plugin that:

• Would only work for users of the “team lead” role
• Has its own API key, set in its env vars (or wherever you like to keep secrets… but it would be its own hardcoded key, not the currentUserAccessToken passed in from the current user)
• That API key should be linked to its own role (like “Inviter role for plugin”). It would have that permission.
• It’d use it with the CMA to invite new users.
• To the user (the team lead), the plugin would only expose a single text field (the email to invite)
• When a team lead creates an invitation through that system, they’re only sending that email to the plugin. The plugin then handles the actual invitation using its internal checks and its own API key, which is never exposed to team lead.
  • To safeguard that API key, this action should happen in a server route (like a route handler / API route in Next, or a generic API route or serverless func wherever you want it)
  • Make sure it doesn’t get exposed to the client (the team lead’s browser)
• The team lead’s role or permission doesn’t actually change. All they do is submit a plaintext email to the plugin, which handles the rest of it internally.

Hacky? Yes, but I think it could work. Let me know if you need an example.

I’ll also update here if I hear back from the devs about a proper backend fix.

[roger]

Quick update here: Unfortunately, this isn’t an easy change we can make right now.

Just splitting the roles into two wouldn’t be enough, because the inviter could always invite themselves (under a separate email) to become an admin.

To do this properly, we would also have to change the collaborator invitation permission to be limited by role, e.g. “Can edit/invite collaborators of roles _____, ______, ______”.

That would take a bit more work, and is currently not planned. However, let’s leave this feature request open, and if there ends up being more demand in the future we will certainly reevaluate!