You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
High-level requirements for access control
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.
owner
privilege associating the client and the user.The text was updated successfully, but these errors were encountered: