Design DbUserPreferences API

[stephenmichaelf]

This includes both read and write.

[stephenmichaelf]

This API is going to be used in several places:

1. PullFromOurDb: Check which filters should be run for each user and against which repository.
2. NotificationDbWriter: I forget why this needs access to Preferences. If the filter generated a notification then shouldn't all of them be written to the DB? If the user didn't want that then they wouldn't have been generated in the first place?
3. NotificationThirdPartyWriter: I believe we want this to check what third parties we should write notifications to for a certain user. This is not in scope for this version of the API.
4. NotificationEmailSender: Check for a given user and repository if emails should be sent.
5. API: The UI will go through a Web API to display the user's preferences as well as allow the user to change their settings. This includes adding and removing filters and choosing if emails are sent.

Other things worth noting:

1. This assumes users will be connected to multiple repositories.
2. Users may also be connected to repositories with many source systems (not just GitHub).
3. We can start to consider if we want authentication to live in here too, my guess is no. If that's the case then we should create a new ticket to design the authentication setup. Given that we are planning to not always use GitHub, we should put some thought into that.
4. Since the repositories will be configured by a site administrator I am going with the assumption that the data for that will be stored elsewhere.
5. This assumes UserPreferences will be initialized when a new user account is created.

There are some things we still need to decide on:

1. For email notifications, should we allow the user to configure them per repostiory, per filter, or some other way?
2. Are we going to scope everything to tenants? If so, that will change the design below.
3. How are new repositories added for a user? This can differ based on if we are multi tenant or not. For instance, the repo admin first has to add the repo to the site and pay for the data to be stored and loaded before a user can be added to that repository. Once the base repository has been added we have some options. Do users have to add themselves to the repo and we piggy back OAuth from GitHub?
4. I think we may need to store the last run time along with the filter. That way for new filters we can let them choose to start from whenver they want? The alternative is that people add new filters and it runs from when they added it (all filters run based on the same last run time). I think it makes more sense to store a date with it so that also if people want to run the filter manually they can and we can update the last run time. I suppose it depends what features we want to allow around running filters.

Given those requirements, my first draft is:

// This is the API for getting and setting preferences.
public interface IPreferencesService
{
	UserPreferences GetPreferences(int userId);
	void UpdateEmailPreferences(int repositoryId, int userId, bool shouldReceiveEmails);
	int AddSearchFilter(int repositoryId, int userId, SearchFilter searchFilter);
	void RemoveSearchFilter(int repositoryId, int userId, int filterId);
}

// Represents all preferences for a user. It contains the user it is for and 
// a list of preferences for each repository that the user is setup for.
public class UserPreferences
{
	User User { get; set; }
	IEnumerable<RepositoryPreferences> RepositoryPreferenceses { get; set; }
}

// A user's specific preferences for a repository. This includes whether or not 
// they should receive email notifications for new notifications in this repository 
// as well as what search filters they care about for the repository.
public class RepositoryPreferences
{
	Repository Repository { get; set; }
	IEnumerable<SearchFilter> SearchFilters { get; set; }
	bool ReceieveNotificationEmails { get; set; }
}

// TODO: Decide what goes in here. It needs to be agnostic of the underlying repository.
// This means it shouldn't be tied directly to how GitHub does querying, I think. We should
// discuss this more.
public class SearchFilter
{
	public int Id { get; set; }
}

Please provide your feedback and constructive criticisms :)

@karelz @ianhays @garfbradaz @safern