feat(mrf): workflow builder #7072
Conversation
| newWorkflowSettings: MultirespondentFormSettings['workflow'], | ||
| ) => { | ||
| return ApiService.patch<FormSettings>( | ||
| `${ADMIN_FORM_ENDPOINT}/${formId}/settings`, |
There was a problem hiding this comment.
Curious, why is workflow using :formId/settings instead of having it's own PATCH, DEL, PUT :formId/workflow?
Was it to write less boilerplate code?
There was a problem hiding this comment.
-- saw that you have already noted this on the PR, this will be resolved after we ship? Totally fine by it as we have a good amount of buffer post-release to make refinements like this.
There was a problem hiding this comment.
Yup, in the spirit of making PRs as small as possible to avoid scope creep,, I decided not to do that modification here. This code was already written and I didn't want to touch it too much. Nonetheless, a linear ticket to resolve this has already been opened as FRM-1632!
There was a problem hiding this comment.
Great division of scope btw! Features are cleanly cut, and isolated.
|
Added d2b3327 as we should be swapping these to their own PATCH / PUT / DELETE. |
Problem
We want to build out a workflow builder for MRF with dynamic number of respondents.
Closes FRM-1624
Solution
This implementation reuses many of the components from the logic module but with several significant changes. In particular, a lot of the inputs are removed and replaced with workflow-specific inputs (e.g. step number, respondent emails). Also, the current implementation uses a single "godlike" put endpoint to put the entire workflow array into the backend. This should be granularized so that we have specific creation, update and delete endpoints on a per-workflow-step basis.
Breaking Changes
Before & After Screenshots
BEFORE:
AFTER:
Screen.Recording.2024-02-08.at.4.58.16.PM.mov
Tests