-
Notifications
You must be signed in to change notification settings - Fork 8
Open
Labels
component: adminAdministration related functionalityAdministration related functionalityenhancementNew feature or requestNew feature or request
Description
Feature Overview
Is your feature request related to a problem? Please describe.
As an admin usher user, I would like to have APIs available to manage Permissions. Some of the APIs are already implemented, this issue should complete the missing APIs.
API Design
| Status | URL | Auth | Params | Notes |
|---|---|---|---|---|
| ✅ | GET /clients/client_id/permissions |
bearerAdminAuth | client_id optional: query param | List Permissions |
| TODO | GET /clients/client_id/permissions/:permission_key |
bearerAdminAuth | permission key: path, required | Get a Permission |
| ✅ | POST /clients/client_id/permissions |
bearerAdminAuth | Permission attributes: body | Create a new Permission |
| TODO | PATCH /clients/client_id/permissions/:permission_key |
bearerAdminAuth | Permission name and/or description: body | Update existing Permission |
| TODO | DELETE /clients/client_id/permissions/:permission_key |
bearerAdminAuth | permission key: path, required | Delete a Permission |
Implementation Notes
- The source files should be placed in the
src/api_endpoints/permissionsfolder. - For the Create Permission API, the
clientkeyattribute should be optional - The Permission object should return both client key and the client id attributes
Questions
- Should the PATCH API to update a permission allow for updating a client key? I can see arguments for either case. Maybe we say no to start to keep things simple? As if you want to "move" a permission from one client to another is really not a common use case , or one we want to support.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
component: adminAdministration related functionalityAdministration related functionalityenhancementNew feature or requestNew feature or request