Track topic status-change history in a new table - #1
Merged
Conversation
- add TopicStatusChange model + migration - record changes from the admin controller (api_update) and post_created - enforce allowed statuses in the controller Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- new migration adds user_id, post_id, and duration (bigint, NOT NULL), backfilling duration for existing rows from their created_at history - record the acting user (api_update) or triggering post (post_creation) - compute duration as seconds spent in the status being left, chained off the prior change and falling back to topic.created_at Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
For a topic with no existing status-change row, fall back to when the current status was set (its topic_custom_fields row, captured before the change) rather than topic.created_at, so pre-existing topics get an accurate first duration instead of time-since-creation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- format Ruby files per the plugin's .streerc (trailing commas, 100-col wrap); routes/engine/spec were pre-existing violations - add the schema annotation block to TopicStatusChange for the annotations_tests check Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
What
Adds a
community_custom_fields_topic_status_changestable that records a row every time a topic's supportstatuschanges, for audit/analytics.How
TopicStatusChangemodel withrecordas the single writer; no-ops unlessstatusactually changes.PUTcontroller (source: "api_update") and thepost_createdhandler (source: "post_creation").topic_createdis intentionally not recorded.from_status/to_status,assignee_id(the assignee before the change), the trigger (user_idfor api_update,post_idfor post_creation),duration(seconds in the status being left), andsource.durationderives from the prior recorded change, falling back to the status field's set-time (topic_custom_fields) for pre-existing topics, thentopic.created_at. The migration backfills existing rows from history.statusagainstnew/open/snoozed/closed(422 otherwise).Testing
Verified end-to-end against a Discourse dev host (real HTTP PUT + real PostCreator): recording on both paths, trigger/assignee/duration columns, duration chaining + pre-existing-topic fallback, no-row-on-no-change, status enforcement, and migration backfill + NOT NULL. 12/12 checks pass.
🤖 Generated with Claude Code