<UserStory> 1954: Implement Service Refactoring </UserStory>
UserStory #1954
<Changes>
1. Refactored notification handling to persist notifications directly in the datastore instead of maintaining notification collections within User objects.
2. Removed recipient User pointer dependencies from Notification and retained recipient user identification through recipientUserId.
3. Implemented generic observer persistence support in DataStore with shared helper methods for loading and saving observer subscriptions.
4. Added datastore-backed observer management for ServiceManagementService, PaymentManagementService, and InventoryManagementService.
5. Updated attach() and detach() operations to load, modify, and persist observer subscriptions using shared memory mappings.
6. Refactored sendNotification() implementations to create and persist Notification records directly to the datastore for subscribed observers.
7. Updated UserManagementService notification retrieval and deletion logic to operate on datastore notification records filtered by recipient user ID.
8. Removed notification ownership and observer-specific notification APIs from User and Observer classes.
9. Added configurable shared memory growth factor support and updated mapping expansion logic to use centralized configuration values.
10. Removed obsolete NotificationManagementService implementation and updated project configuration references.
11. Added DataStoreLockGuard integration for observer and notification persistence operations to ensure synchronized datastore access.
</Changes>
<Test>
N/A
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
- Add serialize/deserialize support for core models
- Add file-based load/save functions in management services
- Introduce FileManager, Config, Utility and helper utilities
- Persist observer IDs for notification services
- Resolve object relationships during load (services, bookings, invoices, job cards)
- Add controller-level loadSystemData/saveSystemData
- Load data at app startup and save on shutdown
<UserStory> NOT006: Configure Notifications </UserStory>
<Changes>
1. Added notification subscription configuration in CustomerMenu to allow customers to enable or disable notifications for Payment Management Service and Service Management Service.
2. Updated Controller::configureNotifications() to attach or detach the authenticated user from service observers based on selected notification preferences.
3. Refactored Observer interface and User notification handling to support notification delivery through observer subscriptions.
4. Implemented observer attach, detach, and sendNotification logic in InventoryManagementService, PaymentManagementService, and ServiceManagementService to ensure notifications are sent only to subscribed users.
</Changes>
<Test>
Precondition:
1. Customer user is logged into the system.
2. Notification configuration option is available in Customer Menu.
3. Notification-triggering event exists for Payment Management Service or Service Management Service.
Steps:
1. Navigate to Configure Notification Preferences in Customer Menu.
2. Enable notifications for one service and disable notifications for the other.
3. Trigger a notification event for both services.
- Verify that notification is received only from the subscribed service.
4. Change preferences by disabling the subscribed service and enabling the other.
5. Trigger notification events again.
- Verify that notification is received only from the newly subscribed service.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
- Removed observer map from Subject base class
- Removed notify() from Subject interface
- Made NotificationManagementService abstract with pure virtual methods
- Added static observer maps to notification service implementations
- Added attach() and detach() overrides in inventory, payment, and service management services
- Added update() override in User model for observer pattern support
- Updated notification method declarations with override specifiers
joelthomastrenser
Jissin Mathew