feat: Add submission limits for storage mode form submissions

[frankchn]

Problem

This pull request adds a submission limits feature for storage.

Closes #148

Solution

Instead of using the formStatisticsTotal collection, I am simply querying SubmissionModel.countDocuments({ form: form._id }) for the number of submissions up till now. I think this is probably fine as the submission model has an index on the form field and we are already using that to count the total number of submissions for export and attachment downloads and those seem reasonably fast.

Otherwise, we are allowing users to specify a submission limit, but will simply show them an error message instead of attempting to deactivate the form, which is more complicated and requires us to touch the form document itself instead of simply checking for number of submissions before we render the form and before the form is submitted.

This also doesn't require re-CAPTCHA to be turned on (maybe we should?).

Features:

• New field to let the user specify how many responses they want.
• Checks for submission limits and shows the user an error message if they visit a form that has exceeded the maximum limit

Before & After Screenshots

Tests

• Create a form, and set the limit to zero.
• Verify that the form is not visible.
• Set the limit to 1 and submit the form.
• Verify that the submission goes through
• Visit the form again and make sure that the form is not visible any more.
• Set the limit to 2 and open two tabs.
• Attempt to submit the form in both tabs. Only one should work.

Deploy Notes

This introduces a new submissionLimit field in the Form collection.

[liangyuanruo]

Changes to make after discussion

1. Ship form deactivation without notification feature
2. Form status should be set to deactivated when submission limit is reached (it would be good to log this)
3. Align UI to design screens

[frankchn]

The response limit is off:

The response limit is on and above the current response count:

The response limit is on and below the current response count:

[frankchn]

@liangyuanruo I am not sure how to fix these build errors, can you take a look? Thanks!

src/app/modules/form/public-form/public-form.middlewares.ts(28,13): error TS2345: Argument of type '(queryResults: number) => void | Promise<Response<any, Record<string, any>, number>>' is not assignable to parameter of type '(value: number) => Response<any, Record<string, any>, number> | PromiseLike<Response<any, Record<string, any>, number>>'.
  Type 'void | Promise<Response<any, Record<string, any>, number>>' is not assignable to type 'Response<any, Record<string, any>, number> | PromiseLike<Response<any, Record<string, any>, number>>'.
    Type 'void' is not assignable to type 'Response<any, Record<string, any>, number> | PromiseLike<Response<any, Record<string, any>, number>>'.
src/app/modules/form/public-form/public-form.middlewares.ts(33,13): error TS2741: Property 'action' is missing in type '{ form: any; }' but required in type '{ [other: string]: any; action: string; }'.

[liangyuanruo]

To be launched for both Storage and Email mode forms, and add tests.

[frankchn]

The email submission route (as defined in email-submission.routes.ts) doesn't support const { form } = req as WithForm<typeof req> and I am not sure where that is added in the processing stack, so I can't enable it at the moment.

[liangyuanruo]

The email submission route (as defined in email-submission.routes.ts) doesn't support const { form } = req as WithForm<typeof req> and I am not sure where that is added in the processing stack, so I can't enable it at the moment.

Ah, I think this is because we recently refactored to combine the email submission middlewares together into a single handleEmailSubmission function for better type safety since there will be no need for type assertions. We'll eventually combine the remaining code into a handleEncryptSubmission function too.

I think you can get around this by first extracting all the business logic from the checkFormSubmissionLimitAndDeactivate middleware into a service, then using that in both the new middleware as well as to extend the handleEmailSubmission function...

Does this make sense?

[liangyuanruo]

Follow-up from discussions:

1. drop hasSubmissionLimit boolean
2. refactor logic out of checkFormSubmissionLimitAndDeactivate middleware into a service function for reuse with both storage and email mode forms

[frankchn]

@liangyuanruo made all the changes -- PTAL, thanks!

[liangyuanruo]

thanks @frankchn - clarified with @syan-syan and I think we need some further refinements to both the processing flow and data model.

[liangyuanruo]

Thanks @frankchn , almost there!

[r00dgirl]

changes from reviewing staging

• tooltip: Form will automatically deactivate when set response limit is reached. Enable reCaptcha to prevent spam submissions from triggering this limit.
• “Maximum number of responses allowed”
• error message below the field change from blue to red