* main:
Fix image icons
Revert "Merge pull request #345 from basecamp/cascade-layers"
Fine tune notifications states
Remove empty helper
Use an icon for the button
Show button on collection page and notif settings
Add involvement types to accesses
Extract a couple components
Add cascade layers to all CSS files
This provides a way to set the level of involvement that a user has with
a collection, and from which we determine the level of notifications to
send. Users can be access-only, watching, or being notified about
everything.
If you're access-only, you won't get an notifications. If you're
watching, you'll only get notifications for the items you're watching
(which includes the items you've been assigned, have commented on, etc).
If you're set to everything you'll get notifications about all activity
in that collection.
This change replaces our previous concept of subscriptions. Where
previously you'd subscribe to a collection to get notifications in it,
now you'll simply set the notification level on your access.
The previous implementation would delete all accesses if the bucket
was not all_access.
I think it's simpler to move the bucket workflow into a separate
Buckets::WorkflowsController, rather than deal with different sets of
params from different forms in the existing BucketsController.
- Rearrange the _tags and _tag partial, so they are properly nested concerns
- Add turbo frames for _tags and _tag
- Load _tag in a separate request, so it's not cached with the card
- Cache _tag using the bubble and the account
- New model behavior: touch Account when tags are added or removed
- New controller action: "new" for taggings toggles, which renders the _tag partial
- Updating taggings responds with a turbo stream response that updates the _tags frame
This is very much a parallel change to what was done with assignments
in #317.
Avoid infinite activity score orders
Items with a zero activity score were getting an activity sorting score
of -infinity, because we base the value on log2(score). Adjusting the
calculation avoids this edge case, by always basing the sorting score on
a non-zero number.
---------
Co-authored-by: Kevin McConnell <kevin@37signals.com>
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.
Jorge Manrubia