feat(SGE): API Rebase to 10.0.x

[SteveDala]

Description

This pull request is a complete rebase of the Staff Grant Extension (SGE) API functionality introduced in #77. The initial feature was built on 9.x, and this PR migrates the feature to the new 10.0.x development branch.

All credit for development of the feature API goes to @samindiii and @SahiruWithanage.

Sister branches

Run OnTrack with the latest version of these branches to recreate the environment.

• doubtfire-web: feat/SGE-rebase-cherry-pick
• doubtfire-deploy: 10.0.x

Sister Pull Requests

• thoth-tech/doubtfire-web #441: Front-end that interacts with this feature
• doubtfire-lms/doubtfire-web #565: Upstream version

Repo cleanup

Merging this PR should be followed by closing the following open PRs with a comment that they have been merged into 10.0.x:

• Feature/Staff Grant Extension - Complete Back-end work #77, which is the initial PR of the complete feature
• Add notification table and model for in-system notifications #69, the in-system notification system that is included in this PR and a dependency
• Feature/Extension notification system - Backend #60, an earlier version of this feature
• Feature/Add Staff Grant Extension endpoint #56, the addition of the SGE API endpoint, a dependency

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Test A

While the development container is running, connect and run rails test from the directory /workspace/doubtfire-api. This runs all unit tests. For the last successful GitHub Action run of this branch, see here.

Test B

To strictly test the API, head to localhost's API docs while your Docker server is running.

Open "auth : Operations about auths" and go to "POST /api/auth". Enter the following JSON for the postApiAuth value:

{"username": "aconvenor", "password":"password"}

Then click "Try it out!". From the response, grab the auth_token value.

Open "units : Operations about units" further down the page then go to "POST /api/units/{unit_id}/staff-grant-extension". Enter the following values for each parameter:

• unit_id: 1
• Username: aconvenor
• Auth_token: (The one you received from POST /api/auth)
• postApiUnitsUnitIdStaffGrantExtension:

{
  "student_ids": [
    24
  ],
  "task_definition_id": 1,
  "weeks_requested": 1,
  "comment": "string"
}

You should receive a "successful" result in the Response Body.

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, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if appropriate
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have created or extended unit tests to address my new additions
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[SteveDala]

@BrianDangDev could you please approve the test run workflows to kick off?

[rammakablecode]

The rebase is clearly documented by Steven,
The migration from the original 9.x implementation appears clean, and it’s good to see the functionality preserved while aligning with the current development architecture.

The PR clearly documents, sister branches, dependent PRs, and testing steps, which does make it easy to reproduce and verify the environment. Test coverage looks strong, with unit tests and RuboCop passing, and the manual API testing steps are clear and reproducible.

Regarding related PRs

• StaffGrantExtensionApi is clearly documented, uses strong parameter validation, and enforces authentication and authorization up front. The transactional handling for bulk grants is particularly solid and aligns well with the stated atomicity guarantees.

• Extracting shared logic into ExtensionService removes duplication from the student-initiated endpoint and provides a clean, testable abstraction for both staff and student flows.

• Notification support is comprehensive:
  In-system notifications via the Notification model and API.
  Email notifications with clear separation between staff summaries and student notifications.

• The API tests cover success paths, authorization failures, validation errors, rollback behavior, and edge cases. Mailer tests are thorough and validate both content and headers.
  The API root and permission updates in Unit and User are minimal and appropriate, and the addition of :grant_extensions is consistent with existing permission patterns.

No issues from a review perspective

[SteveDala]

@rammakablecode could I get you to change your review into an "approving review"?

[rammakablecode]

Reviewed above