Change category "tracking" subscription to "watching" if I post a reply

Support
1

I’d like the following behavior, but don’t know if it’s possible. I have a “tracking” subscription for a certain category, so I get an email when a new topic is made. I reply in some topics, but not all. I would like to start receiving emails for all replies once I reply in a topic that isn’t mine. Currently, I don’t. I have to check the topic manually, or manually change my subscription to “watching”.

On other forum software that is normal behaviour (emails on every reply after I posted a reply, but not before). Is that possible on Discourse?

I’m running 1.8.0.beta10+57.

2

Have you checked your User Preferences?

2 Likes
3

Yes, that is already set. Something else must be going on then (emailing works fine, tons of notifications for other events).

Does the fact that I set the category on “Tracking” affect it?

4

I did another test in a category which I have on “Tracking”. Created a new topic from the API using the “system” user. The topic is set as “Tracked”. Then I posted a reply. The topic remained as “Tracked” (did not change to “Watching”).

5

Yup, that seems to be the case in my sandbox. If I have the category as Normal, it works, but once you set it to Tracking, it fails to change the topic subscription to watching.

2 Likes
6

That doesn’t sound like expected behaviour, right?

7

Once a user changes the notification level manually it is never overridden. The idea being the user wanted it that way when they set it.

8

And if you wanted to see the code, this is where it is done.
https://github.com/discourse/discourse/blob/master/app/models/topic_user.rb#L40-L52

The TopicUser.where is returning an item, thus it isn’t changing the notification.

You can also see more about said feature in this PR (so you can see how it trickles down to the auto_notification definition.
https://github.com/discourse/discourse/pull/4477/commits/6f1c31d777b5b8817baa29e396cc3c0d646e54fa

9

But, firstly, the two options are conflicting … I also set the option to switch to “watching” all topics where I reply. Then, secondly, it seems it is impossible to achieve what I described in my 1st post, which I deem normal behavior, i.e. notify on first post, and then notify on all replies iff I reply. That is what the two options sound like they should be doing (set category to “tracking” and the auto-swiytch to “watching” on reply).

We are a small-medium size team that relies on both those features. Are you saying that this behavior will not be changed and it won’t be possible?

10

Not unless you set it manually on the topic. That is not really the case here

  • you set the category to tracking, so the default state is to track for every topic in that category

  • when you reply you have the pref set to watch on reply

Neither of those is a manual setting of the notification level so this should work. If it does not it is a bug. Any ideas @cpradio?

11

Surely, the auto-switch to “watching” on reply should take precedence … it’s the more natural thing to expect. Manually replying in a particular topic means a deliberate action taken upon a single item. This is carries more significance (takes precedence) over what was set as “default state” for the category (i.e. the set of all topics). I would want to manually set it back to tracking once it switches to “watching” if I no longer want it, not the other way around.

Or add a checkbox at the bottom of the post edit box when replying that is by default checked if the “auto switch to watching” is enabled, and unchecked if the “auto switch to watching” is disabled … then it’s easier to handle. This is the same as the “subscription” checkbox that other forum software have near the “submit” button in the post edit box.

1 Like
12

Yup, topic state is getting set at visit to the topic.

Here is my test:

  1. As a normal user, set a category to Tracking
  2. As another user, create a topic in said category
  3. Using Data Explorer, query the topic_users table for newly created topic to see what users have a subscription state on it.
  4. Validate that only user with a subscription is the topic owner
  5. Visit the topic as the user from step 1
  6. Immediately re-run Data Explorer query in step 3
  7. Two users now have a topic state for the topic (the user from step 1 and from step 2) – this is the culprit
  8. Reply to topic
  9. Topic state does not change because user has a subscription state for the given topic.

Other details:

User for step 2 has the following preferences set:
Automatically track topics I enter is set to 4 minutes. I did not wait 4 minutes on the topic when visiting. I waited less than 30 seconds before running the query, the topic state happens immediately

When I post in a topic, set that topic to is set to Watching.

Tracked Categories is appropriately set for the category being used in the test.

Possible solution:

Change the auto_notification method to look for a higher subscription state than what is being requested. In this case, the current state would be tracking, and the request would be watching so it should permit the change in state. Or in cases of the state being normal (not sure if this is possible) and the request being tracking, it should change it.

Other considerations:
What should happen if the state is muted (meaning the user muted a category) and then they replied to a topic in the muted category? Should that topic’s state change?

4 Likes
13

This sounds good to me. I think the replying to a muted category topic case, they made their bed, now they get to lay in it :wink:

14

I’m a little surprised at how you guys look at this. To me it makes total sense that if I reply anywhere, then the state of that topic should change to what I set my “auto_switch on reply” to be, especially if it’s higher than what I set the category to be, including muted. If I’m replying anywhere, then most likely that is because I’m interested in the topic … I can always mute a topic back if I really no longer want to participate, which is statistically less likely.

Fine if you don’t see things this way. Could you please advise me on the simplest way for me to maintain a patch on my own install that’s easy to re-apply after upgrades? I’m still new to Discourse, be gentle please. We do need it on our install (I can explain why if you’re interested).

15

The way I read it, @cpradio and @codinghorror agree with you

1 Like
16

Then I need more sleep or more coffee (or both).

To me that implied that if some category is set to muted then topics should not be bumped by the “auto_switch on reply”.

I was arguing it should always change to whetever the “auto_switch on reply” is set to (*), even if the category is muted, because that event (replying) shows intent in a particular case, whereas the category setting is a default for all cases. The former should override the latter (not the other way around like it does currently).

(*) when higher than the category setting

2 Likes
17

Fork Discourse, create a branch, make the change, submit change as a PR to Discourse. Point your instance to the branch in the meantime.

2 Likes
18

How exactly do I point my Discourse install to my github fork branch? I presume some change to app.yml? (still new to Discourse)

19

Honestly, I haven’t done that part a lot, but I imagine it is in web.template.yml, this part in particular.

I usually just wait for the PR to be merged (it doesn’t typically take a long time)

      cd: $home
      hook: code
      cmd:
        - git reset --hard
        - git clean -f
        - git remote set-branches --add origin master
        - git pull
        - git fetch origin $version
        - git checkout $version
1 Like
20

Makes sense. For now I’ll wait for you to implement it since you’ve done the previous feature too (I’m also not familiar with the Discourse code yet; also have little to no love for Ruby :smiley:)