General merit workflow

This is an explanation of how does merit process reputation starting from an HTTP request made to an endpoint with associated rules[1]. It's meant for merit developers, not directly helpful for application set up.

1. Merit sets an application-wide after_filter, which creates a merit_action for the request if that controller/action pair has associated rules.

2. Controller after_filter tells MeritAction class to process its unprocessed activity (will typically be the newly created merit_action). It can be done synchronously (default) or as a background job.

3. merit_action asks a judge to grant reputation, given the sash and rule in question.

4. The judge will grant or remove badges and points from its sash according to rule[1] conditions, logging all its activity.

[1] Reputation rules are set in the application via the DSL defined in files rules_{badge|points|rank}_methods.rb

How is each database table used?

Merit installs the following tables for the app:

1. merit_actions is meant for internal merit usage. It is the log of "meritable" actions and who triggered them, so that it can then compute per action if points or a badge is to be granted to someone.
2. sashes defines the Sash model, which has a one-to-one relationship with your "meritable" resources. It has some internally used methods, and it avoids join models.
3. badges_sashes is a relation table between Badges and "meritable" resources. There's only one join model per app, no matter how many meritable resources it has, thanks to the Sash model. Sash indirection should be invisible for the application and should not be used.
4. merit_score_points holds an entry for each point granting/removing, with a num_points integer and an optional log string. They belong to merit_scores which is an indirection between meritable resources and points, which holds the different categories for which a meritable resource may be scored.
5. It also adds new attributes on each resource: sash_id and level.
6. merit_activity_log is a join model between merit_actions, and badges_sashes and merit_score_points, which encodes which reputation was changed per action. Through database relations, one can reconstruct every change to every sash per action triggered on the app.

Models diagram (~> 1.5.0)