feat: Homepage implementation backend - #22
Conversation
paulushcgcj
left a comment
There was a problem hiding this comment.
There are some mentions about some stories that I could not find on github. Other than that looks good. Left just one suggestion
paulushcgcj
left a comment
There was a problem hiding this comment.
Small N+1 observation — trackStatus in MillContextService calls findStatusDescription(code) and it is invoked twice from resolveWorkingContext (once per track). Two round-trips to a lookup table is minor today, but the pattern will grow if more tracks or status lookups are added. Worth considering a batch method like findStatusDescriptions(List<String> codes) returning a Map<String, String>, or flagging for a follow-up.
ConradBoydElliottGustafson
left a comment
There was a problem hiding this comment.
Looks like a reasonably-sized PR with high level of checks applied. Purpose and scope are understandable and the guardrails have all been applied. Pass.
|
We can't let these PRs languish -- it will create merge hell. We'll get the SONAR report when the github actions are all working. Come on DevOps team let's do this thing ;-) |
Description
Builds the backend foundation for Home page: the read endpoints that let a user pick a working mill + reporting year and resolve that selection into a context the schedule pages consume. This replaces the hardcoded default the Schedule pages currently fake with a real, server-controlled selection source.
Scope is backend only.
GET /api/v1/mills
GET /api/v1/reporting-years
GET /api/v1/mill-context?millId&year
Type of change
How Has This Been Tested?
Checklist
Further comments
Thanks for the PR!
Deployments, as required, will be available below:
Please create PRs in draft mode. Mark as ready to enable:
After merge, new images are deployed in: