68 lines
3.7 KiB
Markdown
68 lines
3.7 KiB
Markdown
# Product Context — PEDW FrontEnd
|
|
|
|
## Primary user workflows
|
|
|
|
1. **Public discovery**
|
|
- Search planning cases (basic, advanced, address, DNS).
|
|
- Open case summary pages and review documents/history.
|
|
|
|
2. Authenticated portal (`/myportal/**`)
|
|
- Sign in via magic-link email.
|
|
- View dashboards/worklists (my cases, watched cases, awaiting submission, representations).
|
|
- Start or continue appeal/representation submission flows.
|
|
|
|
3. **Role-shaped behavior**
|
|
- General users can create appeals and representations.
|
|
- LPA users get authority-scoped views and representation actions; raise-appeal behavior is restricted.
|
|
|
|
## Core domain concepts
|
|
|
|
- **Case / Incident**: core planning entity shown in search, detail, and portal journeys.
|
|
- **Appeal type**: controls collection/field behavior and some UI logic.
|
|
- **Representation window**: date-gated period controlling whether representation actions are available.
|
|
- **Watched case / email notifications**: user subscriptions to case changes.
|
|
- **DNS**: Developments of National Significance-specific journey and pages.
|
|
|
|
## Business logic patterns visible in code
|
|
|
|
- Case summary UI varies by appeal type and case attributes.
|
|
- Case status/progress display is portal-shaped rather than a raw CRM passthrough: the portal selects a journey catalogue from CRM `statuscode`, appeal type, and limited Rights of Way specialist-process input to present user-facing progress.
|
|
- Representation actions are conditionally shown by appeal type, role, and date windows.
|
|
- Representation participation now appears to form one broader business decision model: whether a participant can engage in representation or consultation activity for a case at that point in the process.
|
|
- Locale-sensitive behavior affects links, routes, labels, and email template choice.
|
|
- New-case-reference notifications include preferred-language checks before template selection.
|
|
|
|
## Current representation participation state
|
|
|
|
- Technical discovery/documentation for Representation Participation Availability is complete.
|
|
- The current behaviour is best understood as a coherent participation-availability policy with layered appeal-type, process-type, participant-type, consultation, and date-window exceptions.
|
|
- Business validation is still required before any further representation-policy adoption, expansion, or behavioural change work.
|
|
- Reference documents:
|
|
- `docs/representation-participation-availability.md`
|
|
- `docs/representation-participation-business-review.md`
|
|
|
|
## Current case progress display state
|
|
|
|
- Technical investigation for CRM Case Progress Display is complete.
|
|
- Current behaviour is best understood as a **user-facing journey representation**, not a business-policy decision model.
|
|
- The Case Status tab is driven by:
|
|
- CRM `statuscode`
|
|
- appeal type
|
|
- specialist process for Rights of Way variants only
|
|
- `pinswg_casestage` should not currently be treated as a significant input to status-tab lifecycle behaviour.
|
|
- Shared catalogue families exist and reflect a mixture of:
|
|
- genuine shared journey structures
|
|
- presentation reuse
|
|
- historical consolidation
|
|
|
|
## Likely next discovery candidate
|
|
|
|
- No immediate successor discovery candidate is implied by the completed CRM Case Progress Display stream.
|
|
- If reopened later, work should focus on business validation or future behavioural change questions rather than first-pass technical characterization.
|
|
|
|
## Important user-facing behaviors
|
|
|
|
- Welsh route aliases are mapped in `next.config.js` and must remain in sync with page behavior.
|
|
- Breadcrumb/back-navigation behavior is actively maintained across search -> case -> portal routes.
|
|
- Document visibility/download flows are central to case transparency and must remain stable.
|