Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add project access level #154

Closed
rajdip-b opened this issue Feb 26, 2024 · 5 comments · Fixed by #221
Closed

Add project access level #154

rajdip-b opened this issue Feb 26, 2024 · 5 comments · Fixed by #221
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed priority: high scope: api Everything related to the API type: enhancement New feature or request
Milestone

Comments

@rajdip-b
Copy link
Member

Description

Right now, projects are created in a fashion that, to be visible to someone in the workspace, the member needs to have a role association that has the project associated with it in the projectIds array. Similarly, for any external user, the project needs to have isPublic set to true to access it.

We would like to have fine-grained control to be able to handle the following type of access to the project:

  • Any non-user can access a project (public)
  • Any workspace member can access the project (internal)
  • Only selected members via role association can access the project (private)

You can think of this scenario as something that GitLab or GitHub promotes to categorize repository access across teams.

Solution

To implement this, we would like to replace the isPublic field of Project entity with accessLevel. This will be an enum of type AccessLevel that will be defined in schema.prisma. These would be the enum values and associated authority:

  • GLOBAL: Anyone in the world can access the project
  • INTERNAL: Any member in the workspace with READ_PROJECT collective authority will be able to access the project
  • PRIVATE: Only users with role association that has the project's ID in its projectIds field will be able to access this project.
@rajdip-b rajdip-b added type: enhancement New feature or request good first issue Good for newcomers scope: api Everything related to the API labels Feb 26, 2024
@rajdip-b rajdip-b added this to the Release v1 milestone Feb 26, 2024
@rajdip-b
Copy link
Member Author

Add project access level

@rajdip-b rajdip-b moved this to Todo in keyshade-api Feb 26, 2024
@rajdip-b rajdip-b added the help wanted Extra attention is needed label Apr 20, 2024
@rajdip-b rajdip-b pinned this issue Apr 20, 2024
@rayaanoidPrime
Copy link
Contributor

Hi ! I'd like to attempt this one.... also just to be clear about the scope of changes needed for this--- We basically need to change the prisma schema for Project, change the approval , api-key guard , auth logic as well as the logic of all services that touch projects around it and finally the tests right? Please let me know if I missed anything.

@rajdip-b
Copy link
Member Author

Yes, that will mostly be all. You will need to add an enum named ProjectAccessLevel to prisma schema to store the different access levels. And then link it to the project.

Then you will need to update the checkAuthorityOverProject method to make sure you allow/block access to a project accordingly.

I dont think you will need to change the api-key guard file.

@rajdip-b
Copy link
Member Author

rajdip-b commented May 13, 2024

@rayaanoidPrime I'm refactoring the e2e tests for projects into something more readable. I'll notify you when I merge the code so you can take a pull!

EDIT: Here's the PR #215

@rajdip-b rajdip-b moved this from Todo to Under review in keyshade-api May 15, 2024
@github-project-automation github-project-automation bot moved this from Under review to Done in keyshade-api May 17, 2024
@rajdip-b rajdip-b moved this from Done to Queued for release in keyshade-api May 17, 2024
@rajdip-b rajdip-b unpinned this issue May 24, 2024
@rajdip-b rajdip-b moved this from Queued for release to Done in keyshade-api May 24, 2024
@rajdip-b
Copy link
Member Author

🎉 This issue has been resolved in version 1.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed priority: high scope: api Everything related to the API type: enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants