Closed Dr-Pongo closed 1 year ago
Simple way to search up paths based on whatever criteria we need
import formConfig from '../config/form';
const extractPathAndComponent = () => {
Object.entries(formConfig.chapters).forEach(([chapterKey, chapter]) => {
if (chapter.pages) {
Object.entries(chapter.pages).forEach(([pageKey, page]) => {
if (page.editModeOnReviewPage === false) {
console.log(`Chapter: ${chapterKey}, Page: ${pageKey}`);
console.log(`Path: ${page.path}`);
console.log(`editModeOnReviewPage: ${page.editModeOnReviewPage}`);
}
});
}
});
};
// Or by various chapter keys
const extractPathAndComponent = () => {
Object.entries(formConfig.chapters).forEach(([chapterKey, chapter]) => {
if (chapter.pages) {
Object.entries(chapter.pages).forEach(([pageKey, page]) => {
if (
page.CustomPageReview !== undefined &&
page.CustomPageReview !== null
) {
console.log(`Chapter: ${chapterKey}, Page: ${pageKey}`);
console.log(`Path: ${page.path}`);
console.log(`CustomPageReview: ${page.CustomPageReview.name}`);
}
});
}
});
};
// then call this function inside your component
useEffect(() => {
extractPathAndComponent();
}, []);
Classification of the form's chapters, pages, and corresponding paths into distinct categories, including:
Compiled the above information into comprehensive tables. These tables encapsulate details about the chapter, page, path, and any particular component parameters (such as 'CustomPageReview' or 'editModeOnReviewPage').
Our upcoming task is to devise a strategy for activating read-only mode across each section category. This requires careful planning as the implementation approach may vary across different sections due to the unique properties of each category.
@Dr-Pongo @HeatherRienks
Employment History
Spouse Employment History
Additional Income
Spouse Additional Income
Okay in short this is what I'm thinking ticket wise.
ui:options
hideOnReview
set to true
, so easy fix, just want to make sure that the edit for these is definitely hidden bc it could cause validation issues if the radio options get changed on final review.employmentHistorySummary
& spouseEmploymentHistory
. See something like UtilityBillSummaryReview
as an example, and leverage employment history summary card for how to get everything to display.otherIncomeSummary
& spouseOtherIncomeSummary
. See something like UtilityBillSummaryReview
as an examplemonetaryValues
, but only show if the values have been populated.UtilityBillSummaryReview
as an examplevehiclesSummary
, but only show if the values have been populated.UtilityBillSummaryReview
as an examplehouseholdExpensesInputList
, but only show if the values have been populated.UtilityBillSummaryReview
as an examplemonetaryValues
, but only show if the values have been populated.UtilityBillSummaryReview
as an example, and can leverage mini summary implementation for getting all relevant datainstallmentContracts
, but only show if the values have been populated.UtilityBillSummaryReview
as an example, and can leverage mini summary implementation for getting all relevant dataHeaders get a little weird. Currently we don't really have a way to just show a page only on the final review and I don't want to make a huge mess with platform level changes, but we can leverage CustomPageReview
on the first page in each chapter to slide in a header and "Edit section" button. This will involve displaying information for that page and the header. Some pages like Assets we won't necessarily need to worry about bc we're not showing the checklist on the review.
If we take this approach we'll need the following ticket (might not be worth to have split up into multiple tickets for consistency):
CustomPageReview
that shows custom chapter header with "Edit section" button along with relevant page data.veteranInfo
, employmentQuestion
, bankruptcyHistory
CustomPageReview
that shows custom chapter header with "Edit section" button, but these pages either have their info displayed elsewhere, or are read only pages anyway. monetaryChecklist
, expensesExplainer
, optionExplainer
Issue Description
Discovery ticket to investigate review page effort, and make necessary tickets.
When we're making the read only tickets, and the header links, we can probably break these up by chapter so we can divvy up the work. (Income chapters will probably be bigger)
Design Files: see Review request (C7)
Paths with CustomPageReview Component
"VIC" stands for "Veteran Information Chapter" "HIC" for "Household Income Chapter" "HAC" for "Household Assets Chapter" "HEC" for "Household Expenses Chapter"
Paths with CustomPageReview
null
Note: I need to confirm this but it's also likely these are all custom schema pages
Paths with editModeOnReviewPage: true
Paths with editOnReviewPage: false
Pages without customPageReview or editModeOnReviewPage keys in page definition
Tasks
Acceptance Criteria
[ ] LoE and tickets created for tasks listed above.
How to configure this issue
product support
,analytics-insights
,operations
,service-design
,Console-Services
,tools-fe
)backend
,frontend
,devops
,design
,research
,product
,ia
,qa
,analytics
,contact center
,research
,accessibility
,content
)bug
,request
,discovery
,documentation
, etc.)