[FEAT] 캘린더 통합조회 GET /api/calendar 구현 - #247
Conversation
OWNER: 본인이 만든 프로젝트 기간(createdAt~dueDate, 요청 월과 겹치는 것만) LEADER/MEMBER: 본인 PERSONAL 액션 마감일 + 개인 Todo 통합 반환(TEAM 액션 제외) Project에 startDate 필드가 없어 createdAt을 임시 시작점으로 사용(진짜 필드 추가는 공용 테이블 마이그레이션이라 스코프 밖으로 결정). project·action· calendar 모두 동일 담당자 소유라 ACL 포트 없이 도메인 Repository를 직접 조합.
|
Warning Review limit reached
Next review available in: 38 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: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
Changes통합 캘린더 조회
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CalendarController
participant CalendarQueryService
participant ProjectRepository
participant ActionRepository
participant PersonalTodoRepository
CalendarController->>CalendarQueryService: 회사·회원·권한·조회 월 전달
CalendarQueryService->>ProjectRepository: OWNER 프로젝트 조회
CalendarQueryService->>ActionRepository: PERSONAL 액션 조회
CalendarQueryService->>PersonalTodoRepository: 개인 Todo 조회
CalendarQueryService-->>CalendarController: CalendarItem 목록 반환
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
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: 1
🧹 Nitpick comments (1)
src/test/java/com/module06/backend/calendar/presentation/api/CalendarControllerTest.java (1)
65-75: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win기본 월 인자를 직접 검증하세요.
Line 74는 응답이 배열인지 만 검증합니다.
getCalendarUseCase가 다른YearMonth로 호출되어도 Mockito의 기본 빈 리스트 때문에 이 테스트는 통과할 수 있습니다.
요청 전YearMonth expectedMonth를 저장하고,verify(getCalendarUseCase)로 그 값을 전달했는지 검증하세요.🤖 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 `@src/test/java/com/module06/backend/calendar/presentation/api/CalendarControllerTest.java` around lines 65 - 75, Update defaultsToCurrentMonthWhenOmitted to capture YearMonth.now() in an expectedMonth variable before stubbing and use it in the getCalendarUseCase expectation. After the request, verify getCalendarUseCase was called with COMPANY, MEMBER, "MEMBER", and expectedMonth so the default month argument is explicitly validated.
🤖 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
`@src/main/java/com/module06/backend/calendar/application/service/CalendarQueryService.java`:
- Around line 86-89: Update the Personal Todo lookup in CalendarQueryService to
include the current company ID alongside memberId and the date range, using the
corresponding repository method and passing the active company context. Add a
regression test verifying that Todos belonging to another company are excluded
from the current company’s calendar.
---
Nitpick comments:
In
`@src/test/java/com/module06/backend/calendar/presentation/api/CalendarControllerTest.java`:
- Around line 65-75: Update defaultsToCurrentMonthWhenOmitted to capture
YearMonth.now() in an expectedMonth variable before stubbing and use it in the
getCalendarUseCase expectation. After the request, verify getCalendarUseCase was
called with COMPANY, MEMBER, "MEMBER", and expectedMonth so the default month
argument is explicitly validated.
🪄 Autofix
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: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 98512ef1-d92f-4535-8dba-6dabedb0ffaa
📒 Files selected for processing (12)
src/main/java/com/module06/backend/calendar/application/service/CalendarQueryService.javasrc/main/java/com/module06/backend/calendar/application/usecase/CalendarItem.javasrc/main/java/com/module06/backend/calendar/application/usecase/CalendarItemType.javasrc/main/java/com/module06/backend/calendar/application/usecase/GetCalendarUseCase.javasrc/main/java/com/module06/backend/calendar/presentation/api/CalendarController.javasrc/main/java/com/module06/backend/calendar/presentation/api/TodoController.javasrc/main/java/com/module06/backend/calendar/presentation/api/response/CalendarItemResponse.javasrc/main/java/com/module06/backend/project/domain/repository/ProjectRepository.javasrc/main/java/com/module06/backend/project/infrastructure/persistence/ProjectPersistenceAdapter.javasrc/main/java/com/module06/backend/project/infrastructure/persistence/SpringDataProjectRepository.javasrc/test/java/com/module06/backend/calendar/application/service/CalendarQueryServiceTest.javasrc/test/java/com/module06/backend/calendar/presentation/api/CalendarControllerTest.java
TodoController·CalendarController — C 도메인 컨트롤러 전체(project·action)에 @Tag/@operation을 추가하던 김에 이 PR 범위(calendar)도 같이 맞춘다. 로직 변경 없음.
2 participants
📌 연관 이슈
📝 작업 내용
GET /api/calendar?month=yyyy-MM신규 — 역할별 단일 통합 엔드포인트createdAt~dueDate)이 요청 월과 겹치는 것만 반환ProjectRepository에findAllByCompanyIdAndCreatedBy신규(OWNER 화면 전용)🖥️ 프론트엔드 연동 가이드 (API 명세)
1. 주요 엔드포인트
GET/api/calendar?month=yyyy-MM: 역할별 캘린더 통합 조회 (month생략 시 이번 달)2. 요청 파라미터 (Request)
yyyy-MM형식, 생략 시 서버 기준 이번 달3. 정상 응답 예시 (200 OK)
응답 JSON 보기 (클릭)
{ "httpStatus": 200, "message": "캘린더를 조회했습니다.", "data": [ { "type": "PROJECT", "title": "프로젝트명", "tag": "TAG-1", "startDate": "2026-08-01", "endDate": "2026-08-20" }, { "type": "ACTION", "title": "액션 제목", "tag": null, "startDate": "2026-08-15", "endDate": "2026-08-15" }, { "type": "TODO", "title": "Todo 내용", "tag": null, "startDate": "2026-08-20", "endDate": "2026-08-20" } ] }4.⚠️ 프론트엔드 참고 및 주의사항
type에 따라 응답 항목이 배타적입니다 — OWNER 로그인 시PROJECT만, LEADER/MEMBER 로그인 시ACTION·TODO만 섞여서 나옵니다.startDate == endDate입니다.PROJECT만 기간(span)입니다.tag는 PROJECT에만 값이 있고, ACTION·TODO는 항상null입니다.Project에 아직 진짜startDate필드가 없어createdAt(생성일)을 임시 시작점으로 씁니다 — 프로젝트 생성일과 실제 착수일이 다르면 간트 시작점이 부정확할 수 있습니다.🚨 주요 에러 코드 및 예외 (Exceptions)
💡 백엔드 리뷰 포인트 (Backend Review)
ProjectQueryPort패턴과는 의도적으로 다른 선택).ActionRepository.findAllByAssigneeMemberId가 companyId로 스코프되지 않아 서비스 레이어에서 방어적으로companyId필터를 추가로 걸었습니다. 이게 맞는 방어 위치인지 의견 부탁드립니다.Project.startDate부재로createdAt을 임시 대체값으로 쓴 점 — 진짜 필드 추가(마이그레이션) 필요 여부는 이슈 #246에 후속 논의로 남겨뒀습니다.✅ 체크리스트
Summary by CodeRabbit
새 기능
테스트