Updating "Category default notifications" for groups that don't have permission to see the category

Contribute Bug
,

AI-generated summary

The discussion addresses a bug where admins can set category notifications for groups that lack permission to view the category, creating a misleading user interface. jericson highlights that while the system correctly prevents notifications from being sent (due to permission checks during the notification pipeline), the UI allows admins to configure notifications for inaccessible categories, which can cause confusion. For example, an admin can assign a group to watch a private ‘Staff’ category, but the user won’t actually receive notifications, and the tracking preferences show no change. sam confirms that no data leaks occur, as permissions are enforced at the notification delivery stage. The core issue is UX—admins are misled into thinking notifications will be sent, when they are not. The suggestion is to prevent admins from setting tracking preferences for categories users can’t read, either by blocking the action or showing an error during bulk updates. The only potential justification for allowing such settings is if an admin plans to later grant access, but this is not considered a strong enough reason to keep the current behavior.

1

It’s possible to add category notifications (via /g/[group_name}/manage/categories) for categories a group does not have permission to see. For instance, you can set all members of Trust_level_0 to watch the Staff category. There is even a prompt to apply the change historically:

Screenshot 2024-01-09 at 9.57.14 AM
Screenshot 2024-01-09 at 9.57.14 AM627×219 15.6 KB

This would be very bad :tm: if Discourse actually made that change and started showing random users what staff members are saying in private. Thankfully the prompt is a lie. After making this very scary change (on a staging instance) I could impersonate a random user and see they didn’t have this set in their tracking preferences (/my/preferences/tracking/) and don’t get notified of new activity. Category security is working as expected.

That said, when I look at the user’s tracking preferences while logged in as an admin, I see this:

Screenshot 2024-01-09 at 10.14.13 AM
Screenshot 2024-01-09 at 10.14.13 AM553×178 7.19 KB

I can add them to all sorts of private categories, which can cause momentary panic if you don’t know that Discourse is managing things correctly behind the scenes.

I think the right approach would be to disallow admins from setting the tracking preferences for categories users can’t actually read. That means I can’t manually add a category while visiting another user’s profile unless they are in a group that can see the category. And if I use the bulk update to add an entire group to a category, I get an error if the group doesn’t have permission to read the category.

Is there any reason to let admins add notification settings that don’t actually send notifications? The only case I can think where it might make sense is if the admin plans to open up a category in the future and wants to have notifications for the appropriate group to be ready in advance. (But I don’t know if that’s a reasonable thing to do.)

1 Like
2

No need to worry there, the notification pipeline always checks permission at the point we raise notifications.

So in this case no information would leak, we would just set the records up and if, by chance, the user gains visibility by becoming staff, they would auto watch.

Feels like this is mostly around improving the UX so it does not lie to the admin about what is going to happen.

1 Like
3

Right. The user has no idea this is going on, but the admin (especially an admin who is used to software that might screw up something like this) would need to dig into something (email logs, impersonating another user, testing on staging, etc.) to verify that no notifications are actually sent.

1 Like