2025-12-03 19:59:44 +05:30

6.6 KiB

Raw Blame History

User Notification Preferences

Overview

Individual users can now control their notification preferences across three channels: Email, Push, and In-App notifications.

Features Implemented

✅ Backend

Database Schema
- Added three boolean fields to users table:
  - email_notifications_enabled (default: true)
  - push_notifications_enabled (default: true)
  - in_app_notifications_enabled (default: true)
- Migration file: 20251203-add-user-notification-preferences.ts
User Model Updates
- Re_Backend/src/models/User.ts
- Added fields: emailNotificationsEnabled, pushNotificationsEnabled, inAppNotificationsEnabled
API Endpoints
- GET /api/v1/user/preferences/notifications - Get current user's preferences
- PUT /api/v1/user/preferences/notifications - Update preferences
- Controller: Re_Backend/src/controllers/userPreference.controller.ts
- Routes: Re_Backend/src/routes/userPreference.routes.ts
- Validator: Re_Backend/src/validators/userPreference.validator.ts
Notification Service Enhancement
- Re_Backend/src/services/notification.service.ts
- Now checks user preferences before sending notifications
- Respects individual channel settings (email, push, in-app)

✅ Frontend

API Service
- Re_Figma_Code/src/services/userPreferenceApi.ts
- Functions: getNotificationPreferences(), updateNotificationPreferences()
UI Component
- Re_Figma_Code/src/components/settings/NotificationPreferences.tsx
- Beautiful card-based UI with toggle switches
- Real-time updates with loading states
- Success/error feedback
Settings Page Integration
- Re_Figma_Code/src/pages/Settings/Settings.tsx
- Full-width notification preferences card
- Separate browser push registration button
- Available for both admin and regular users

How It Works

User Experience

Navigate to Settings
- User clicks on Settings in the navigation
View Notification Preferences
- Top card shows three toggle switches:
  - 📧 Email Notifications - Receive notifications via email
  - 🔔 Push Notifications - Receive browser push notifications
  - 💬 In-App Notifications - Show notifications within the application
Toggle Preferences
- Click any switch to enable/disable that channel
- Changes are saved immediately
- Success message confirms the update
Register Browser for Push (separate card)
- One-time setup per browser/device
- Requests browser permission
- Registers the browser endpoint for push notifications

System Behavior

When sending notifications:

// System checks user preferences
if (user.inAppNotificationsEnabled) {
  // Create in-app notification in database
  // Emit socket event for real-time delivery
}

if (user.pushNotificationsEnabled) {
  // Send browser push notification (if browser is registered)
}

if (user.emailNotificationsEnabled) {
  // Send email notification (when implemented)
}

Benefits:

✅ Users have full control over notification channels
✅ Reduces notification fatigue
✅ Improves user experience
✅ Respects user preferences while ensuring critical alerts are delivered

API Documentation

Get Notification Preferences

Request:

GET /api/v1/user/preferences/notifications
Authorization: Bearer <token>

Response:

{
  "success": true,
  "data": {
    "emailNotificationsEnabled": true,
    "pushNotificationsEnabled": true,
    "inAppNotificationsEnabled": true
  }
}

Update Notification Preferences

Request:

PUT /api/v1/user/preferences/notifications
Authorization: Bearer <token>
Content-Type: application/json

{
  "emailNotificationsEnabled": false,
  "pushNotificationsEnabled": true,
  "inAppNotificationsEnabled": true
}

Response:

{
  "success": true,
  "message": "Notification preferences updated successfully",
  "data": {
    "emailNotificationsEnabled": false,
    "pushNotificationsEnabled": true,
    "inAppNotificationsEnabled": true
  }
}

Database Migration

To apply the migration:

cd Re_Backend
npm run migrate

This will add the three notification preference columns to the users table with default value true for all existing users.

Admin Configuration vs User Preferences

Two Levels of Control:

System-Wide (Admin Only)
- Settings → Configuration → Notification Rules
- ENABLE_EMAIL_NOTIFICATIONS - Master switch for email
- ENABLE_PUSH_NOTIFICATIONS - Master switch for push
- If admin disables a channel, it's disabled for ALL users
User-Level (Individual Users)
- Settings → User Settings → Notification Preferences
- Users can disable channels for themselves
- User preferences are respected only if admin has enabled the channel

Logic:

Notification Sent = Admin Enabled AND User Enabled

Future Enhancements

Email notification implementation (currently just a preference toggle)
SMS notifications support
Granular notification types (e.g., only approval requests, only TAT alerts)
Quiet hours / Do Not Disturb schedules
Notification digest/batching preferences

Testing Checklist

User can view their notification preferences
User can toggle email notifications on/off
User can toggle push notifications on/off
User can toggle in-app notifications on/off
Notification service respects user preferences
In-app notifications are not created if disabled
Push notifications are not sent if disabled
UI shows loading states during updates
UI shows success/error messages
Migration adds columns with correct defaults
API endpoints require authentication
Changes persist after logout/login

Files Modified/Created

Backend

✅ src/models/User.ts - Added notification preference fields
✅ src/migrations/20251203-add-user-notification-preferences.ts - Migration
✅ src/controllers/userPreference.controller.ts - New controller
✅ src/routes/userPreference.routes.ts - New routes
✅ src/validators/userPreference.validator.ts - New validator
✅ src/routes/index.ts - Registered new routes
✅ src/services/notification.service.ts - Updated to respect preferences

Frontend

✅ src/services/userPreferenceApi.ts - New API service
✅ src/components/settings/NotificationPreferences.tsx - New component
✅ src/pages/Settings/Settings.tsx - Integrated new component

Implementation Complete! 🎉

6.6 KiB Raw Blame History