I'll have a look at this, see if I can figure out how this works!
@ThomasRoest let me know if you want to brainstorm here how to handle this. It's interesting that there are several matrixes of subscriptions here:
Not sure the data model we should approach here, but it's probably a new table - open to ideas there though.
A secondary use case here that would be awesome is to disable the in-app "X has joined your community" notifications that we send to community team members. I'd want per-community control over that specifically (I'm the admin of the React community, which has 14k members, so almost all of my notifications are about new members)
We could add a different section to user settings called Community owner preferences, maybe with a select to set notifications for each community.
starting with checkboxes for
[] Email me if someone requests to join my community
[] Email me if someone joins my community
or maybe add community owner preferences and community team member preferences
How about Community notification preferences with a section per community where you are a team member or admin. Within each section you'd need checkboxes like you mentioned, except we don't currently send emails for new joins in a community, those are only in-app. Let's scope this to just eliminate unwanted emails, and have a checkbox to turn off the email me if someone requests to join my community email notifications.
In the future we can add more rows for notification types and more columns for delivery methods (eg email vs in-app)

This is what I came up with, let me know what you think. Also, do both team members and admins get an email if someone requests to join?
@ThomasRoest this looks like the right direction, yep! I'll probably jump in with some styling fixes if that's cool, once we're closer to ship. And right now both team members and admins get emails. See athena/queues/private-community-request-sent.js - now that I'm poking around there, we might as well also add the same option for requests to private channels. It's probably not worth trying to have per-channel settings, so maybe we can have a global setting for getting emails when a user requests to join any private channel in the community
coming back to the model for this, would it be ok to add a new field to the usersSettings table?
Pretty much like this migration in api/migrations/20171103014955-add-mention-notification-settings.js, for example:
notifications: {
types: {
requestToJoin: {
email: true,
},
},
},
That model won't work though, right? Since you could have per-community differences in that setting?
We might want to store it on the usersCommunities record, perhaps...pinging @mxstbr for extra brainpower on how to model this
Most helpful comment
I'll have a look at this, see if I can figure out how this works!