Custom roles and permissions#523
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
|
||
| - **View** gives read-only access to that area. The member can see it but cannot change anything. | ||
| - **Deploy** applies only to Instances. It gives View access plus the ability to deploy changes to an instance, such as updating the sync config and database connections. It does not allow creating or deleting instances. | ||
| - **Manage** gives full access to that area, including creating, editing, and deleting. |
There was a problem hiding this comment.
| - **Manage** gives full access to that area, including creating, editing, and deleting. | |
| - **Manage** gives full access to instances, including creating, editing, deploying and deleting. |
There was a problem hiding this comment.
I added the deploying part but left it generic because Manage applies to more permissions than just instances
|
|
||
| ### Project Scope | ||
|
|
||
| Permissions fall into two groups. Organization-level permissions (Private Endpoints, Team, Billing, and Organization settings) always apply across the whole organization. Project-level permissions (Projects, Instances, Instance logs, Alert Rules, and Notification Rules) can be scoped to all projects or to a specific set of projects that you choose. |
There was a problem hiding this comment.
Aren't there 3 groups? Organization, Project, Instance? Project-level permissions just being quite minimal. From the UI breakdown we have these 3 groups (e.g. in the permissions dropdown) and it aligns nicely with the high level hierarchy https://docs.powersync.com/tools/powersync-dashboard#hierarchy-organization-project-instance
|
|
||
| A project-scoped member is granted their permissions inside the selected projects and has no access outside them. The Manage level on Projects is only available on roles scoped to all projects, since creating and deleting projects is an organization-scoped action. | ||
|
|
||
| ### How Permissions Appear in the Dashboard |
There was a problem hiding this comment.
Do we really need this? Feels a bit like AI generated info overload. Feels intuitive enough that if a user doesn't have permission they will in some way be blocked - I also don't think we should say something like "will stay visible but disabled" explicitly, because we might not be consistent with that or choose a different means to block them for some cases?
3 participants
Summary
Adds a Roles and Permissions section to the PowerSync Dashboard page, covering built-in roles, custom roles, the permissions table, access levels, and project scope.
Changes
AI note
I used Claude to research the custom roles implementation and cross-check the permissions and access levels against the source (the permission catalog and role compiler), so the table reflects what the code actually grants.