Repository navigation
Conversation
github-actions
Bot
added
the
Scope: Backend
02074e7 to
a6e1350
Compare
| latest_events, serialize(latest_events, user, InboxItemEventSerializer()) | ||
| ) | ||
| } | ||
| # Get titles for each item based on the subject type |
There was a problem hiding this comment.
this ends up being a little complicated to read. i think a longer term solution will be to decouple some of the shared functionality like get_title from the subject registry, but for now this works
There was a problem hiding this comment.
agreed, seems to make sense to have as a function exposed from an inbox item service or subject registry mapping
| latest_events, serialize(latest_events, user, InboxItemEventSerializer()) | ||
| ) | ||
| } | ||
| # Get titles for each item based on the subject type |
There was a problem hiding this comment.
agreed, seems to make sense to have as a function exposed from an inbox item service or subject registry mapping
| if value is not None: | ||
| data[key] = str(value) | ||
| data = convert_dict_key_case(data, snake_to_camel_case) | ||
| last_read_at = obj.inbox_item.last_read_at |
There was a problem hiding this comment.
should we be prefetching this in get_attrs() like we do in InboxItemSerializer? not 100% sure if it currently actually results in extra queries tho
| actor = {"type": "system", "id": None, "name": "Sentry", "avatar": None} | ||
| else: | ||
| actor_user = attrs["user"] | ||
| actor = { |
There was a problem hiding this comment.
Can we use ActorSerializer here to ensure this is consistent with other user objects?
There was a problem hiding this comment.
i don't think we can be consistent here, since ActorSerializer would be missing the avatar. i'll think about this one more
| "avatar": actor_user.get("avatar") if actor_user else None, | ||
| } | ||
| data = {key: value for key, value in obj.data.items() if key != "summary"} | ||
| for key in ("comment_id", "seer_run_id"): |
There was a problem hiding this comment.
Seems wrong for the serializer to need to know what kinds of properties data might have?
There was a problem hiding this comment.
hm i can probably think of something better here. the problem is that we want to conditionally stringify some fields of data as part of serialization, but since data can be anything, we need to identify what fields to stringify here. i'll follow up with a change for each InboxEventData to own it's own data serialization
Load subject titles, event aggregates, and latest events in bulk. Resolve user actors once per page and expose stored summaries with camelCase payload keys. Keep retained events readable when their subject or event registration is removed. Fixes ISWF-3645 Co-authored-by: Codex <codex@openai.com>
a6e1350 to
c301029
Compare
Add serializers for inbox items and events. With this we'll be able to go from model -> api response.
Fixes ISWF-3645