fix: reject OTP generation when form is not public

[scottheng96]

Problem

The public POST /api/v3/forms/:formId/fieldverifications/:transactionId/fields/:fieldId/otp/generate endpoint only checked that the form exists, not that it is public. Anyone with a form ID and a live transaction could keep requesting OTPs against a closed or archived form and get a 201 back — triggering real SMS and email sends for a form that can no longer accept submissions. This is both an abuse vector (unsolicited OTP sends, SMS cost) and inconsistent with the rest of the public API, which rejects non-public forms.

Solution

Gate _handleGenerateOtp on FormService.isFormPublic immediately after the form is retrieved, before any auth verification or OTP generation/sending. This mirrors the existing pattern in the feedback and issue controllers.

Breaking Changes

• No — this PR is backwards compatible. Public forms behave exactly as before; only requests against private/archived forms change from 201 (or 500) to 404/410, which no legitimate client flow depends on.

Tests

Unit tests: pnpm test src/app/modules/verification/__tests__/verification.controller.spec.ts in apps/backend (91 passing, includes new 404/410 cases).

TC1: OTP generation blocked on a closed form

• Create a form with a verifiable email field, open it, and load the public form to obtain a transaction ID
• Close the form (set to Private) in the admin settings
• Call POST /api/v3/forms/:formId/fieldverifications/:transactionId/fields/:fieldId/otp/generate with a valid {"answer": "<email>"} body
• Verify that the response is 404 with message "This form is no longer active, so OTPs can no longer be requested."
• Verify that no OTP email is received

TC2: OTP generation still works on a public form (regression)

• On an open form with a verifiable email field and a verifiable mobile field, request an OTP for each field via the public form UI
• Verify that both OTPs arrive (email and SMS) and the responses are 201
• Verify the OTPs and submit the form successfully

TC3 MRF step 2 respondent on an open form (regression)

• Create a 2-step MRF form with a verifiable email field in step 2 and submit step 1
• As the step-2 respondent, request and verify an OTP for the email field
• Verify that the OTP is issued (201) and step 2 can be submitted

🤖 Generated with Claude Code

[kevin9foong]

issue(minor): it seems that the message for FormDeletedError is form is no longer active.

export class FormDeletedError extends ApplicationError { constructor(message = 'This form is no longer active') { super(message, undefined, ErrorCodes.FORM_DELETED) } }

should the error here be This form is no longer active, so OTPs cannot be requested instead? or shall we just use the default core error message?

[kevin9foong]

issue(minor): should we perhaps update the copy here to be consistent with other mappers?

suggestion: This form has been taken down, so OTPs cannot be requested.

other mappers:
case PrivateFormError: return { statusCode: StatusCodes.NOT_FOUND, errorMessage: 'This form has been taken down. For assistance, please contact the person who asked you to fill in this form.', }

[kevin9foong]

LGTM! Thanks for discovering this and it is quite scary that this was allowed previously haha. Just a few minor comments about the error messaging to use consistent terms with the rest of the app. Let's release this once those messages are updated!

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request