To create a fine-grained permission model in Ory, you can follow the iterative process outlined in the [Create a permission model](https://www.ory.sh/docs/keto/modeling/create-permission-model) guide. Here's a simplified version of the process tailored to your specific scenario: 1. Create a list of objects. In your case, the objects could be

User

,

Role

, and

Organization

. 2. Make a list of relationships each object has to other objects. For example, a

User

can have a

Role

within an

Organization

. 3. Define each relation in the Ory Permission Language (OPL). For instance, you might define a relationship that states

User:Bob is Finance of Organization:X

. 4. Make a list of permissions that you want to check. In your case, this could be the

makeRequest

permission. 5. Define each permission in the OPL. For example, you might define a permission rule that states "All members of the Finance role in an organization can make requests". 6. Test your permission model. You can do this manually by creating relationships and checking permissions through the API or SDK, or automate the testing process. Here's an example of how you might define the permission rule in OPL:

typescript class Organization implements Namespace {   related: {     finance: User[]   }    permits = {     makeRequest: (ctx: Context): boolean =>       this.related.finance.includes(ctx.subject)   } }

In this example, the

Organization

namespace has a

finance

relation that includes a list of

User

entities. The

makeRequest

permission is defined as a function that checks if the subject (the user making the request) is included in the

finance

relation. Please note that this is a simplified example and the actual implementation may vary depending on the specifics of your application and use case.

To create a fine-grained permission model in Ory that allows both users with the

Finance

role and users with the

makeRequest

permission to make requests, you can follow the iterative process outlined in the [Create a permission model](https://www.ory.sh/docs/keto/modeling/create-permission-model) guide. Here's a simplified version of the process tailored to your specific scenario: 1. Create a list of objects. In your case, the objects could be

User

,

Role

, and

Organization

. 2. Make a list of relationships each object has to other objects. For example, a

User

can have a

Role

within an

Organization

, and a

User

can have a

Permission

. 3. Define each relation in the Ory Permission Language (OPL). For instance, you might define a relationship that states

User:Bob is Finance of Organization:X

and

User:Bob has makeRequest Permission

. 4. Make a list of permissions that you want to check. In your case, this could be the

makeRequest

permission. 5. Define each permission in the OPL. For example, you might define a permission rule that states "All members of the Finance role in an organization can make requests" and "All users with the makeRequest permission can make requests". 6. Test your permission model. You can do this manually by creating relationships and checking permissions through the API or SDK, or automate the testing process. Here's an example of how you might define the permission rule in OPL:

typescript class Organization implements Namespace {   related: {     finance: User[]   }    permits = {     makeRequest: (ctx: Context): boolean =>       this.related.finance.includes(ctx.subject) || ctx.subject.permissions.includes('makeRequest')   } }  class User implements Namespace {   permissions: string[] }

In this example, the

Organization

namespace has a

finance

relation that includes a list of

User

entities. The

makeRequest

permission is defined as a function that checks if the subject (the user making the request) is included in the

finance

relation or if the subject has the

makeRequest

permission. The

User

namespace includes a

permissions

array that contains the permissions assigned to the user. Please note that this is a simplified example and the actual implementation may vary depending on the specifics of your application and use case.