Feature/Staff Grant Extension - Complete Back-end work

[SahiruWithanage]

Description

This pull request provides the complete back‑end implementation for the Staff Grant Extension feature. It introduces a dedicated API that allows staff (tutors, convenors and admins) to grant extensions to one or more students on a given task directly from the Ontrack system. All UI/UX work is handled in a separate PR – this branch focuses on the API, model and mailer changes needed to support the new workflow.

What’s Included

New API for staff‑granted extensions

• StaffGrantExtensionApi endpoint – A new Grape API mounted under /staff‑grant‑extension (and protected by existing authentication helpers). The POST route enables staff to grant extensions to multiple students without formal requests. The endpoint accepts a list of student IDs, a task identifier, the number of weeks to extend and a reason, and returns a result object listing successes and failures.
• Reuses existing extension logic – The API delegates to a shared ExtensionService originally used for student‑requested extensions, ensuring both staff and student flows use the same business rules and validations. This avoids duplication and keeps extension handling consistent across the codebase.
• Validation and error handling – Parameters are validated up front, and clear error responses are returned for missing fields or invalid data. Thread‑safe processing ensures race conditions are avoided when updating multiple students’ due dates.

Notifications system

• Database model and relations – Introduced a new Notification model and underlying table with a relationship to User. Notifications store a message, a target user and a read/unread status.
• In‑system notifications for students – When an extension is successfully granted, a notification record is created for each affected student. This allows the front‑end to display an in‑system notification panel informing the student of their new due date.
• Notification API – Added endpoints to list and delete notifications by ID. These routes allow the front‑end to fetch unread notifications and dismiss them once read.

Email delivery improvements

• Comprehensive mailer updates – Extension emails now use consistent delivery methods (deliver_now vs. deliver_later) and handle errors gracefully. A summary email is sent to the staff member listing all extensions granted and individual emails are sent to each student.
• Configuration and sender fixes – Updated the mailer configuration to use the correct sender address and added robust error handling around email delivery.
• Pending SMTP configuration – At present, there is no SMTP server configured in the development environment. When an extension is granted, the system generates the email and saves it as a file on disk. In production, the config/environment will need to be updated with the proper SMTP details so that emails are actually sent.

Refactoring and shared services

• Unified ExtensionService – Refactored the existing student extension_comments_api to use a shared service so that both student and staff extension flows call the same business logic. This reduces duplication and improves maintainability.
• Improved logging and debugging – Added extra logging around extension creation and mailer outcomes to aid debugging and system monitoring.
• Test cleanup and consistency – Updated test files to follow string‑formatting conventions and cleaned up unused code as part of peer reviews.

Type of change

• Bug fix (non‑breaking change which fixes an issue)
• New feature (non‑breaking change which adds functionality)
• Refactor/Cleanup (code improvement without changing external behaviour)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Testing Checklist (the front‑end exercising this API serves as the primary way to verify functionality)

• Tested staff grant extension creation for multiple students
• Verified notifications are created
• Confirmed summary and individual emails are delivered(created)
• Ensured student extension endpoints still operate correctly
• Checked validation and error handling for invalid input

Checklist

• My code follows the style guidelines of this project
• I have performed a self‑review of my own code
• I have commented my code in hard‑to‑understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

Folders and Files Added/Modified

Added:

• app/api/staff_grant_extension_api.rb – New Grape API with POST endpoint to grant extensions to multiple students.
• app/models/notification.rb and associated migration – Defines the Notification model and database table.
• app/api/notifications_api.rb – Provides GET and DELETE endpoints for notifications.
• New mailer templates and methods for staff summary emails and individual student notifications.

Modified:

• app/api/api_root.rb – Mounted the StaffGrantExtensionApi and NotificationsApi and added authentication hooks.
• app/services/extension_service.rb – Updated to support staff‑initiated extensions and reuse logic for student‑requested extensions.
• app/mailers/extension_mailer.rb – Corrected sender configuration, added summary email method and improved error handling.
• app/api/staff_grant_extension_api.rb – Updated in subsequent commits to refine email sending logic and handle race conditions.
• Test files (test/api/staff_grant_extension_test.rb) – Added new cases for multiple students and notifications; refactored to follow single‑quote conventions.

Deleted:

• No significant file deletions. Deprecated methods and unused code were removed as part of refactoring.