You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Theres a bunch of places where we are only supporting numeric project IDs in endpoints. For example, on the organization_events endpoint. Every place that we accept a numeric project ID, assuming an organization is available (which should be 100% of the time), we need to also accept a project slug for the same value. You can see how this is done in the api/bases/project.py.
You can grep on OrganizationParams.PROJECT to get a sense of one piece of scope of this work, but e.g. in the snuba params fetch these need to be one unified approach to fetching projects (using just the 'project' param vs multiple different narrowly typed params):
slugs = project_slugs or set(filter(None, request.GET.getlist("projectSlug")))
ids = project_ids or self.get_requested_project_ids_unchecked(request)
This should not be an overly complicated thing to fix, it just needs done by someone who can properly test it and ideally someone who's familiar w/ the current generation of code.
Note this probably goes beyond that one param implementation, that was just what I found in a couple minutes of grepping the codebase.
The text was updated successfully, but these errors were encountered:
Theres a bunch of places where we are only supporting numeric project IDs in endpoints. For example, on the organization_events endpoint. Every place that we accept a numeric project ID, assuming an organization is available (which should be 100% of the time), we need to also accept a project slug for the same value. You can see how this is done in the api/bases/project.py.
You can grep on
OrganizationParams.PROJECT
to get a sense of one piece of scope of this work, but e.g. in the snuba params fetch these need to be one unified approach to fetching projects (using just the 'project' param vs multiple different narrowly typed params):This should not be an overly complicated thing to fix, it just needs done by someone who can properly test it and ideally someone who's familiar w/ the current generation of code.
Note this probably goes beyond that one param implementation, that was just what I found in a couple minutes of grepping the codebase.
The text was updated successfully, but these errors were encountered: