Skip to content
This repository has been archived by the owner on Feb 23, 2022. It is now read-only.

Add endpoints for getting and setting workspace user roles #419

Closed
jjnesbitt opened this issue Jul 2, 2020 · 2 comments · Fixed by #430
Closed

Add endpoints for getting and setting workspace user roles #419

jjnesbitt opened this issue Jul 2, 2020 · 2 comments · Fixed by #430
Assignees

Comments

@jjnesbitt
Copy link
Member

Prerequisite functionality for multinet-app/multinet-client#107

This would be a pair of endpoints that would look something like:

  • GET /api/workspaces/{workspace}/permissions
  • PUT /api/workspaces/{workspace}/permissions

The data model for each of these would contain a list of users, and their permission on the workspace. Something like:

[
  {
    user: <sub>
    role: <'reader' | 'writer' | 'maintainer' | 'owner'>
  },
  ...
]

The workflow for modifying the permissions of a workspace would be as follows:

  1. Retrieve list of users with their respective roles
  2. Modify list
  3. Call PUT to set the new permissions

This would obviously be gated behind the owner role on a workspace.

@waxlamp
Copy link
Collaborator

waxlamp commented Jul 8, 2020

Instead of a list of individual users, would it be better or worse to have something like:

{
  owner: <sub>,
  maintainers: [<sub1>, <sub2>, ...],
  writers: [...],
  readers: [...]
}

and you would modify the permissions structure just by adding/deleting users from the appropriate lists.

What are the pros/cons of doing it each way?

@jjnesbitt
Copy link
Member Author

Instead of a list of individual users, would it be better or worse to have something like:

{
  owner: <sub>,
  maintainers: [<sub1>, <sub2>, ...],
  writers: [...],
  readers: [...]
}

and you would modify the permissions structure just by adding/deleting users from the appropriate lists.

What are the pros/cons of doing it each way?

The approached you laid out is preferred, as we already model the permissions in this way anyway. I'll follow this approach.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants