mirror of
https://github.com/discourse/discourse.git
synced 2026-08-06 13:08:40 +08:00
Small action posts (closing, opening, pinning, archiving, category changes, auto-close, etc. — post_type 3) no longer count toward a topic's counters or unread tracking. They still occupy a post_number so the post stream stays gapless, but they contribute to nothing: not highest_post_number, highest_staff_post_number, posts_count, last_posted_at, last_post_user_id, word_count or bumped_at, and they never mark a topic unread or publish unread updates — for regular users and staff alike. Previously this exclusion only applied to private messages. Because small actions advanced highest_post_number, a topic whose only new post was a small action (say an auto-close at the end of a thread) was treated as unread: the nav "Unread (N)" badge counted it while /unread did not list it — the "Unread (N) but /unread is empty" phantom reported in https://meta.discourse.org/t/-/403986. More broadly, routine administrivia such as bulk closes and auto-close timers should not notify watchers or inflate reply counts (https://meta.discourse.org/t/-/404058). How it works: - Topic.next_post_number assigns small actions a post_number but advances no counter (whispers bump only the staff counter; small actions bump neither). - Topic.reset_highest / reset_all_highest! exclude them via two shared SQL fragments — public_post_types_sql (no whispers, no small actions) and staff_post_types_sql (no small actions) — collapsing the old regular-vs-PM branches into one. - PostCreator skips last_posted_at / last_post_user_id / word_count / bumped_at and the user post count for small actions; PostDestroyer's last-post lookup skips them too. - TopicTrackingState / PrivateMessageTopicTrackingState#publish_unread and the PostUpdateTopicTrackingState job return early for small actions. - Category time-based post counts, UserStat#calc_topic_reply_count! and the import.rake topic backfill exclude them as well. - A post-deploy migration recomputes the affected counters for existing topics and clamps any topic_users.last_read_post_number left pointing past the new highest (whisperers to highest_staff_post_number, everyone else to highest_post_number) so nobody is stuck with phantom read state. Keeping the unread count and the /unread list filtering on the same column is a separate, complementary fix that ships on its own. This supersedes the earlier proof-of-concept PRs #40290 and #39093.
45 lines
1.5 KiB
Ruby
Vendored
45 lines
1.5 KiB
Ruby
Vendored
# frozen_string_literal: true
|
|
|
|
describe "Topics unread when closed" do
|
|
fab!(:topics) { Fabricate.times(10, :post).map(&:topic) }
|
|
let(:topic_list) { PageObjects::Components::TopicList.new }
|
|
let(:topic_page) { PageObjects::Pages::Topic.new }
|
|
|
|
context "when closing a topic" do
|
|
fab!(:admin)
|
|
fab!(:user)
|
|
|
|
it "close notifications do not appear when disabled" do
|
|
user.user_option.update!(topics_unread_when_closed: false)
|
|
sign_in(user)
|
|
topic = topics.third
|
|
topic_page.visit_topic(topic)
|
|
topic_page.watch_topic
|
|
expect(topic_page).to have_read_post(1)
|
|
|
|
# Close the topic as an admin
|
|
TopicStatusUpdater.new(topic, admin).update!("closed", true)
|
|
|
|
# Check that the user did not receive a new post notification badge
|
|
visit("/latest")
|
|
expect(topic_list).to have_no_unread_badge(topics.third)
|
|
end
|
|
|
|
it "close notifications do not appear even when enabled (the default)" do
|
|
user.user_option.update!(topics_unread_when_closed: true)
|
|
sign_in(user)
|
|
topic = topics.third
|
|
topic_page.visit_topic(topic)
|
|
topic_page.watch_topic
|
|
expect(topic_page).to have_read_post(1)
|
|
|
|
# Close the topic as an admin
|
|
TopicStatusUpdater.new(topic, admin).update!("closed", true)
|
|
|
|
# The close action is a small action, which no longer marks a topic unread,
|
|
# so the badge does not appear regardless of the topics_unread_when_closed preference.
|
|
visit("/latest")
|
|
expect(topic_list).to have_no_unread_badge(topics.third)
|
|
end
|
|
end
|
|
end
|