* Add JSON events API endpoint
* Add regression test for event particulars defaults
* Move JSON events API to a dedicated ActivitiesController
The events endpoint served both the HTML day timeline and the JSON API
feed, but the two paths shared no data or behavior — the HTML side uses
DayTimelinesScoped while the JSON side built its own query. Splitting
into ActivitiesController gives the API its own home at
GET /:account/activities.json without dragging in the timeline
before_actions.
Also preloads comment creator in Event.preloaded to avoid an N+1 when
rendering comment eventables in the JSON feed.
- Switch to binary 16 for UUID keys
- Remove AccountScopedRecord base class, all model use binary uuids now
- Fix the search sql to serialize uuids properly
- Patch the MySQL schema dumper to output binary lengths
Also, revert to using a helper method to determine the event action, since this is purely a view concern. Keep method at the event model to identify initial assignments.
This introduces a more dynamic system of activity scoring, to improve
the way bubbles "bubble up" due to their activity. There are a few
different parts we can tune here, and it's likely we'll need to make
adjustments once we get a feel for how this works in practice.
The basic idea here is:
- We assign points for certain types of event that happen on a bubble. A
boost gets 1 point, a comment gets 10 points, and so on.
- These points decay over time, at a rate of 50% per day. So old
activity is worth much less than new activity. Bubbles should rise up
quickly when acted upon, bit will float back down if left idle.
- Some comments can score higher than others: the first comment from
each person on a bubble is worth more (20) because it signals that
more people are getting involved; and comments that follow a comment
by a different author are also worth more (15) because that signals
there's ongoing conversation between people, not just a series of
notes being left by one individual.
In terms of implementation, we persist the score on the bubble
whenever it changes, but we handle the decay on the client side. That
allows us to cache the bubble representation without having to
continually change it while its activity decays.
We also keep a separate `activity_score_order` attribute on the model.
This can be used to sort the bubbles in order of "most active", without
having to think about the decay.
Rob Zolkos