Comments are a bit complicated because they tie into several generic systems that span model types:
Comment: The root comment model, which can be attached via source_entity_id to a deck, card, or post.
This is further complicated by the fact that the Deck model a comment is attached to is likely a snapshot (and cards can have versions, as well, although we haven't had any Reborn errata yet).
Streamable: This generic type is used to generate "entity IDs" which are globally-unique identifiers assigned to cards, decks, posts, and comments (e.g. all things that can show up in the homepage recent activity "stream")
Subscriptions (same file as Streamable), which are used to track which decks, cards, and posts users have commented on (or opted into a subscription without commenting) so that the site can notify them of updates.
On the legacy site, comments had multiple entrypoints:
In other words, this is a bit of a mess that I haven't gotten around to architecting for the new API-driven site yet.
Requirements
[x] Comment CRUD
[x] GET /comments/{entity_id} paginated listing endpoint
[x] POST /comments/{entity_id} creation endpoint
[x] DELETE /comment/{comment_entity_id} user or moderator deletion logic
[x] PATCH /comment/{comment_entity_id} user or moderator update logic
[x] Managing subscriptions
[x] Add "last seen entity ID" output to card and deck detail views if the user is authenticated
[x] Endpoint to update the last seen entity ID for a given entity ID (card or deck; support posts?)
[x] Endpoint to subscribe or unsubscribe to a given entity ID (restricted to cards or decks; support posts?)
[x] Full test coverage
Should this task include support for the homepage stream and subscription notifications? I'm not super sure how to handle that stuff yet, but if I don't include it then people are going to receive a huge number of notifications when I do eventually enable it. See #10.
onecrayon
commented
1 year ago
The most-requested feature!
Comments are a bit complicated because they tie into several generic systems that span model types:
source_entity_idto a deck, card, or post.On the legacy site, comments had multiple entrypoints:
In other words, this is a bit of a mess that I haven't gotten around to architecting for the new API-driven site yet.
Requirements
/comments/{entity_id}paginated listing endpoint/comments/{entity_id}creation endpoint/comment/{comment_entity_id}user or moderator deletion logic/comment/{comment_entity_id}user or moderator update logicShould this task include support for the homepage stream and subscription notifications? I'm not super sure how to handle that stuff yet, but if I don't include it then people are going to receive a huge number of notifications when I do eventually enable it. See #10.