Is your feature request related to a problem? Please describe.
FrontierService.ListProjectsByUser returns every project a user has access to across all organizations, with no way to scope the result to one organization server-side. The request message only carries the user id:
message ListProjectsByUserRequest {
string id = 1;
}
Callers that need "projects of user X within org Y" (a common multi-tenant lookup) have to fetch all of the user's projects and filter by org_id client-side. The sibling RPC ListProjectsByCurrentUser already supports exactly this filter, so the two contracts are inconsistent:
message ListProjectsByCurrentUserRequest {
// org_id is optional and filter projects by org
string org_id = 1;
...
}
Describe the solution you'd like
Add an optional org_id filter to the request, mirroring ListProjectsByCurrentUserRequest:
message ListProjectsByUserRequest {
string id = 1;
// org_id is optional and filters projects by org
string org_id = 2;
}
Semantics:
org_id unset/empty → current behavior unchanged (projects across all orgs), so the change is fully backward compatible on the wire and in behavior.
org_id set → only projects belonging to that organization are returned.
The implementation looks small: the handler (internal/api/v1beta1connect/user.go → ListProjectsByUser) already builds a core/project.Filter, which supports OrgID alongside Principal — the new field just needs to be passed through, plus the proto change in raystack/proton.
Describe alternatives we've considered
- Client-side filtering of the full
ListProjectsByUser response by project.org_id — works, but transfers and transforms all projects across every org the user belongs to on each call.
ListProjectsByCurrentUser with org_id — only works for the authenticated user; it can't be used by a service user resolving another user's projects.
ListOrganizationProjects — scoped to the org but not filterable by user, so it would require intersecting two full listings client-side.
Additional context
We call this RPC from a backend service (service-user credentials) via the Go SDK (frontierv1beta1.ListProjectsByUserRequest) to resolve the projects a given user can access within one specific organization.
Is your feature request related to a problem? Please describe.
FrontierService.ListProjectsByUserreturns every project a user has access to across all organizations, with no way to scope the result to one organization server-side. The request message only carries the user id:Callers that need "projects of user X within org Y" (a common multi-tenant lookup) have to fetch all of the user's projects and filter by
org_idclient-side. The sibling RPCListProjectsByCurrentUseralready supports exactly this filter, so the two contracts are inconsistent:Describe the solution you'd like
Add an optional
org_idfilter to the request, mirroringListProjectsByCurrentUserRequest:Semantics:
org_idunset/empty → current behavior unchanged (projects across all orgs), so the change is fully backward compatible on the wire and in behavior.org_idset → only projects belonging to that organization are returned.The implementation looks small: the handler (
internal/api/v1beta1connect/user.go→ListProjectsByUser) already builds acore/project.Filter, which supportsOrgIDalongsidePrincipal— the new field just needs to be passed through, plus the proto change inraystack/proton.Describe alternatives we've considered
ListProjectsByUserresponse byproject.org_id— works, but transfers and transforms all projects across every org the user belongs to on each call.ListProjectsByCurrentUserwithorg_id— only works for the authenticated user; it can't be used by a service user resolving another user's projects.ListOrganizationProjects— scoped to the org but not filterable by user, so it would require intersecting two full listings client-side.Additional context
We call this RPC from a backend service (service-user credentials) via the Go SDK (
frontierv1beta1.ListProjectsByUserRequest) to resolve the projects a given user can access within one specific organization.