code-corps-api icon indicating copy to clipboard operation
code-corps-api copied to clipboard

Add property bag of user email subscription settings

Open joshsmith opened this issue 8 years ago • 4 comments

Problem

We should add email subscription settings for a user, possibly as a property bag. For now we can simply add the task suggestions email as the sole subscription we're checking.

This will involve:

  • an EmailSetting model, belonging to a user
  • a controller where you can create and delete settings

joshsmith avatar Oct 10 '17 20:10 joshsmith

Seems like a good place to get started :) I think some discussion is required to proceed. What is your definition of a property bag? If you mean something like EAV I'd be inclined to sway you on this decision, but perhaps you mean something else?

That detail aside, what would a feature spec for this look like?

ghost avatar Nov 24 '17 08:11 ghost

The initial thinking was something like this: http://culttt.com/2015/02/02/storing-user-settings-relational-database/

I'm not sure it's a great idea, though.

As far as what it would actually do, for now we'd probably like the following:

Email me when:

  • [ ] Someone @mentions me in a task or comment
  • [ ] There are recommended tasks for me in my projects

joshsmith avatar Nov 24 '17 17:11 joshsmith

We'll probably be adding to these settings over time. For now they could be simple boolean flags and we'd probably need to query against it when determining whether to send out an email.

It's worth considering that eventually there may be web notifications preferences, too. It's not clear whether this should be considered separately from the email preferences.

joshsmith avatar Nov 24 '17 17:11 joshsmith

The above could end up looking, in practice, more like:

Notification preferences

Any mentions of you in a conversation

  • [ ] Desktop
  • [ ] Email

Email digests

Recommended tasks

  • [ ] Get a list of recommended tasks each week

☝️ this could even have some form of frequency applied to it.

All this is to say that whatever solution we adopt here we may need to massage it heavily in the future to consider things like:

  • whether you receive notifications
  • where you receive the notifications
  • frequency of the notification/digest

It's entirely possible that the notifications should be considered altogether separate entities from digests, though.

joshsmith avatar Nov 24 '17 17:11 joshsmith