Event notifiers used the `mentionees` DB association to exclude mentioned
users from comment/card notifications. Since mentions are created async
via Mention::CreateJob, a race condition meant the mentionee list could
be empty when the event notification job ran first, causing the user to
receive both a comment and a mention push notification.
Use `scan_mentionees` instead, which scans the rich text body directly
for mentioned users without depending on Mention records existing yet.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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.
Instead of delegating. With a polymorphic relationship, relying on a certain
attribute implies doing things like aliasing "mentioner" to "creator" or similar.
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.
Previously when an item was `created`, we'd track the event, update the
summary text, and broadcast the notifications. But now that we have a
draft state, we shold do all of this when it's published instead.
Rosa Gutierrez