Skip to content

Add optional org_id filter to ListProjectsByUser #1856

Description

@riteeksrivastav

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.goListProjectsByUser) 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions