<UserStory> SER005: Update Service Status </UserStory>
<Changes>
1. Integrated Controller with ServiceManagementService to support job completion workflow.
2. Implemented ServiceManagementService::completeJob with validation for technician assignment, job existence, and status transition.
3. Enhanced TechnicianMenu with job selection helper to display assigned jobs, allow index-based selection, and handle invalid choices.
4. Updated TechnicianMenu::completeJob to mark job as completed via Controller and provide user feedback.
5. Added logic to check if all jobs in a booking are completed, triggering invoice generation and customer notification.
</Changes>
<Test>
Acceptance Criteria:
1. Status updates are visible to customers immediately after technician marks job as completed.
Precondition:
1. Technician is logged into the system.
2. At least one active job card is assigned to the technician.
3. Datastore contains valid service bookings linked to jobs.
Steps:
1. Navigate to Technician menu and choose "Complete Job".
- Verify that the system lists active jobs with index-based selection.
2. Select a job card by index.
- Verify that the job status changes from STARTED to COMPLETED.
3. Check customer view.
- Verify that the updated status is reflected in the customer’s booking history.
4. If all jobs in the booking are completed:
- Verify that an invoice is generated and a notification is sent to the customer.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> INV002: Add Stock </UserStory>
<Changes>
1. Added Controller integration with InventoryManagementService to support adding new inventory items and updating existing stock quantities.
2. Implemented InventoryManagementService::addInventoryItem to create new items via Factory and insert them into the DataStore.
3. Implemented InventoryManagementService::addInventoryItemStock to update stock quantities for existing items.
4. Enhanced AdminMenu with options to add new items or update stock quantities, including input validation and confirmation messages.
5. Added helper functions in AdminMenu to display inventory items and handle quantity updates interactively.
6. Included necessary headers (InventoryItem, Factory, iomanip) for new functionality.
</Changes>
<Test>
Precondition:
1. Admin user is logged into the system.
2. Inventory contains existing items with unique IDs.
3. DataStore is accessible and initialized.
Steps:
1. Navigate to Admin Menu and select "Add Inventory Item".
- Verify that the system prompts for part name, quantity, and price.
2. Enter details for a new item with a unique part name and ID.
- Verify that the item is successfully added and a confirmation message is displayed.
3. Attempt to add an item with a duplicate ID.
- Verify that the system rejects the duplicate and displays an error message.
4. Select "Add Quantity" option for an existing item.
- Verify that the system updates the stock quantity and displays the new total in the confirmation message.
5. Navigate to "View Stock Levels".
- Verify that the updated stock quantity is reflected in the inventory list.
</Test>
<Review>
Sreeja Reghukumar
</Review>
<UserStory> SER004: View Service History </UserStory>
<Changes>
1. Added integration between Controller and ServiceManagementService to fetch service bookings by customer ID.
2. Enhanced ServiceBooking model to store technician as a User* instead of a string for richer details.
3. Implemented Controller::getServiceBookingsByUser to return a read-only map of bookings for safe access.
4. Updated CustomerMenu::viewServiceHistory to display bookings in tabular format with aligned columns.
5. Added condition check to show technician name if assigned, otherwise display "Not Assigned".
6. Included booking status and discount percentage in the service history output.
</Changes>
<Test>
Acceptance Criteria:
1. System should fetch real-time status.
2. Status should update automatically when technician changes it.
3. Customer should be able to view history.
Precondition:
1. Customer is logged into the console application.
2. At least one active service booking exists for the customer.
3. Technician has permission to update booking status.
Steps:
1. Navigate to Customer menu and choose "View Service History".
- Verify that the console displays current booking status along with technician assignment.
2. Technician updates the status of a booking.
- Verify that the console view reflects the updated status automatically.
3. Customer views service history again.
- Verify that the history shows the latest status changes.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> INV001: View Stock Level </UserStory>
<Changes>
1. Integrated InventoryManagementService into Controller to provide read-only access to inventory items.
2. Added implementation for InventoryManagementService::getInventoryItems to fetch data from DataStore.
3. Enhanced AdminMenu with viewStockLevels functionality to display inventory details (ID, part name, quantity, price).
4. Updated NotificationManagementService interface to provide concrete implementations for sendNotification, attach, detach, and notify methods.
5. Included necessary headers (InventoryItem, InventoryManagementService, iomanip) for new functionality.
</Changes>
<Test>
Precondition:
1. Admin user is logged into the system.
2. Inventory contains multiple items with varying stock levels.
3. Notification service is active and users are registered.
Steps:
1. Navigate to Admin Menu and select "View Stock Levels".
- Verify that the system displays all inventory items with ID, part name, quantity, and price.
2. Check items with sufficient stock.
- Verify that they are displayed normally without highlighting.
3. Check items with low stock threshold.
- Verify that these items are highlighted to indicate low availability.
4. Trigger a notification for a low-stock item.
- Verify that the notification is sent to registered users successfully.
</Test>
<Review>
Sreeja Reghukumar
</Review>
<UserStory> SER003: Remove Service </UserStory>
<Changes>
1. Added integration between Controller and ServiceManagementService to support service removal.
2. Implemented ServiceManagementService::removeService with validation for service existence and marking as INACTIVE.
3. Enhanced Controller::getServices to return a read-only map of services for safe UI access.
4. Added AdminMenu::selectServicesToRemove helper to list active services in tabular format and capture user choice.
5. Updated AdminMenu::removeService to prompt for service selection, delegate removal to Controller, and display success/failure messages.
</Changes>
<Test>
Acceptance Criteria:
1. Admin selects service ID.
2. System confirms deletion.
3. Service removed from customer menu.
Precondition:
1. Admin is logged into the system.
2. At least one active service exists in the datastore.
3. Customer menu displays available services.
Steps:
1. Navigate to Admin menu and choose "Remove Service".
- Verify that the system lists active services in tabular format.
2. Select a service ID from the list.
- Verify that the system confirms deletion.
3. Check customer menu.
- Verify that the removed service no longer appears.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> SER002: Create Service </UserStory>
<Changes>
1. Added integration between Controller and ServiceManagementService to support service creation.
2. Implemented ServiceManagementService::createService with validation for duplicate service IDs and insertion into datastore.
3. Enhanced AdminMenu with selectInventoryItems helper to display inventory in tabular format, allow selection, and handle exit condition.
4. Updated AdminMenu::createService to prompt for service name, allow inventory selection, capture labour cost, and create service via Controller.
</Changes>
<Test>
Acceptance Criteria:
1. Admin enters new service name.
2. Admin selects required parts for the services.
3. Service created and visible to customers.
Precondition:
1. Admin is logged into the system.
2. Inventory contains at least one active item.
3. Datastore is available for storing services.
Steps:
1. Navigate to Admin menu and choose "Create Service".
- Verify that the system prompts for service name.
2. Select inventory items from the tabular list.
- Verify that inactive items are skipped and active items can be added.
3. Enter labour cost and confirm creation.
- Verify that the service is created successfully and stored in datastore.
4. Check customer view.
- Verify that the newly created service is visible to customers.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> SER001: Assign job to technician </UserStory>
<Changes>
1. Added ServiceManagementService logic to retrieve service bookings and create job cards for assigned technicians.
2. Added UserManagementService support to retrieve technicians by user type and fetch technician details by ID.
3. Connected Controller methods with ServiceManagementService and UserManagementService for service booking retrieval, technician listing, and job card creation.
4. Updated JobCard model to use util::ServiceJobStatus consistently and simplified constructor initialization for assigned and completion timestamps.
5. Added PENDING status in ServiceJobStatus enum for identifying unassigned service bookings.
6. Implemented AdminMenu job assignment flow to list pending service bookings, display available technicians, allow technician selection, and assign jobs for services in the booking.
7. Added notification trigger during job card creation for assigned technicians.
</Changes>
<Test>
Job assignment functionality validation
Precondition:
1. System is running.
2. Pending service bookings are available in the system.
3. Technician users are available in the system.
4. Admin user is logged in and admin menu is active.
Steps:
1. Launch the application and log in as an admin.
2. Select the Assign Job option from the admin menu.
3. View the list of available pending service bookings.
- Verify that pending bookings are displayed.
4. Select a valid service booking.
5. View the list of available technicians.
- Verify that technicians are listed for selection.
6. Select a technician to assign the job.
- Verify that job cards are created for services in the booking.
- Verify that assigned jobs are visible in the technician’s menu.
- Verify that a confirmation message is shown.
- Verify that a confirmation notification is sent to the assigned technician.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> ADM006:Create Combo Package </UserStory>
<Changes>
1. Added ServiceManagementService::createComboPackage to validate package name, included services, and discount percentage before creation.
2. Integrated Controller::createComboPackage to delegate combo package creation to ServiceManagementService.
3. Enhanced AdminMenu::createComboPackages to allow admin input for package name, service selection, and discount percentage.
4. Implemented service validation to ensure only active services are selectable and that duplicate combos are prevented.
5. Added formatted output for service listing with cost calculation and confirmation messages upon successful package creation.
</Changes>
<Test>
Precondition:
1. Admin is logged into the system.
2. At least two active services exist in the system.
3. ServiceManagementService is connected to DataStore for services and combo packages.
Steps:
1. Navigate to Admin Menu and select "Create Combo Package".
2. Enter package name, select two active services, and provide discount percentage.
- Verify that system validates service IDs and ensures discount is between 0 and 100.
3. Attempt to create a package with invalid service IDs or duplicate services.
- Verify that system rejects with appropriate error messages.
4. Enter valid package details.
- Verify that combo package is saved successfully and visible to customers.
</Test>
<Review>
Sreeja Reghukumar
</Review>
<UserStory> SER003: Remove Combo Package </UserStory>
<Changes>
Added integration between Controller and ServiceManagementService to support combo package removal.
Implemented ServiceManagementService::removeComboPackage with validation for package ID and marking state as INACTIVE.
Enhanced AdminMenu with displayComboPackagesWithIndex helper to show packages in tabular format with index.
Updated AdminMenu::selectComboPackage to allow selection of active packages only and return selected package ID.
Updated AdminMenu::removeComboPackage to prompt for selection, confirm removal, and provide success/failure feedback.
</Changes>
<Test>
Acceptance Criteria:
Admin selects package ID.
System confirms deletion.
Package removed from customer menu.
Precondition:
Admin is logged into the system.
At least one active combo package exists.
Datastore is available for storing combo packages.
Steps:
Navigate to Admin menu and choose "Remove Combo Package".
Verify that the system displays available active packages in tabular format with index.
Select a package ID from the list.
Verify that inactive packages are skipped and only active ones are selectable.
Confirm removal.
Verify that the package is marked INACTIVE and removed from customer menu.
Check customer view.
Verify that the removed package is no longer visible to customers.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory>
NOT005: Payment Reminder
</UserStory>
<Changes>
1. Added payment reminder check in Controller::runSystemChecks() to trigger reminder processing during system startup.
2. Implemented PaymentManagementService::sendPaymentReminders() to identify unpaid invoices that exceed the pending payment threshold and send reminder notifications to customers.
3. Added reminder notification logic to include invoice details and stop reminders once invoice payment status changes from Pending to Paid.
</Changes>
<Test>
Precondition:
1. Customer has an invoice with PaymentStatus::PENDING.
2. Invoice age exceeds the configured payment reminder threshold.
3. Application is started and system checks execute.
Steps:
1. Start the application.
2. Allow system checks to run during startup.
3. Navigate to View Notifications.
- Verify that a payment reminder notification is displayed.
4. Open the generated notification.
- Verify that the notification includes the invoice ID and due date.
5. Complete payment for the invoice and restart the application.
- Verify that no further reminder notifications are generated for the paid invoice.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> NOT004: Low Stock Alert </UserStory>
<Changes>
1. Added low stock alert check in Controller::runSystemChecks() to trigger inventory notification processing during system startup.
2. Implemented InventoryManagementService::sendLowStockAlerts() to detect inventory items below threshold, identify admin users, and send low stock alert notifications with item details.
3. Added helper logic to notify all admins when low stock inventory is detected.
</Changes>
<Test>
Precondition:
1. System has at least one admin user.
2. Inventory item exists with quantity below the configured low stock threshold.
3. Application is started and system checks execute.
Steps:
1. Start the application.
2. Allow system checks to run during startup.
3. Navigate to Inventory Menu / View Notifications.
- Verify that a low stock alert notification is displayed.
4. Open the generated notification.
- Verify that the notification includes the part name and remaining quantity.
5. Confirm notification content.
- Verify that the alert was triggered only for inventory items with stock below the threshold.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS001:Login </UserStory>
<Changes>
1. Added login implementation in AuthenticationManagementService to validate username and password from stored user records.
2. Connected Controller::login() with AuthenticationManagementService login logic.
3. Added getAuthenticatedUser() integration in Controller for retrieving the logged-in user.
4. Implemented login flow in UserInterface to collect credentials and validate login.
5. Added role-based menu navigation for Admin, Technician, and Customer after successful login.
6. Added error handling to display "Invalid Username or Password" for failed login attempts.
7. Added required includes and controller member dependency for authentication support.
8. Added a check to create a default admin automatically if no admin exists in the system on startup
</Changes>
<Test>
Login functionality validation
Precondition:
1. System is running.
2. User records are available in the data store.
3. Valid username and password exist for a registered user.
Steps:
1. Launch the application.
2. Select the login option from the main menu.
3. Enter a valid username and password.
- Verify that the entered credentials are validated.
- Verify that access is granted and the correct menu is shown based on user type.
4. Enter an invalid username or password.
- Verify that the message "Invalid Username or Password" is displayed.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
Changes:
- Added Admin Menu display with menu options
- Added Technician Menu display with menu options
- Added menu choice handling using switch case
- Connected menu options to corresponding functions
- Added invalid choice message
- Added logout handling
- Added missing function declarations in TechnicianMenu header
* Added Customer Menu display with all customer options
* Added menu choice handling using switch case
* Connected menu options to corresponding customer functions
* Added invalid choice message
* Added logout option handling
<UserStory> ADM004: Logout </UserStory>
<Changes>
1. Added AuthenticationManagementService::logout to clear authenticated user session.
2. Integrated logout handling in Controller::logout to delegate session termination.
3. Updated AdminMenu::logout and TechnicianMenu::logout to call Controller::logout for consistent session management.
4. Extended TechnicianMenu.h with logout method declaration.
5. Ensured session termination returns control to main menu after logout.
</Changes>
<Test>
Precondition:
1. User is logged into the system (Admin or Technician).
2. AuthenticationManagementService maintains active session.
3. Controller is connected to AuthenticationManagementService.
Steps:
1. Navigate to Admin or Technician Menu.
2. Select "Logout" option.
- Verify that AuthenticationManagementService::logout clears authenticated user.
3. Session is terminated.
- Verify that system confirms logout and invalidates session.
4. Console returns to main menu.
- Verify that user is redirected to main menu and must log in again to continue.
</Test>
<Review>
Sreeja Reghukumar
</Review>
<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>
<UserStory> CUS004: Register Customer Account </UserStory>
<Changes>
1. Added customer registration flow in UserInterface to collect username, name, email, password, and phone inputs.
2. Added validation for email, password, and phone number before proceeding with registration.
3. Updated Controller::createCustomer() and UserManagementService::createUser() to support customer registration with full user details including name.
4. Added duplicate username validation in UserManagementService using map predicate search.
5. Added user creation and insertion logic in UserManagementService to store newly registered customer records in DataStore.
6. Added observer attachment for newly registered users to inventory(only for admins), payment, and service notification services.
7. Added registration confirmation message display after successful customer creation.
</Changes>
<Test>
Precondition:
1. Application is running and user is on the main login/register menu.
2. DataStore is initialized and available for storing user records.
3. Existing customer records may already be present in the system.
Steps:
1. Select the Register Customer option.
2. Enter valid username, name, email, password, and phone number.
3. Submit the registration request.
- Verify that the system accepts valid inputs and creates the customer account.
4. Attempt registration using an already existing username.
- Verify that the duplicate registration is rejected.
5. Register again with valid unique details.
- Verify that the registration confirmation message is displayed.
6. Re-access application data after registration.
- Verify that the customer data is stored persistently.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> NOT003: View Technician Notifications </UserStory>
<Changes>
1. Added MenuHelper.h to the project for shared notification viewing helper support.
2. Updated TechnicianMenu.cpp to include MenuHelper.h and route viewNotifications() through the shared notification handler.
</Changes>
<Test>
Precondition:
1. Technician user exists and is logged into the system.
2. Technician has one or more notifications available.
3. “View Notifications” option is visible in the Technician menu.
Steps:
1. Navigate to Technician Menu.
2. Select “View Notifications”.
3. Verify that the system displays a list of notifications showing title, message, and timestamp.
4. Select a notification to view full details.
- Verify that the selected notification is displayed and deleted after viewing.
5. Return to the notification list or reopen “View Notifications”.
- Verify that the previously viewed notification is no longer present.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> NOT002: View Admin Notifications </UserStory>
<Changes>
1. Added shared notification view handler `viewAndDeleteNotification()` in MenuHelper.h for notification viewing and deletion logic reuse.
2. Updated AdminMenu.cpp to include MenuHelper.h and connected AdminMenu::viewNotifications() to the shared notification handler.
</Changes>
<Test>
Precondition:
1. Admin user exists and is logged into the system.
2. Admin has one or more notifications available.
3. “View Notifications” option is visible in the Admin menu.
Steps:
1. Navigate to Admin Menu.
2. Select “View Notifications”.
3. Verify that the system displays a list of notifications showing title, message, and timestamp.
4. Select a notification to view full details.
- Verify that the selected notification is displayed and deleted after viewing.
5. Return to the notification list or reopen “View Notifications”.
- Verify that the previously viewed notification is no longer present.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS007: Purchase Combo Package </UserStory>
<Changes>
1. Added combo package selection flow in CustomerMenu to list all active combo packages with estimated cost and allow customer selection.
2. Implemented Controller::purchaseComboPackage to delegate combo package booking requests to ServiceManagementService.
3. Added ServiceManagementService::purchaseComboPackage logic to validate authenticated user, fetch selected combo package, create a ServiceBooking, persist it in DataStore, and send booking confirmation notification.
4. Added helper functions in CustomerMenu to calculate combo package estimated cost based on included services and required inventory items.
5. Updated ServiceBooking model to use User* reference for assigned technician and simplified constructor to align booking model with object references.
</Changes>
<Test>
Precondition:
1. Customer account exists and is logged into the system.
2. Active combo packages are available in the system.
3. Combo package contains one or more active services.
4. Service bookings and notifications can be created successfully.
Steps:
1. Navigate to Customer Menu and select the combo package booking option.
2. View the list of available combo packages.
- Verify that all active combo packages are displayed with their details.
3. Select one combo package and enter vehicle number, vehicle brand, and vehicle model.
- Verify that a booking request is generated successfully.
4. Complete the booking flow.
- Verify that a confirmation message is displayed to the customer.
5. Check customer notifications.
- Verify that a booking confirmation notification is received.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS006 Purchase Individual Service </UserStory>
<Changes>
1. Added service selection flow in CustomerMenu to display active services, allow customer to choose a service, and collect vehicle details for booking.
2. Implemented Controller::purchaseService to delegate service booking requests to ServiceManagementService.
3. Added ServiceManagementService::purchaseService logic to validate authenticated user, fetch selected services, create a ServiceBooking, and persist it in DataStore.
4. Updated ServiceBooking constructor and assigned technician handling to use User* references instead of technician name strings.
5. Integrated ServiceManagementService dependency into Controller
</Changes>
<Test>
Validate customer service booking flow and service status tracking
Precondition:
1. Customer account exists and is logged into the system.
2. Active services are available in the system.
3. Service bookings can be created and stored in DataStore.
4. Technician account exists to update service status.
Steps:
1. Navigate to Customer Menu and select the individual service booking option.
2. View the list of active services and select a service.
3. Enter vehicle number, vehicle brand, and vehicle model, then confirm booking.
- Verify that the service booking is created successfully with an initial status.
4. Technician updates the service booking status.
- Verify that the latest status is reflected in the system.
5. Customer refreshes or views service booking history.
- Verify that the updated status is shown correctly in booking history.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS005: Update Customer Profile Details </UserStory>
<Changes>
1. Added update profile flow in CustomerMenu to collect new email and phone number inputs.
2. Added validation for updated email and phone number before saving changes.
3. Updated Controller::updateUserDetails() to fetch the authenticated user and delegate profile update to UserManagementService.
4. Added user existence validation in UserManagementService before updating profile details.
5. Added logic in UserManagementService to update stored email and phone details for the selected user.
6. Added profile update confirmation message after successful save.
</Changes>
<Test>
Update Customer Profile Details
Precondition:
1. Application is running and a customer is logged into the system.
2. Customer record exists in DataStore.
3. Customer has existing profile details stored in the system.
Steps:
1. Select the Update Profile Details option.
2. Verify that the current profile details are displayed.
- Verify that the system shows the customer’s existing details.
3. Enter a new valid email address and phone number.
4. Save the updated details.
- Verify that the system accepts the changes and displays a success message.
5. Create or view a future booking using the same customer account.
- Verify that the updated profile details are reflected in future bookings.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS003: Implement change password functionality </UserStory>
<Changes>
1. Connected Controller::changePassword() with AuthenticationManagementService password update logic.
2. Added password validation before updating the user password.
3. Added logged-in user check before allowing password changes.
4. Implemented password update logic in AuthenticationManagementService.
5. Added change password flow in CustomerMenu to collect new password input and trigger password update.
6. Added success message display after password is changed successfully.
</Changes>
<Test>
Change password functionality validation
Precondition:
1. System is running.
2. A registered user exists in the data store.
3. User is logged in and customer menu is active.
Steps:
1. Launch the application and log in with valid credentials.
2. Select the Change Password option from the customer menu.
3. Enter a new password.
- Verify that the entered password is validated.
4. If the password is valid, complete the password change.
- Verify that the new password is saved successfully.
- Verify that the message "Password changed successfully" is displayed.
</Test>
<Review>
Sreeja Reghukumar, please review
</Review>
<UserStory> CUS002: Logout</UserStory>
<Changes>
1. Connected Controller::logout() with AuthenticationManagementService logout logic.
2. Added logout implementation in AuthenticationManagementService to clear the authenticated user session.
3. Added logout handling in CustomerMenu to invoke controller logout when the user selects the logout option.
4. Added authentication service dependency in Controller for logout support.
</Changes>
<Test>
Logout functionality validation
Precondition:
1. System is running.
2. A registered user exists in the data store.
3. User is logged in and customer menu is active.
Steps:
1. Launch the application and log in with valid credentials.
- Verify that access is granted and customer menu is displayed.
2. Select the Logout option from the customer menu.
- Verify that the logout operation is triggered immediately.
3. Complete the logout operation.
- Verify that the authenticated user session is cleared.
4. After logout completes.
- Verify that the user is redirected to the login menu.
</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
<Changes>
1. Added State enum with ACTIVE and INACTIVE values in Enums.h.
2. Added state member, getter, and setter in User, Service, InventoryItem, and ComboPackage models.
3. Updated constructors to initialize model objects with ACTIVE state by default.
4. Added state string conversion helper functions in Enums.h.
5. Added default return values in Controller getter methods to complete stub implementations.
6. Added basic menu loop implementation in CustomerMenu and TechnicianMenu for handling user input.
</Changes>
Changes:
- Added stub implementations for Controller.cpp methods
- Fixed const issue in UserInterface methods (run, login, registerCustomer, handleOperation)
- Changed return types to use const pointers for read-only objects
- Updated maps and vectors to return const object pointers
- Fixed some function parameter names and signatures for consistency
Jissin Mathew
joelthomastrenser