feat: 보관함·대시보드 확정 스케줄 API 연결 - #103
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 41 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Walkthrough대시보드(GET /dashboard)와 스케줄 히스토리(GET /schedule-history, 상세, CSV 내보내기) API를 추가하고, 웹 대시보드·스케줄 히스토리 페이지를 실제 조회/다운로드 흐름으로 전환한다. 공유 스키마, 라우터, 통합 테스트, API 문서도 함께 갱신된다. ChangesDashboard & Schedule History 기능 전체
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 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: 8
🤖 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 `@apps/api/src/modules/schedule-history/schedule-history.service.ts`:
- Around line 79-85: The CSV escaping helper in escapeCsvCell only handles CSV
syntax and does not neutralize formula-injection payloads from user-controlled
values like workerNameSnapshot. Update escapeCsvCell so it also detects cells
starting with =, +, -, @, or those characters after leading whitespace, and
prefix them with a safe character such as apostrophe before applying the
existing quote escaping. Apply the same protection anywhere the same CSV export
logic is used, including the other workerNameSnapshot-related export path
referenced in the diff.
In `@apps/api/test/dashboard.routes.test.ts`:
- Around line 84-132: The dashboard route test currently only seeds one
organization, so it cannot catch regressions where latestConfirmedSchedule is
fetched globally instead of within the logged-in user’s organization scope.
Update the createFakePrisma setup in this test to include a second organization
with a more recent CONFIRMED schedule, then assert that
createApp("/api/dashboard") still returns only the current organization’s data
and its own latest confirmed schedule. Use the existing dashboard.routes.test
case and the latestConfirmedSchedule/organization assertions to verify the
access-control behavior.
In `@apps/api/test/schedule-history.routes.test.ts`:
- Around line 72-291: The schedule history route tests are missing
validation-failure coverage for the `validate()`-protected inputs. Add one or
two Supertest cases in `schedule-history.routes.test.ts` that hit `GET
/api/schedule-history` with an invalid `year/month` query (for example
`month=13`) and/or `GET /api/schedule-history/:scheduleId` with a non-numeric
id, and assert the response is `400` with `VALIDATION_ERROR`. Use the existing
`createApp`, `authHeader`, and route paths to locate the relevant test blocks.
- Around line 109-291: The schedule-history route tests currently only seed one
organization, so they do not catch organization-scope leakage. Update the
existing cases around createApp, createFakePrisma, and the /api/schedule-history
list/detail/export.csv requests to include a second organization with a newer
CONFIRMED schedule and a matching detail target, then assert the logged-in org
only sees its own data. Verify the foreign-org schedule is excluded from the
list and that detail/CSV calls for it return 404 with SCHEDULE_NOT_FOUND, using
the schedule-history route handlers and confirmed schedule fixtures to locate
the affected tests.
In `@apps/web/src/features/dashboard/components/mvp-dashboard-page.tsx`:
- Around line 61-63: The `formatDateTimeToTime()` helper is dropping the date
and making overnight ranges like `startsAt`/`endsAt` look like same-day shifts.
Update the time formatting logic in `mvp-dashboard-page.tsx` to preserve or
indicate next-day end times, and apply the same fix anywhere the copied helper
is used in the archive page so both views handle overnight boundaries
consistently. Use the existing schedule display code around
`formatDateTimeToTime()` and the `startsAt`/`endsAt` rendering as the place to
centralize this behavior.
In
`@apps/web/src/features/schedule-history/components/mvp-schedule-history-page.tsx`:
- Around line 25-26: The schedule history year filter is incorrectly capped by
HISTORY_YEAR_OPTIONS in mvp-schedule-history-page, which hides older CONFIRMED
records that still exist on the server. Update the availableYears/year option
logic so it is not limited to the current year minus six; instead derive options
from server-provided years or another uncapped discovery mechanism, and make
sure the filtering/export flow in this page can surface all available history
years.
- Around line 143-146: The schedule history detail query is being treated as
loading even when it is disabled, which leaves the page stuck on a loading state
for empty year/month selections. Update the loading logic in
mvp-schedule-history-page and the useScheduleHistoryDetailQuery result handling
so disabled state does not count as pending; only show loading when
selectedScheduleId is non-empty and the detail query is actually pending, or
switch the UI condition to use isFetching instead of isPending.
In `@docs/API.md`:
- Around line 579-602: The CSV export contract for GET
/schedule-history/:scheduleId/export.csv is missing the BOM requirement, which
should be documented alongside the existing UTF-8 content type. Update the API
contract in docs/API.md near the schedule history CSV export section to
explicitly state that the response includes a UTF-8 BOM, so consumers and QA can
rely on the exact file format. Keep the wording aligned with the existing
response description and CSV format notes.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 72330de5-a13e-48e5-96ec-fa54efed0d83
📒 Files selected for processing (22)
apps/api/src/modules/dashboard/dashboard.handlers.tsapps/api/src/modules/dashboard/dashboard.service.tsapps/api/src/modules/organization/organization.service.tsapps/api/src/modules/schedule-history/schedule-history.handlers.tsapps/api/src/modules/schedule-history/schedule-history.service.tsapps/api/src/routes/dashboard.routes.tsapps/api/src/routes/index.tsapps/api/src/routes/schedule-history.routes.tsapps/api/test/dashboard.routes.test.tsapps/api/test/helpers/fake-prisma.tsapps/api/test/schedule-history.routes.test.tsapps/web/src/features/dashboard/api/dashboard-api.tsapps/web/src/features/dashboard/components/mvp-dashboard-page.tsxapps/web/src/features/dashboard/queries/dashboard-queries.tsapps/web/src/features/dashboard/queries/dashboard-query-keys.tsapps/web/src/features/schedule-history/api/schedule-history-api.tsapps/web/src/features/schedule-history/components/mvp-schedule-history-page.tsxapps/web/src/features/schedule-history/queries/schedule-history-queries.tsapps/web/src/features/schedule-history/queries/schedule-history-query-keys.tsapps/web/src/lib/api-client.tsdocs/API.mdpackages/shared/src/schemas/dashboard.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web/src/features/schedule-history/api/schedule-history-api.ts (1)
12-18: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
month단독 쿼리를 여기서 막아 주세요.
/schedule-history계약상month는year와 함께 전달돼야 하는데, 현재는query.month만 있어도 그대로 붙습니다. 호출부가 실수하면 바로 400 검증 오류로 끝나므로 이 helper에서 조합을 보정하는 편이 안전합니다.수정 예시
if (query.year !== undefined) { searchParams.set("year", String(query.year)); } - if (query.month !== undefined) { + if (query.year !== undefined && query.month !== undefined) { searchParams.set("month", String(query.month)); }As per path instructions,
docs/API.mdsays “month는 year와 함께 전달(조건 불일치 시 validation 흐름 유지)”.🤖 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 `@apps/web/src/features/schedule-history/api/schedule-history-api.ts` around lines 12 - 18, The schedule-history query builder currently appends month whenever query.month is present, even if year is missing. Update the helper in schedule-history-api.ts so month is only included when year is also set, keeping the query shape aligned with the /schedule-history contract. Use the existing query.year and query.month checks in the same function to gate month insertion together, so standalone month inputs are ignored rather than forwarded.Source: Path instructions
🤖 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
`@apps/web/src/features/schedule-history/components/mvp-schedule-history-page.tsx`:
- Around line 65-71: The `formatScheduleAssignmentTimeRange` logic is duplicated
in `mvp-schedule-history-page.tsx` and `mvp-dashboard-page.tsx`, so move this
shared time-range formatting into a common util and have both pages call that
single helper. Keep the existing `formatScheduleAssignmentTimeRange` behavior,
but replace the copied implementation with an import from the shared utility so
future fixes stay in sync.
---
Outside diff comments:
In `@apps/web/src/features/schedule-history/api/schedule-history-api.ts`:
- Around line 12-18: The schedule-history query builder currently appends month
whenever query.month is present, even if year is missing. Update the helper in
schedule-history-api.ts so month is only included when year is also set, keeping
the query shape aligned with the /schedule-history contract. Use the existing
query.year and query.month checks in the same function to gate month insertion
together, so standalone month inputs are ignored rather than forwarded.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: bb2b7a1e-dcb4-4de6-9cea-949789b566d3
📒 Files selected for processing (9)
apps/api/src/modules/schedule-history/schedule-history.service.tsapps/api/test/dashboard.routes.test.tsapps/api/test/schedule-history.routes.test.tsapps/web/src/features/dashboard/components/mvp-dashboard-page.tsxapps/web/src/features/schedule-history/api/schedule-history-api.tsapps/web/src/features/schedule-history/components/mvp-schedule-history-page.tsxapps/web/src/features/schedule-history/queries/schedule-history-queries.tsdocs/API.mdpackages/shared/src/schemas/schedule-history.ts
meteorqz6
approved these changes
Jun 30, 2026
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
2 participants
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.
요약
검증
Summary by CodeRabbit