#Custom Permissions
1 messages · Page 1 of 1 (latest)
Hi @frosty hawk, thanks for sharing your case.
Here is ours custom permission approach: https://docs.permify.co/docs/use-cases/custom-roles/
If that wouldn’t help, we would love to have a chat and try conduct a solution together. Here is my calendar: https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert
This document highlights a solution for custom roles with the [Permify Schema]. In this tutorial, we will create custom admin and member roles in a project. Then set the permissions of these roles according to their capabilities on the dashboard and tasks.
That might be what I'm looking for, I'm not sure. Is it all right if I go ahead and set up a meeting for next week?
Of course, you can select an available slot for next week.
I think this will work for me, but one quick question: Is there a way to make the assignee a user or a team, not just a user?
Or should I create duplicate role definitions, one for teams and one for users?
Maybe it would help to have a stronger understanding of what we're trying to accomplish with our PoC. The idea is to use Permify as a system for controlling access to resources, such as documents, shared folders, repositories, APIs, and more. ("Resource" is just a generic term, here.) We want to be able to test whether a user has specific types of access to a resource, but we want to allow tenants to determine what those types are. They may want something like a CRUD app, or they may want something more customized.
I'm assuming to accomplish this, we would want to allow tenants to write their own schemas, is that correct?
Actually it depends, If tenants will depend on a central schema, then modifying the one central schema will be enough. However, if the permissions of the tenants are unique and isolated from each other, then yes, they should modify their own unique schemas. In Permify, the only way to modify the schema is by using the ‘WriteSchema’ API endpoint. Could you provide more elaboration about your use case, especially explaining what the terms ‘user’ and ‘tenant’ represent in your system?
Sure. So we're looking at these as the main entities:
- Tenants: Different large organizations within the company, some with their own unique needs.
- Teams: Teams of people within larger organizations.
- Users: Representations of people. The way I envision this, each person will be part of a team.
- Resources: Representing documents, shared folders, APIs, etc. (As mentioned, a generic term for anything we seek to control access to.) These will usually have teams of people with default levels of access to them, and individual users with higher levels of access (e.g., administrators or managers).
- Roles: These should be assignable to either teams or users, and control access to resources.
Does that help?
Yes @frosty hawk, those are very helpful thank you. If you're considering the use of "Multi Tenancy" - which seems to be a great fit for your case - isolating schemas makes sense. In this scenario, each tenant should be able to modify and manage their own schema. If this modification and management are not meant to be done at runtime, then centralizing each tenant and controlling schema management with a few best practice guidelines that we could suggest would likely be sufficient for production operation.
In contrast, if you expect end users to directly change these schemas (without requiring an engineer or developer, possibly from a UI/web page) on runtime, we don't currently have that functionality. Since it's open source, this can be developed from your side to streamline the process. But my suggestion here is that if we could learn more about your use case and discuss it together, we could formulate a best practice solution to make this process smoother.
We're currently working with several large organizations where they often have custom or edge cases that require us to dive deep and find solutions. I feel like this is one of those cases. So, feel free to schedule a call. Here is my calendar again, https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert
Hi, thank you for the response. We're definitely considering multi tenancy - in fact, I think it may be a requirement. I've gone ahead and scheduled a meeting for this Friday so we can discuss it further. Thank you!