feat(api): Accept project slugs in organization filters#117446
Merged
Conversation
github-actions
Bot
added
the
Scope: Backend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
JoshFerge
reviewed
Jun 11, 2026
| class OrganizationParams: | ||
| PROJECT_ID_OR_SLUG = OpenApiParameter( | ||
| name="project_id_or_slug", | ||
| PROJECT_SLUG = OpenApiParameter( |
Member
There was a problem hiding this comment.
if we're intending to drop this it we can probably just remove this from the docs
JoshFerge
reviewed
Jun 11, 2026
| type=int, | ||
| description="""The IDs of projects to filter by. `-1` means all available projects. | ||
| type=str, | ||
| description="""The IDs or slugs of projects to filter by. Project slugs are unique within each organization. Omit this parameter to include all accessible projects. `-1` is also accepted. |
Member
There was a problem hiding this comment.
should we say """
-1 is also accepted to include all accessible projects?
"""
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
gricha
added a commit
that referenced
this pull request
Jun 12, 2026
Add a shared project ID-or-slug parser and DRF field for endpoints that explicitly opt in to accepting either identifier. Existing ProjectField behavior stays slug-only by default, while id_allowed=True can now resolve project IDs or slugs within the current organization and permission context. This is the foundation PR for the project slug API split. It only introduces the helper, serializer support, and focused tests; endpoint resolver behavior lands in the stacked follow-up PR #117446. Co-authored-by: OpenAI GPT-5.5 <noreply@openai.com>
Update the organization project resolver so the existing project query parameter can resolve IDs, slugs, or mixed ID-and-slug filters with the same permission checks as project IDs. Preserve legacy projectSlug precedence and align release-permission cache keys with the effective project scope. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
Keep existing endpoints that only understand numeric project IDs working while the new organization resolver accepts project IDs or slugs. Add regression coverage that slugs are ignored by the compatibility helper. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
Allow project query slugs to be parsed when callers pass an empty project ID set from numeric-only compatibility helpers. Keep release-permission cache keys aligned with the same project-resolution precedence. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
Use the ID-or-slug request parser in endpoints that previously inspected only numeric project IDs before resolving projects. This prevents slug-only project filters from becoming membership-wide or org-wide queries. Add endpoint regression coverage for stats, combined rules, and notification actions. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
Document project as the ID-or-slug organization filter and remove the legacy projectSlug parameter from endpoint schemas. Also clarify that -1 means all accessible projects. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
gricha
force-pushed
the
feat/project-id-or-slug-resolver
branch
from
a1c19c9 to
70c0278
Compare
Keep project query documentation focused on numeric project IDs while retaining the all-project sentinel wording. Co-Authored-By: OpenCode <noreply@opencode.ai>
Let project-aware endpoints resolve request project filters through get_projects so mixed numeric IDs and slugs are not truncated to IDs only. Co-Authored-By: OpenCode <noreply@opencode.ai>
Document project as the canonical ID-or-slug query parameter while avoiding promotion of the legacy projectSlug parameter name. Co-Authored-By: OpenCode <noreply@opencode.ai>
Use exact all-project sentinel detection and multi-value groupBy checks so stats v2 still materializes permission-scoped projects when grouping by project. Co-Authored-By: OpenCode <noreply@opencode.ai>
Keep the existing projectSlug OpenAPI parameter available while documenting project as the preferred ID-or-slug query parameter. Co-Authored-By: OpenCode <noreply@opencode.ai>
Centralize legacy projectSlug precedence and blank project filter cleanup for serializers that validate both project parameters. Co-Authored-By: OpenCode <noreply@opencode.ai>
Keep the pre-existing project_id_or_slug query parameter on endpoints that already exposed it while continuing to prefer the canonical project filter. Co-Authored-By: OpenCode <noreply@opencode.ai>
Expose a focused helper for serializers that only need blank project query values treated as absent. Keep the projectSlug precedence helper layered on top. Co-Authored-By: OpenCode <noreply@opencode.ai>
Advertise project ID-or-slug inputs as integer or string in OpenAPI so generated clients can keep passing numeric project IDs while also supporting slugs. Co-Authored-By: OpenCode <noreply@opencode.ai>
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a9dcf02. Configure here.
Treat exact all-project filters as organization-wide listing requests so projectSlug= keeps organization-level notification actions while specific project filters still exclude them. Co-Authored-By: OpenCode <noreply@opencode.ai>
Describe project query parameters as arrays whose items accept project IDs or slugs. This preserves generated client typing without triggering drf-spectacular warnings for many=True on a non-basic schema. Co-Authored-By: OpenCode <noreply@opencode.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Organization project resolution now accepts project IDs, slugs, or mixed ID-and-slug values through the canonical
projectquery parameter. Permission checks still run throughget_projects(), legacyprojectSlugfilters keep existing runtime precedence, existingprojectSlugOpenAPI fields remain available, empty project filters are treated as absent, and stats endpoints preserve permission-scoped project materialization when grouping by project.This PR is stacked on #117445 and intentionally stops at the shared organization resolver, generic API docs, stats, and combined-alert callers. Product-specific endpoint opt-ins are split into separate draft PRs against this resolver branch.