[vidiyala99]

Description

Bug 62 (Jobs Component - Cap Application Confirmation Emails): each form allows one application per address, but nothing limited how many forms one address could be used on. Anyone could use the public form to make One Community email a victim once per open form, or burn the shared Gmail quota that password-reset emails also depend on.

Fixes # Bug 62 (Jobs Component - Cap Application Confirmation Emails)

Related PRS (if any):

HGNRest#2411 (escape applicant input in the same email) edits the email body in the same function. This PR only adds a guard at the top, and the two merge cleanly.

Main changes explained:

• Create src/utilities/confirmationEmailCap.js: shouldSendConfirmation(email) counts saved applications in the last 24 hours (rolling window), for the applicant's address and across all forms. A confirmation email is skipped when the address has more than 3 or the total is more than 300. The count runs after the application is saved, so it includes the current one: the 3rd application from one address in 24 hours still gets an email and the 4th does not; globally the 300th gets one and the 301st does not.
• Update src/controllers/collaborationController.js: sendApplicationConfirmationEmail checks the cap first. When capped, the application is still saved, the response is the same success response, and one warning is logged (cap name, masked address such as a***@example.com, the counts).
• If the count query fails, the email is sent anyway, so a database problem never blocks legitimate confirmations.
• Update src/models/jobApplicationsModel.js: indexes { email: 1, createdAt: -1 } and { createdAt: -1 } so both counts stay cheap. Mongoose builds them on deploy, no migration.
• Tests: src/utilities/__tests__/confirmationEmailCap.test.js (new, 11 cases) and 4 new cases in src/controllers/collaborationController.test.js: sent under the cap, sent at 3, skipped at 4 while the application is still saved and the response stays 201, global cap, only the last 24 hours counts, fails open on a count error, logs never contain the full address, and the index check.

How to test:

1. check into current branch
2. do npm install
3. npx jest --runInBand src/utilities/__tests__/confirmationEmailCap.test.js src/controllers/collaborationController.test.js (27 tests pass)
4. Live: on a local backend, submit applications with the same email to 4 different forms. Emails go out for the first 3; the 4th is saved and returns 201 but logs "Confirmation email skipped (per-address cap)".

Screenshots or videos of changes:

Test output (jest): 2 suites, 27 tests passed.

Note:

• The limits (3 per address, 300 per day) are my choices and are single constants in the utility.
• A caller could submit 300 fake applications to reach the global cap and suppress other people's confirmations for a day. Bug 61 (bot protection and rate limiting on submit) is the fix for that.
• Not tested against a real MongoDB; the tests mock the model.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud