generated from curveball/starter
-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Milestone
Description
High-level requirements for access control
- Users should only be able to see projects they were given explicit access to.
- The type of access you have in a project is either 'member' or 'owner'. If you are a member, you can enter time in the project (but not see anyone else's). If you are an owner, you can see everything, and invite new people into the project.
All of this should be handled by a12n-server groups and privileges ideally. This might down the road create some challenges, but I would like a12n-server to be very capable as a store for access control lists.
- When a user creates a client, automatically assign a
ownerprivilege associating the client and the user. - Add an endpoint in the API that lets a user add a different user (by principal uri) to a project and assign a specific privilege (logger, admin, owner). (New Endpoint: Add a Person to Project #47)
- Restrict the client list to only return clients that the user has access to. This change needs to apply to both the 'list', but also anything else that fetches information about clients. Typically we do this work in controllers, but I worry that's not wise here given that we'll need to duplicate this logic in a lot of places.
- Do the same for projects
- Restrict operations further based on which specific role a user has on a client/project. For example, only owners can invite other users. Only admins and owners can see other people's entries. Everyone can submit to a project they have access to.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
In Progress