Fine grained permission in admin site

Hi there,

I just started my first Webiny website and I’m wondering how is it possible as a business owner to create new users with only specific access like: View and Edit content of created Pages, but not create new Pages nor Menu etc.

We would like to set up different Roles for different profiles of people accessing the Admin site.
Is it possible at the moment ?

If not, could you hint us on where we could deep dive ? (Probable here:


Hi @Saad! That’s a good question :slight_smile: What you are looking for is not possible out of the box, but the foundations for that are already built into the system. I’ll give you some code references and explain our logic, so you can take it from there.

GraphQL Security

Each of our API packages contains a GraphQL schema plugin. That plugin also contains security rules which are implemented using the library.

Here’s a reference to security rules for Page Builder: (btw., each API package in our repo has this graphq schema plugin at the same path, so every package will have src/plugins/graphql.ts if they do something with schema)

As you can see, at the moment they are very simple, and most of the operations are covered by one scope:

// ...
createPage: hasScope("pb:page:crud"),
deletePage: hasScope("pb:page:crud"),
// ...

In the same file you can see how Revisions are configured much better, they have a separate scope for each operation:

createRevisionFrom: hasScope("pb:page:revision:create"),
updateRevision: hasScope("pb:page:revision:update"),
publishRevision: hasScope("pb:page:revision:publish"),
deleteRevision: hasScope("pb:page:revision:delete"),

Once you have these scopes, you use them to create Roles in our admin UI:

That’s how you give users the necessary scopes to execute GraphQL operations.

Now - there is a bug in the system that doesn’t detect all scopes from all the services. That is why you can only see these 3 scopes here. This bug happened when we split our monolith system into separate Apollo Services. We will get on it and fix it in the upcoming days. Once it’s fixed, you will be able to see all scopes from all the services in this list.

So scopes are the smallest “permission” to execute an operation. You assign them to Roles, and you can create user Groups which contain multiple Roles. Once the user logs in, all of his scopes from all roles and groups are stored in his JWT. So whenever you want to perform a check on the API side, you get that data from context.user.

This is everything there is regarding the GraphQL side of things.

React Security

In React apps, you also have access to a User object and his scopes, using useSecurity() hook. Here is a reference to how you use in your app:

And here is an example of how you can render UI elements based on roles/scopes:

Customizing the UI

This one would require you/us to upgrade the existing UI to use the <SecureView> (or another component which checks permissions) in places like these:

Once those components are in place, you will be able to control both UI and API using the scopes/roles/groups from the Admin app. And the same goes for all our apps, not only Page Builder.


This is all possible, however, we’re short on human resources and would LOVE your help. Send us PRs, we’ll be glad to help and give you more guidance, but we ourselves are very busy with other high priority tasks at the moment.

We have an active Gitter chat, so feel free to join us for even faster communication. If you give it a go and start working on improvements, please do open an issue on GH where we can discus the implementation and give you more references, directions, whatever you may need.

Hope this helps, and let us know what you think :slight_smile:

here is an issue to track the scopes bug:

Thanks for your answer, we will definitely look into it!

Hi @Saad, just a quick update.

The PR that fixes all of the mentioned is almost ready to be merged.

Sit tight! :slight_smile:

1 Like

Hi @Saad, we made a smaller release, which included “some” of the fixes that were mentioned in this topic. You can check out the related PR here.

Basically, the thing that wasn’t implemented yet was the fine-grained control. We’ve created an issue which explains what’s left to be done. Hopefully, someone we’ll be able to tackle it soon.