Implement project list#38
Open
sprucely wants to merge 3 commits into
Open
Conversation
📝 WalkthroughWalkthroughThis PR adds a Project List API backed by fiscal-year parsing, database queries, aggregation, and stored procedure changes. It also adds a client project-identification stage with tabs, summaries, search, retry handling, workflow integration, and expanded tests. ChangesProject List feature
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant Browser
participant ProjectIdentificationStage
participant ProjectListController
participant ProjectListService
participant GetProjectList
Browser->>ProjectIdentificationStage: render project-identification stage
ProjectIdentificationStage->>ProjectListController: GET /api/projectlist?fy=FY26
ProjectListController->>ProjectListService: validate FY and call GetAsync
ProjectListService->>GetProjectList: execute stored procedure
GetProjectList-->>ProjectListService: project rows
ProjectListService-->>ProjectListController: aggregated ProjectListResponse
ProjectListController-->>ProjectIdentificationStage: return response
ProjectIdentificationStage->>ProjectIdentificationStage: filter and display rows
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
tests/server.tests/Models/FiscalYearCycleTests.cs (1)
8-28: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider adding test cases for 4-digit years and 2-digit boundaries.
The valid-case theory only covers
"FY25"and"fy26". Adding"FY2025"(4-digit path) and"FY00"/"FY99"(2-digit boundaries) would verify theshortYear < 100 ? 2000 + shortYear : shortYearbranch and edge values.🧪 Suggested InlineData additions
[InlineData("FY25", "FY25", 2024, 10, 1, 2025, 9, 30)] [InlineData("fy26", "FY26", 2025, 10, 1, 2026, 9, 30)] + [InlineData("FY2025", "FY25", 2024, 10, 1, 2025, 9, 30)] + [InlineData("FY00", "FY00", 1999, 10, 1, 2000, 9, 30)] + [InlineData("FY99", "FY99", 2098, 10, 1, 2099, 9, 30)]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/server.tests/Models/FiscalYearCycleTests.cs` around lines 8 - 28, The FiscalYearCycle.TryParse test only covers mid-range 2-digit inputs, so add cases for the 4-digit parse path and the 2-digit boundary values. Extend TryParse_maps_fiscal_year_to_cycle_dates in FiscalYearCycleTests with InlineData for "FY2025" plus "FY00" and "FY99", and assert the expected FiscalYear, CycleStart, and CycleEnd so the shortYear conversion branch is exercised.client/src/components/ProjectIdentificationStage.tsx (1)
141-142: 📐 Maintainability & Code Quality | 🔵 TrivialVerify
workflow-panelclasses align with Tailwind/DaisyUI guidelines.The
workflow-panelandworkflow-panel__headerclasses use BEM-style custom CSS. The coding guidelines prefer Tailwind CSS classes unless necessary, while also allowing UC Davis Gunrock design system patterns. Confirm these classes are part of the Gunrock design system; otherwise, consider replacing with Tailwind utilities.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@client/src/components/ProjectIdentificationStage.tsx` around lines 141 - 142, The `workflow-panel` and `workflow-panel__header` wrappers in `ProjectIdentificationStage` should be checked against the Gunrock design system, since they currently use custom BEM-style classes that may conflict with the Tailwind/DaisyUI preference. If these class names are not part of the approved design system, replace them with equivalent Tailwind utility classes and keep the surrounding JSX structure in `ProjectIdentificationStage` consistent with the existing layout.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@client/src/components/ProjectIdentificationStage.tsx`:
- Around line 63-65: ProjectIdentificationStage currently only checks data and
isLoading, so a failed useQuery can leave the loading state stuck forever.
Update the query handling in ProjectIdentificationStage (and the other matching
location noted in the review) to also read the error state from
useQuery/projectListQueryOptions, render an error message when the fetch fails
after retries, and provide a retry action that re-runs the query instead of
continuing to show “Loading project list...”.
In `@server/Models/FiscalYearCycle.cs`:
- Around line 27-32: Add explicit bounds validation in the FiscalYearCycle
parsing flow before constructing the DateOnly values. In the logic that computes
endYear and startYear for the FiscalYearCycle constructor, reject parsed years
outside the supported range so endYear stays within 2 to 9999 (and startYear
remains valid) instead of letting DateOnly throw ArgumentOutOfRangeException.
Make the parse path return a validation failure/400-style result for invalid
inputs like "FY10000" rather than creating the FiscalYearCycle with invalid
dates.
---
Nitpick comments:
In `@client/src/components/ProjectIdentificationStage.tsx`:
- Around line 141-142: The `workflow-panel` and `workflow-panel__header`
wrappers in `ProjectIdentificationStage` should be checked against the Gunrock
design system, since they currently use custom BEM-style classes that may
conflict with the Tailwind/DaisyUI preference. If these class names are not part
of the approved design system, replace them with equivalent Tailwind utility
classes and keep the surrounding JSX structure in `ProjectIdentificationStage`
consistent with the existing layout.
In `@tests/server.tests/Models/FiscalYearCycleTests.cs`:
- Around line 8-28: The FiscalYearCycle.TryParse test only covers mid-range
2-digit inputs, so add cases for the 4-digit parse path and the 2-digit boundary
values. Extend TryParse_maps_fiscal_year_to_cycle_dates in FiscalYearCycleTests
with InlineData for "FY2025" plus "FY00" and "FY99", and assert the expected
FiscalYear, CycleStart, and CycleEnd so the shortYear conversion branch is
exercised.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 71c774af-2b1b-416b-b557-0c960ad85f7a
📒 Files selected for processing (15)
client/src/components/ProjectIdentificationStage.tsxclient/src/queries/projectList.tsclient/src/routes/(authenticated)/workflow.$stageId.tsxclient/src/test/routes/(authenticated)/workflow.test.tsxdatabase/data/StoredProcedures/GetProjectList.sqlserver/Controllers/ProjectListController.csserver/Models/FiscalYearCycle.csserver/Models/ProjectList/ProjectListDtos.csserver/Program.csserver/ProjectList/IProjectListService.csserver/ProjectList/ProjectListResponseFactory.csserver/ProjectList/ProjectListService.cstests/server.tests/Models/FiscalYearCycleTests.cstests/server.tests/ProjectList/ProjectListControllerTests.cstests/server.tests/ProjectList/ProjectListResponseFactoryTests.cs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #17
Summary by CodeRabbit
New Features
Bug Fixes