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

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

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

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

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

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