feat(mrf): frontend field locking

[justynoh]

Problem

We want to implement field locking for MRF. This PR does this for frontend locking. Backend locking validation will be implemented in a separate PR.

Closes FRM-1639

Solution

Admin-side

• Update workflow builder frontend
  • For active state (EditStepBlock), add a new component, QuestionsBlock which contains the multiselect dropdown for admins to choose questions to edit.
  • Also, update inactive state (InactiveStepBlock) with new section to display field labels for selected questions to be edited by each step.
• Add edit key to
  • workflow step schemas in shared/*,
  • backend types, and
  • API middlewares for workflow settings, which is where the workflow object still gets PATCHed 😢.

Public-side

• Frontend disabling of fields. There are two things that need to be done.
  • Visually, the fields are in a disabled state.
    • A new augmentation augmentWithWorkflowDisabling is added, which disables the field only if the field is in the workflow step, and it's an input field (i.e. not header, paragraph or image). This uses the disabled key in the FormFieldDto type.
    • Some field UI updates had to be done to support this, as not all fields fully supported the disabled key. In particular, phone numbers and the table field were updated.
  • Required validation should be turned off for these fields.
    • Achieved through similar means as before, using the disableRequiredValidation key in the FieldFactory component. However this time instead of checking if the form is MRF and disabling the validation universally, we implement a field-level check using the same util as augmentWithWorkflowDisabling so that the logic is always consistent.

Breaking Changes

• No - this PR is backwards compatible

Before & After Screenshots

Tests

Deploy Notes

New scripts:

• 20240214_mrf-workflow-field-locking : This DB migration script adds the edit key for all workflow steps, which allows users to choose the fields each respondent is allowed to edit. To preserve existing behavior, all respondents must be allowed to edit all fields. Therefore, a copy of the form fields (excl non-input fields section, statement and image) are copied into every edit key.

[linear]

FRM-1639 Field restrictions by workflow step (admin + public frontend)

[KenLSM]

LGTM some nits / questions

[KenLSM]

Noob question: why there's a need to bind here? Didn't see any usage of this in the inner function calls of augmentWithWorkflowDisabling

[justynoh]

updated in 17083cf

Actually here i was a bit annoyed at how i have to give a variable name haha. Basically the idea is I want a partially-applied function, with only the first argument provided. There are three ways of doing it

1. Write the function with two parameters, and create an anonymous function inline (this is the way i did it in the updated commit, above)

// Define
const augmentWithWorkflowDisabling = (workflowStep, formFields) => ...

// Call
formFields.map((fields) => augmentWithWorkflowDisabling(workflowStep, fields))

The advantage is this is all very nice and maintainable, we're used to functions with multiple parameters, but is annoying because i shouldn't really need to define a new variable and think about it's name and what it means just to pass it in to a function and never do anything else interesting with it.

2. Write the function with two parameters, and bind it to create a partially applied function (this is the way I did it previously)

// Define
const augmentWithWorkflowDisabling = (workflowStep, formFields) => ...

// Call
formFields.map(augmentWithWorkflowDisabling.bind(this, workflowStep))

In this case, this is nice because I've removed the need to define a new variable, but now i include this random reference to ".bind" which no one really understands, and references a context "this" which doesn't exist (it's the global module context, which is a bit weird). Also not ideal

3. Curry the function, and partially apply it as usual (my preferred way, but not typical coding pattern in FormSG)

// Define
const augmentWithWorkflowDisabling = (workflowStep) => (formFields) => ...

// Call
formFields.map(augmentWithWorkflowDisabling(workflowStep))

This is very nice when used in this scenario, solves all the problems and is easy to read. But, using curried functions aren't very typical in the codebase, and will look weird if used in other places where partial application is not necessary (e.g. if someone else down the line needs to use augmentWithWorkflowDisabling but has both workflowStep and formFields available in the surrounding context, the call signature becomes augmentWithWorkflowDisabling(workflowStep)(formFields), which can look confusing in a sea of typically-uncurried functions).

In the end I think just going with 1 makes the most sense and is most consistent with the rest of the codebase, even though i like 3 the most hahaha

[KenLSM]

https://ramdajs.com/docs/#curry helps for 3. But ramda isn't a library that FormSG uses.

I notice that lodash also supports placeholders in curried functions. But this can be an exercise for the next time.

I've seen 1/3, but never 2 😆.

[justynoh]

If i have to write .curry then that feels a bit like, it defeats the purpose of currying anyway though. HAHAHA

[justynoh]

re: ramda, What?? what is this javascript magic that allows you to write f(1)(2,3) or f(1,2)(3) tf 🤣