[MRF-12] PLU-520: (frontend) set approval config when creating step

[pregnantboy]

Changes

• Added visual indicators (green/red box shadows) to steps in approval branches
• Connected the ApproveReject component to the MrfContext to track branch selection
• Fixed step duplication to properly preserve approval branch configuration
• Added helper function getMrfApprovalConfig to determine approval configuration for new steps
• Enhanced useStepMetadata hook to detect and provide approval branch information
• Added shadow styles to the theme foundations

How to test?

1. Create a workflow with a FormSG MRF step that includes an approval field
2. Add steps after the MRF step in both the "approve" and "reject" branches
3. Verify that steps in the "approve" branch have a green shadow
4. Verify that steps in the "reject" branch have a red shadow
5. Test duplicating steps within approval branches to ensure they maintain the correct branch configuration
6. Test adding new steps to approval branches to ensure they're properly assigned

[pregnantboy]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [MRF-18] PLU-520: remove mrf-related steps and config on checkstep #1347
• [MRF-17] PLU-520: (frontend) allow if-then and for-each for different branches #1345
• [MRF-16] PLU-520: style approve/reject steps, show approval tag for yes/no #1344
• [MRF-15] PLU-520: (frontend) allow reordering of steps across MRF steps #1343
• [MRF-14] PLU-520: (frontend) conditionally hide steps based on approval branch #1293
• [MRF-13.5] PLU-520: (frontend) refactor contexts #1292
• [MRF-13] PLU-520: (frontend) refactor cache manipulation #1290
• [MRF-12] PLU-520: (frontend) set approval config when creating step #1288 👈 (View in Graphite)
• [MRF-11] PLU-520: (backend) create step approval config #1287
• [MRF-10] PLU-520: pass prevStep instead of prevStepId #1286
• [MRF-9] PLU-520: MRF context and refactor #1349
• [MRF-8] PLU-520: New Approve-Reject component (frontend) #1284 : 1 other dependent PR (#1285 )
• [MRF-7] PLU-520: remove mrf actions steps if necessary #1275
• [MRF-6] PLU-520: testStep for mrf actions should test multiple steps #1269
• [MRF-5] PLU-520: refactor frontend to allow test step on mrf actions #1268
• [MRF-4] PLU-520: automatically create/delete/update mrf steps on check step #1267
• [MRF-3] PLU-520: introduce mrf action that cannot be added by user #1266
• [MRF-2] PLU-520: parse formsg workflow data + refactor #1265
• [MRF-1] PLU-520: allow mrf forms to be connected #1264
• mrf/trunk

This stack of pull requests is managed by Graphite. Learn more about stacking.

[linear]

PLU-520 MRF: Approvals

[kevinkim-ogp]

Suggested change

	approval: step.config?.approval,
	approval: {
	branch: step.config.approval.branch,
	stepId: step.config.approval.stepId,
	},

current config throws error when attempting to duplicate step in the 'reject' branch. it complains about __typename being present in the input

[kevinkim-ogp]

• Can create step in approval branch
• Can create step in rejection branch
• Can duplicate step in approval branch
• Can duplicate step in rejection branch
• Can duplicate branch
• Can create step in if-then branch
• Can reorder steps

---

clarification for the UI: is that the intended border ?