After a bit of research on some libraries that offer such functionalities and
implementation details that we could potentially use for this:
### 1. [notifications-rails](https://github.com/jonhue/notifications-rails)
`notifications-rails` provides a modular structure for creating, rendering,
pushing, and managing settings for notifications, with each module backed by
the database. This setup supports on-site notifications with user-configurable
preferences, allowing users to see unread counts and mark notifications as read.
**Database Structure and Requirements:**
- **New Tables:**
- **`notifications`:** Main table storing each notification. Key columns:
- `target_id` and `target_type` (polymorphic association for the recipient)
- `object_id` and `object_type` (polymorphic link to the notification’s
subject, e.g., a `Comment`)
- `metadata` (JSON for additional data), `category` (notification type),
and `read` (boolean for read/unread).
- **`notification_groups` (optional):** Allows bulk notifications for groups
(e.g., subscribers).
- **Modified Tables:**
- **User Table**: Adds optional columns for `read_notification_count` and
`unread_notification_count` to cache unread counts, and `settings` for storing
user-specific notification preferences.
- **Indexes:**
- Indexes on `target_id`, `target_type`, and `category` for quick lookups in
the `notifications` table.
**Database Workflow:**
1. **Creating Notifications:** Notifications are inserted into `notifications`
with details on target, subject, metadata, and category.
2. **Marking as Read:** Updating `read` marks notifications as read, and
`unread_notification_count` can be adjusted for caching.
3. **Bulk Notifications:** The `notification_groups` table can manage batch
notifications by defining recipient groups.
### 2. [noticed](https://github.com/excid3/noticed)
`noticed` offers individual and bulk notifications, supporting multiple
delivery methods, such as ActionCable for real-time updates. It’s suitable for
creating on-site notifications tied to specific events, each managed through
ActiveJob for asynchronous processing.
**Database Structure and Requirements:**
- **New Tables:**
- **`notified_events`:** Logs each event that triggers notifications. Key
columns:
- `type` (event type, e.g., “NewCommentNotifier”)
- `record_id` and `record_type` (polymorphic association to link with the
event’s subject, e.g., `Post`)
- `params` (JSON to store event details, like message and URL).
- **`notifications`:** Links notifications to events and tracks each
recipient. Key columns:
- `event_id` (foreign key to `notified_events`), `recipient_id` and
`recipient_type` (polymorphic association for the recipient), and `read_at`
(datetime for read status).
- **Modified Tables:**
- **User Table**: No required modifications, but adding `has_many
:notifications` makes it easier to manage notifications.
- **Indexes:**
- Indexes on `type`, `record_type`, and `record_id` in `notified_events` for
efficient filtering and quick retrieval.
**Database Workflow:**
1. **Logging Events:** Each new event (e.g., a comment) is logged in
`notified_events`, capturing relevant metadata.
2. **Creating Notifications:** Notifications are linked to events in
`notifications`, enabling individual tracking for each recipient.
3. **Read Status:** Users mark notifications as read by updating `read_at`,
enabling quick querying for unread notifications and visual badges.
Hope you find this helpful @gravitystorm
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/1387#issuecomment-2443324208
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/issues/1387/2443324...@github.com>_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
