Org members inherit access to all projects - #1412
Conversation
|
|
||
| const membership = await getProjectMember(project.id, userId); | ||
| return membership ? project : null; | ||
| const role = await getUserRoleInProject(project.id, userId); |
There was a problem hiding this comment.
key change is here, this was the only place where the wrong function was called: getProjectMember
馃殌 Preview Deployment
Preview will be automatically removed when this PR is closed. |
|
Since org members have access to all projects. They should not get added to all project teams. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 7 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| }), | ||
|
|
||
| listUsersWithAccess: projectProtectedProcedure.query(async ({ ctx }) => { | ||
| return projectQueries.listUsersWithProjectAccess(ctx.project.id); |
There was a problem hiding this comment.
listUsersWithProjectAccess returns the messagingProviderCode it means every user in a project can get the providerCode of someone else and try to login in their place I think.
There was a problem hiding this comment.
looks like it was also the case before but i think it can be fixed
There was a problem hiding this comment.
and why do we need this route?
There was a problem hiding this comment.
Agreed on messagingProviderCode. I鈥檒l remove it from all user-list responses.
We do need this route for per-user budgets. Org members can generate spend without being explicit project members, so listAllUsersWithRoles omits users who need to appear there.
| }); | ||
| const projectMembers = useQuery({ | ||
| ...trpc.project.listAllUsersWithRoles.queryOptions(), | ||
| ...trpc.project.listUsersWithAccess.queryOptions(), |
There was a problem hiding this comment.
why? we also added the coalesced to listAllUsersWithRoles it seems
There was a problem hiding this comment.
Ok It's a bit a confusing but I think:
listAllUsersWithRoles calls listProjectMembersWithRoles, which only returns explicit project members.
listUsersWithAccess calls listUsersWithProjectAccess, whose coalesce also handles org members. Since org members can generate spend, the budget page must use listUsersWithAccess.
|
LGTM |
2 participants
Summary
it one by one. This fixes new users getting stuck on "No project configured" bug.
list unless they were added there explicitly.
role on the project, which wins.
Closes #1173