Add per-topic prompt checklist#17
Merged
Merged
Conversation
Staff can attach a checklist of items to a single topic from the topic admin (wrench) menu via a dedicated "Prompt Checklist" entry (separate from "Moderator Actions"). When any user, including staff, replies to that topic, a modal pops up first and they must tick every item before the reply is allowed through. Acceptance is recorded per-topic-per-user with a version, so a staff edit bumps the version and re-prompts previously-accepted users. Storage: - Topic custom field mod_topic_prompt_checklist (json): items, version, button_label, updated_at. - User custom field mod_topic_checklist_accepted (json): map of topic_id => accepted_version. Server: - New staff-gated routes GET/PUT/DELETE /topic/:topic_id/prompt-checklist in the existing checklist controller, reusing parse_items for the index-keyed-hash shape the browser form-encodes. - owed_checklist_for(user, topic_id:) now considers per-topic checklists when topic_id is supplied; priority: targeted > per-topic > global. /checklist/owed?topic_id=... carries the new kind:topic result with the topic id. - Existing POST /checklist/accept handles kind:topic and records the clamped accepted version into the user map. - topic_view serializer exposes the per-topic checklist for the editor modal's initial load. Frontend: - New initializer registers the topic-admin-menu entry via addTopicAdminMenuButton. - New modal mod-topic-prompt-checklist-modal.gjs lets staff load / edit / save / clear the per-topic checklist; save bumps version and shows a toast. - Composer gate in precheck-prompt.js passes topic_id to refreshOwedChecklist when replying. - The user-facing modal mod-first-post-checklist.gjs already passes kind and id through to /checklist/accept. Tests: - spec/requests/topic_prompt_checklist_spec.rb covers staff CRUD, 403 for regular users, the topic_id query on /checklist/owed (per-topic gating + clamp + version bump + priority over global, yields to targeted), accept-with-kind-topic, and the topic_view serializer. - spec/system/topic_prompt_checklist_spec.rb walks the staff editor flow and the user reply flow end-to-end, with screenshots 171-180. Docs: - New docs/topic-prompt-checklist.md. - README, features.md, testing.md updated. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…n tests The :json user custom field can occasionally come back as a JSON-encoded string in the request lifecycle (separate from the freshly-set Hash path), so JSON.parse it when needed and treat any non-Hash value as empty. Co-Authored-By: Claude Opus 4.7 <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
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.
Add per-topic prompt checklist feature
Staff can attach a checklist of items to a single topic from the topic
admin (wrench) menu via a dedicated "Prompt Checklist" entry (separate
from "Moderator Actions"). When any user, including staff, replies to
that topic, a modal pops up first and they must tick every item before
the reply is allowed through.
Acceptance is recorded per-topic-per-user with a version, so a staff
edit bumps the version and re-prompts previously-accepted users.
Storage:
version, button_label, updated_at.
topic_id => accepted_version.
Server:
in the existing checklist controller, reusing parse_items for the
index-keyed-hash shape the browser form-encodes.
checklists when topic_id is supplied; priority: targeted > per-topic
the clamped accepted version into the user map.
editor modal's initial load.
Frontend:
addTopicAdminMenuButton.
edit / save / clear the per-topic checklist; save bumps version and
shows a toast.
refreshOwedChecklist when replying.
kind and id through to /checklist/accept.
Tests:
403 for regular users, the topic_id query on /checklist/owed
(per-topic gating + clamp + version bump + priority over global,
yields to targeted), accept-with-kind-topic, and the topic_view
serializer.
flow and the user reply flow end-to-end, with screenshots 171-180.
Docs:
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com