Spec: set group default category notification settings

Feature
1

Continuing the discussion from Make members of a group watch a category by default: (splitting out from this topic, because it’s quite old, there’s a bit of noise, and I really want this.)

We have the need to set the default notification settings of groups on our Discourse instance within Mozilla, and I’d like to build the feature upstream because it seems like its something a number of users could benefit from.

I see this being implemented in much the same way that default category notification settings can be set globally, with 4 fields like the following added to the group admin page:

Along with a drop-down specifying how these should interact with user preferences:

And a “message users when their notification levels change” option.

Where multiple groups set defaults on the same category, the higher level of notification should always take priority, as follows: muted < tracking < watching first post < watching.

If the user override preference is set to never:

  1. Users can’t change their notification level

  2. When a user joins a group with category notification defaults specified, these will be applied.

  3. When a user leaves the group, the applied category notification defaults will be reverted to the settings the user had before joining.

  4. If the category notification defaults change while a user is in a group, they will be applied/reverted for existing users.

If the user override preference is set to if higher level:

  1. Users can set their notification level to a higher priority.

  2. will happen unless the user has a higher level of notification already set

  3. will happen unless the user has changed their notification level while in the group

  4. will happen unless the user has set a notification level higher than the new group default

If the user override preference is set to always:

  1. Users can set their notification level to anything

  2. will happen unless the user already has a notification level set

  3. will happen unless the user has changed their notification level while in the group

  4. will happen unless the user has changed their notification level

With “message users when their notification levels change” enabled, a user will be messaged by the system user when they join/leave a group or the group defaults get changed, letting them know what the defaults for the group are, and whether they’ve been applied/reverted in their case or not.

In terms of how this will be achieved technically, a boolean from_group_defaults column can be added to the category_users table, which is true when a users’ category notification level has been set by being a member of a group. This should provide enough information to make the above logic work.

20 Likes
2

Sorry for bumping this topic, but I’d like to know if there has been any work on this spec since the OP?

1 Like
3

I wonder if I should take no comment as implicit approval from the @team… pr-welcome?

There has not, been working on a few other things, although it is still somewhere on my to-do list.

4

It sounds like it would be an unintrusive change, but at the same time it isn’t a common request so it gets those feature creep senses tingling.

Could this be done as a plugin? We’ve did something similar in this outdated plugin:

1 Like
5

Always? So if an org mandates that a certain category have a minimum level of notification, the user can override it? There are existing deployments which use Discourse to disseminate information or policy, alerts are integral to ensuring circulation. If a user can suppress those alerts then this becomes much less reliable.

A compromise would be to have suggested and mandatory options, but that’s going to muddy the waters with further UI fields, notation, or a mixture of the two.

Seems more like the home for this.

5 Likes
6

I am very interested in this plugin, and sympathetic to the case outlined by @steve_pd:

Let me outline my own case, slightly simplified:

  • Announcements. @reps group watch first post of the public “Announcement” category. Users can’t join or leave the @reps group through the Discourse UI.

  • Interest groups. @foo group watch first post of public “Foo” category. We have several such groups. Users can join or leave these interest groups via the Discourse UI.

  • Working groups. @bar group watches every post of private “Bar” category. There are several such groups. Users cannot join or leave via the Discourse UI. We use these as a kind of mailing list, because it’s turned out to be simpler to use and explain than group messages.

Here are some interesting edge cases:

  • I’d like people to be able to watch every post of “Announcements” or “Foo” if they wish to.
  • I’d like people to be able to leave @foo and therefore stop automatically watching the first post of “Foo”.
  • I don’t want members of @bar to be able to change their settings so that they are not watching all the posts of the “Bar” category.

Given all of the above, here’s an option that would be workable in my case:

Ignore a user’s settings, unless they have a higher level of notification than the group defaults, much like the case of multiple groups.

One way to implement this is to provide a site-wide setting like this for the plugin:

  • Allow user settings to override group defaults:
    • Yes, always
    • Yes, if higher level
    • No

If feasible (and desirable), the plugin might provide this setting per group – though if left unset, it should inherit the global setting.

What do folks think?

Edit: I fixed a minor typo

7 Likes
7

This sounds perfect for academic use, to make sure students get all announcements, team members get all internal discussion, …

4 Likes
8

I think this is a very good idea, but I think it’d be clearer if this was just a per-group setting, rather than anything global at all.

2 Likes
10

I’ve edited the original post to (hopefully) make it a bit clearer, and incorporate @alehandrof’s suggestion.

@alehandrof let me know if I’ve got the wrong end of the stick

4 Likes
11

@LeoMcA, I think you’ve got the gist of it. I don’t quite follow the “will happen” conditions in the “if higher level” and “always” lists. I think you’re trying to think through the various combinations of cases, but I found the phrasing confusing. I haven’t had a :coffee: yet, so I may just be groggy.

Two questions, to make sure we’ve thought of them:

  1. What happens if the group’s defaults change? Does the change steamroll the user’s settings, or would it take into account the override setting.

    Let’s say a group’s override setting is set to “Yes, if higher level”. And category “Foo” was set to “Watching first post”. A user had changed his settings for that category to “Watching”. If the group’s default changes “Foo” to “Tracking”, what will happen to the user’s setting? While it remain at “Watching” or will it be changed to “Tracking”?

  2. What is the UX/UI of a user not being able to change the settings on a category? Would the user be allowed to change them only to receive a message that they’ve overridden? Would the UI itself be wholly or partly disabled?

1 Like
12

I think it should take into account the override setting (see the point 4s above, if that :coffee: has kicked in).

It would remain at “Watching”. But if the user hadn’t manually set it to “Watching”, then it would change to “Tracking”.

Good question, I hadn’t considered this one. I imagine partly disabling the UI (with a message telling the user what’s going on) would be best, but that could be a little tricky from a plugin (without some changes in core to enable it, at least).

1 Like
13

All this sounds :ok_hand:

14

Any movement on this? A colleague asked me about how we manage notifications and I’m currently in the process of explaining how my crufty plugin works :slight_smile:

15

Getting there, but my priorities are still around secondary email support, and writing our own internal moderation policy.

4 Likes
16

I needed to implement a subset of these features in a different plugin I’m working on, so decided to spin them out as a separate plugin, as even in this early stage it may prove useful to others (and it makes building upon them, and implementing this whole spec, easier in future):

https://github.com/mozilla/discourse-group-category-notification

The readme explains a lot of the caveats, the biggest of which is probably the lack of a UI.

10 Likes
17

Thanks Leo. This kind of thing is super valuable for using Discourse internally, within a company that has a large number of categories (because of a number of employees). Will give this a shot when we can.

IMO this is something that I feel like Discourse for Teams should enable by default because it’s quite helpful to give users strong defaults. attn @tobiaseigen

In our use case, we use Okta + SAML groups and it’s helped for other services, like Slack, to auto-subscribe team members to their respective channels.

We would like to keep all of the categories open for view, but would like to mute them all otherwise, except for those that are directly relevant to them (based on their group membership).

1 Like
18

That’s still the best approach to specific categories watching on specific group?