mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-05-06 10:30:31 +08:00
029519ce15
What is the problem? - The chat plugin routes thread message requests through `/chat/api/channels/:channel_id/threads/:thread_id/messages`, where `channel_id` is part of the URL hierarchy. - `Chat::ListChannelThreadMessages` ignores the `channel_id` route parameter entirely, looking up threads globally via `thread_id` alone in `fetch_thread`. - This violates REST hierarchy semantics — a request with a mismatched `channel_id` still succeeds — and is inconsistent with every other thread-scoped service (`Chat::LookupThread`, `Chat::UpdateUserThreadLastRead`, etc.) which all scope by both IDs. - Additionally, unlike peer services, it does not enforce that threading is enabled for the channel. What is the solution? - Add `channel_id` to the service contract with presence validation. - Scope `fetch_thread` by both `thread_id` and `channel_id` so mismatched pairs return a 404. - Add a `threading_enabled_for_channel` policy check after `can_view_thread`, matching the pattern in `Chat::LookupThread` (with `thread.force` support for forced threads like AI bot DMs). - Add the corresponding `on_failed_policy` handler in `Chat::Api::ChannelThreadMessagesController`. - Update `ChatSDK::Thread#messages` to resolve and pass `channel_id` to the service, and handle the new policy failure. |
||
|---|---|---|
| .. | ||
| channel.rb | ||
| message.rb | ||
| thread.rb | ||
