FIX: when a post is moved copy notifications level (PR #9311)

[lis2]

This is a revert of FIX: Move notification level only when user posted · discourse/discourse@2c01125 · GitHub

More information on meta: When a reply is moved to a new topic, the followers of the previous topic are automatically follower of the new topic as well - feature - Discourse Meta

GitHub

[SamSaffron]

app/models/post_mover.rb

@@ -365,9 +364,7 @@ def copy_topic_users
              )                                           AS last_emailed_post_number,
              GREATEST(tu.first_visited_at, t.created_at) AS first_visited_at,
              GREATEST(tu.last_visited_at, t.created_at)  AS last_visited_at,
-             CASE
-               WHEN p.user_id IS NOT NULL THEN tu.notification_level
-               ELSE :default_notification_level END      AS notification_level,
+             tu.notification_level,

doesn’t this need deleting?

 LEFT OUTER JOIN
           (
             SELECT DISTINCT user_id
             FROM posts
             WHERE topic_id = :new_topic_id
           ) p ON (p.user_id = tu.user_id)

[lis2]

I don’t think so, it is still used here https://github.com/discourse/discourse/blob/444744dc665d5ada5e58040342eb72ac3221e6fd/app/models/post_mover.rb#L345

[lis2]

we can move it back as select instead of join FIX: Move notification level only when user posted · discourse/discourse@2c01125 · GitHub

[gschlager]

I think having it in the SELECT was a little bit faster than doing the JOIN. It might be worth looking at the explain plan of both queries and use the faster one.

[SamSaffron]

app/models/post_mover.rb

@@ -342,9 +341,12 @@ def copy_topic_users
                               notifications_changed_at, notifications_reason_id)
       SELECT tu.user_id,
              :new_topic_id                               AS topic_id,
-             CASE
-               WHEN p.user_id IS NULL THEN FALSE
-               ELSE TRUE END                             AS posted,
+               EXISTS(
+                 SELECT 1
+                 FROM posts p
+                 WHERE p.topic_id = :new_topic_id
+                   AND p.user_id = tu.user_id

I think it auto optimises, but you might as well do a limit 1

once done feel free to merge

[gschlager]

yes, EXISTS aborts the subquery as soon as one row is found

The subquery will generally only be executed long enough to determine whether at least one row is returned