Inbuilt groups for permissions #568
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## dev #568 +/- ##
==========================================
+ Coverage 70.42% 71.30% +0.87%
==========================================
Files 115 116 +1
Lines 9167 9263 +96
==========================================
+ Hits 6456 6605 +149
+ Misses 2711 2658 -53
☔ View full report in Codecov by Sentry. |
| --pretty, | ||
| --show-error-codes, | ||
| --no-strict-optional, | ||
| --ignore-missing-imports, | ||
| --install-types, | ||
| --non-interactive, | ||
| --show-error-context, | ||
| # --show-error-context, |
There was a problem hiding this comment.
What was the reason to comment it out?
There was a problem hiding this comment.
It seemed to show too much context, and the regular does enough to solve most problems :)
| ] | ||
| async def get_all_projects(self, author: str): | ||
| """Get all projects""" | ||
| await self.check_project_creator_permissions(author) |
There was a problem hiding this comment.
Just a silly question.
Does this mean if user who is not in 'project-creators' and would call api route project/all, would get Forbidden exception?
Should user gets the list of all projects he/she is allowed to view?
There was a problem hiding this comment.
Great question! There's a /my equivalent route for that, this was handy for specific applications that need all projects or fail
Inbuilt groups for permissions, allow us to be quicker with group lookups, and create custom groups easier for specific permissions.
This creates group + group_member tables, + adds some plumbing on the ProjectPermissions table.
Would require the pulumi bot to connect to metamist to update group members, probably not a hard task tbh.
When adding tests, I realised the method names and implementations are a bit over the place, so I pulled them apart, renamed a bunch and added cleaner implementations in some places.