Merged PR 2432: Add myportal API grouping facade read slice

Add myportal API grouping facade read slice Related work items: #23754
2026-06-25 09:37:01 +00:00
parent a1b89d19b8
commit 94b19f9697
8 changed files with 306 additions and 3 deletions
@@ -371,6 +371,54 @@ UI journey
    - legacy endpoint handlers remain canonical
    - no route migration, deletion, or contract change has occurred

+#### Additional vertical-slice proof point — My Portal dashboard read / enrichment
+
+- The active My Portal dashboard read / enrichment journey now has a fifth additive grouping slice for the proven CRM-backed dashboard read/enrichment family only:
+    - grouped façade routes exist under `pages/api/myportal/` for the proven active reads:
+        - `get-my-cases`
+        - `get-my-lpa-cases`
+        - `get-portal-module-details`
+    - the existing owning service-layer adoption is split across the current dashboard read services:
+        - `actions/services/portalDirectService.js` now targets grouped myportal routes for:
+            - `getMyCases`
+            - `getMyLPACases`
+        - `actions/services/caseDirectService.js` now targets the grouped myportal route for:
+            - `getPortalModuleDetails`
+    - legacy endpoint handlers remain present and canonical behind the façade:
+        - `pages/api/endpoint/getmycases_api.js`
+        - `pages/api/endpoint/getmylpacases_api.js`
+        - `pages/api/endpoint/getportalmoduledetails_api.js`
+- The bounded audit established that the true active My Portal dashboard read/enrichment slice is narrower than the whole dashboard-related API surface:
+    - `pages/myportal/index.js` is the principal authenticated dashboard loader
+    - the active CRM read branch on that page is:
+        - `getMyCases(loggedInUser)` or `getMyLPACases(lpaId)`
+        - `getPortalModuleDetails(collectionName, caseID)` for detail-card enrichment fan-out
+    - watched cases are already covered by the subscriptions slice through `getWatchedCases(loggedInUser)`
+    - representation and awaiting-submission lists on this loader are blob-backed in the active path:
+        - `getRepsFromBlob(thisSession.user.id)`
+        - `getAwaitingSubmissionFromBlob(thisSession.user.id)`
+    - account/bootstrap/auth routes remain upstream supporting concerns rather than part of this grouped read slice:
+        - `getPortalLogin(...)`
+        - `getPersonalAccount(...)`
+        - `getSession(ctx)`
+- The following routes were intentionally left outside this grouped adoption scope:
+    - `getwatchedcases_api.js`
+    - `getmyrepresentations_api.js`
+    - `getawaitingsubmission_api.js`
+    - storage/draft routes under `pages/api/file/**`
+    - account/auth/session routes
+- Exclusion reasoning:
+    - watched-case reads are already owned by the completed subscriptions slice
+    - `getmyrepresentations_api.js` and `getawaitingsubmission_api.js` were candidate routes to investigate, but they are not part of the proven active `pages/myportal/index.js` read path, which currently uses blob-backed representation and awaiting-submission retrieval instead
+    - storage/blob routes remain explicitly out of scope for this read-only CRM façade slice
+    - account/bootstrap/auth concerns remain out of scope by requirement and because they are not journey-owned dashboard CRM reads
+- For this My Portal slice, a complete vertical grouping slice means:
+    - the proven active CRM dashboard read/enrichment family has grouped façade routes
+    - current owning service calls for that family target the grouped routes
+    - subscriptions, storage/draft, and account/auth routes remain unchanged
+    - legacy endpoint handlers remain canonical
+    - no route migration, deletion, contract change, auth change, storage change, or behaviour change has occurred
+
 ---

 ### Stage 3 — Documentation Maturity