Is confusing since "source" already captures the origin of the notifications. It's
needed to interpret things at rendering time, so we can query things as needed there.
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.
* main:
Indention
@collection is always available when card scoped
Style
Duh, no before destroy commit, but this is still not right!
No long transactions!
But feels more essentially part of the User, so list first
Not related to the other two
Style
Try a slimmer version
We werent using any of the other avatar methods
Dont do a lot of work inside a single transaction
Really liking the new it-style yields in many places
Bump nokogiri from 1.18.7 to 1.18.8
If you intend to deactivate someone, and the process fails mid process,
so you only delete some sessions, or some accesses, you are actually
fine. The system is never left in an incomplete state. And that's really
the only time we should be using transactions with sqlite3 -- to prevent
actual data integrity issues.
The rest of the time, we should optimize for each transaction to be as
quick as possible. The sqlite3 writer lock is the one bottleneck that we
cant afford to overload.
- It does not make sense to scan "event summaries" for notifications.
- Placing them at the message level prevents us from using the generic approach to extract the mentionable content
Instead of delegating. With a polymorphic relationship, relying on a certain
attribute implies doing things like aliasing "mentioner" to "creator" or similar.
Jorge Manrubia