raystack / raystack/frontier

Add optional org_id filter to ListProjectsByUser

Open
#1,856 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
344
Forks
47
Avg merge
4d 4h
Merged PRs (30d)
26

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the ListProjectsByUser entry point in internal/api/v1beta1connect/user.go and the corresponding request definition in raystack/proton. Trace how the existing core/project.Filter receives the user Principal, then mirror the sibling ListProjectsByCurrentUser org_id handling. Done means an unset or empty org_id preserves current results and a set value limits results to that organization.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
75/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.