careful-honey-27437
05/24/2025, 9:24 PMbrief-egg-61061
05/24/2025, 9:24 PMbrief-egg-61061
05/24/2025, 9:24 PM// Edit and view access for admin group to all reports reports:finance#edit@(groups:admin#member) reports:community#edit@(groups:admin#member) reports:marketing#edit@(groups:admin#member) reports:finance#view@(groups:admin#member) reports:community#view@(groups:admin#member) reports:marketing#view@(groups:admin#member)
And the group membership: groups:admin#member@Neel // Neel is the admin (sysadmin)
You would generalize this pattern for your own resource types and actions, ensuring that the "sysadmin" group (or user) is granted all necessary permissions across all namespaces and resources. This way, any user added to the "sysadmin" group will have super-user access everywhere. The specific implementation will depend on your resource structure and the namespaces you define in your Ory Permissions configuration. For more details, see the RBAC with Ory Keto guide: [RBAC with Ory Keto](https://www.ory.sh/docs/keto/guides/rbac#rbac-with-ory-keto). If you are using the Ory Permission Language (OPL), you can also define global rules that grant all permissions to users in the "sysadmin" group. The knowledge sources do not provide a full OPL example for this scenario, but the principle is the same: define a group, assign users, and grant that group all permissions in your rules. If you need to update your configuration, you can use the Ory CLI to import or update your permission rules as described here: [Configure Ory Permissions](https://www.ory.sh/docs/guides/cli/configure-permission-service). If you need more specific OPL code or a broader example, please let me know!