feat(supergroups): Add assignee summary to supergroups endpoint#113856
feat(supergroups): Add assignee summary to supergroups endpoint#113856
Conversation
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 3104acd. Configure here.
3104acd to
ed86a32
Compare
ed86a32 to
4f4a6d9
Compare
| org_group_ids = set( | ||
| Group.objects.filter(id__in=all_group_ids, project__organization=organization).values_list( | ||
| "id", flat=True | ||
| ) | ||
| ) |
There was a problem hiding this comment.
might be able to combine this query into GroupAssignee?
|
|
||
| actors = [ | ||
| *user_service.get_many_by_id(ids=user_ids), | ||
| *Team.objects.filter(id__in=team_ids), |
There was a problem hiding this comment.
i think we generally still add organization_id=organization.id to be safe in each query
4f4a6d9 to
cc38b36
Compare
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
cc38b36 to
89f9dbb
Compare
89f9dbb to
df71daf
Compare
|
|
||
| if not status_param: | ||
| return Response(data) | ||
| # Filter out resolved groups from the response |
There was a problem hiding this comment.
nit - the original comment gave a but more info here - its not just resolved, we need this query after the call to make sure only matching group_ids come back right? the wording about status preivously was kinda better, unless I am missing somthing and this can only happen with "resolved"?
| def _add_assignees( | ||
| organization: Organization, supergroups: list[SupergroupDetailData] | ||
| ) -> list[dict[str, Any]]: |
There was a problem hiding this comment.
Would it be worth building the whole supergroup serialization into a serializer instead of directly into the endpoint? Maybe not in this pr, but as a general goal?
There was a problem hiding this comment.
yes — very tentative plan is to move some supergroup data into sentry and ref these endpoints to use sentry models. i think that will also make building a serializer for supergroups both necessary and useful in the near future
| *(users_by_id[user_id] for user_id in sg_user_ids if user_id in users_by_id), | ||
| *(teams_by_id[team_id] for team_id in sg_team_ids if team_id in teams_by_id), | ||
| ] | ||
| result.append({**sg, "assignees": serialize(actors, serializer=ActorSerializer())}) |
There was a problem hiding this comment.
Nit: Should we serialize all actors at once instead of per supergroup?
Co-authored-by: Claude <noreply@anthropic.com>
df71daf to
09603d6
Compare
) Add assignee information to the supergroups endpoint. On fetching supergroups from seer, we now also query `GroupAssignee` to construct a list of assignees for each supergroup. I don't expect this to work for extremely large supergroups, but will likely be fine for now. Co-authored-by: Claude <noreply@anthropic.com>

Add assignee information to the supergroups endpoint. On fetching supergroups from seer, we now also query
GroupAssigneeto construct a list of assignees for each supergroup. I don't expect this to work for extremely large supergroups, but will likely be fine for now.