feat: 방장 일정 등록 폼 추가 및 대시보드 연동 기능 구현 - #78
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 41 minutes and 9 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
Walkthrough
Changes참여자 userId 연동
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/lib/schedules/store.ts (1)
155-182:⚠️ Potential issue | 🟠 Major | ⚡ Quick win인증 참여자를 여전히 이름으로만 매칭하면 중복 제출과 오버라이트가 발생합니다.
이유: 이제
userId를 저장하면서도 기존 레코드 조회는scheduleId + name만 사용합니다. 그래서 같은 사용자가 표시 이름을 바꾸면 새 행이 생기고, 반대로 서로 다른 사용자가 같은 이름을 쓰면 기존 제출을 덮어쓸 수 있습니다. 이번 PR의userId연동 목적 자체가 여기서 깨집니다.수정:
핵심 수정 예시
const normName = normalizeParticipantName(input.name); const existing = await tx.scheduleParticipant.findFirst({ - where: { scheduleId, name: normName }, + where: input.userId + ? { scheduleId, userId: input.userId } + : { scheduleId, name: normName }, }); if (existing) { return tx.scheduleParticipant.update({ where: { id: existing.id }, data: { + name: normName, available: JSON.stringify( normalizeAvailability(schedule, input.available), ), submittedAt: new Date(), userId: input.userId ?? existing.userId, }, }); }🤖 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/lib/schedules/store.ts` around lines 155 - 182, The findFirst query in the participant lookup is only matching on scheduleId and the normalized name, ignoring the userId even though it's now being persisted. This causes issues where the same authenticated user changing their display name creates duplicate records, and different users with identical names can overwrite each other's submissions. Modify the where clause in the findFirst call to conditionally include userId in the matching criteria when the input has a userId value, so that authenticated participants are matched by (scheduleId, normalizedName, userId) and unauthenticated ones by (scheduleId, normalizedName) only. This ensures proper deduplication at the user level when userId is available.
🤖 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 `@prisma/schema.prisma`:
- Around line 70-72: The ScheduleParticipant model in the Prisma schema is
missing an index on the userId field, which causes performance degradation when
the dashboard queries schedules using participants.some.userId. Add a new index
entry for userId in the @@index array to enable efficient lookups, allowing the
database to avoid full table scans as the ScheduleParticipant table grows. The
existing scheduleId index should remain alongside the new userId index.
In `@src/app/api/schedules/`[id]/availability/route.ts:
- Around line 20-25: The code is using getSession() to retrieve the userId for
database operations, but this method only trusts client cookies without
cryptographic verification, creating a security vulnerability where clients can
inject arbitrary userIds into the participants table. Replace the getSession()
call with getUser() which validates the JWT cryptographically with the Auth
server, ensuring the userId passed to addParticipantAvailability() is properly
authenticated and cannot be spoofed.
In `@src/app/schedule/`[id]/ScheduleRoomClient.tsx:
- Around line 284-289: The isHostView logic in the useMemo function (lines
284-289) immediately returns true when currentUser.id matches
schedule.creatorId, which prevents the host/creator from accessing the
submission form that only renders when isHostView is false (lines 478-709). To
fix this, you need to either: (1) modify the isHostView condition to check if
the creator has already submitted their availability before switching to host
view, OR (2) ensure the submission form is also rendered within the HostView
component so creators can submit their availability. Choose one approach and
implement it consistently - if you modify the isHostView logic, verify the
submission form is accessible to creators; if you add the form to HostView,
ensure it's not duplicated elsewhere.
---
Outside diff comments:
In `@src/lib/schedules/store.ts`:
- Around line 155-182: The findFirst query in the participant lookup is only
matching on scheduleId and the normalized name, ignoring the userId even though
it's now being persisted. This causes issues where the same authenticated user
changing their display name creates duplicate records, and different users with
identical names can overwrite each other's submissions. Modify the where clause
in the findFirst call to conditionally include userId in the matching criteria
when the input has a userId value, so that authenticated participants are
matched by (scheduleId, normalizedName, userId) and unauthenticated ones by
(scheduleId, normalizedName) only. This ensures proper deduplication at the user
level when userId is available.
🪄 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: 3cd84caf-d86f-486c-a2bd-d94d14ac30ea
📒 Files selected for processing (5)
prisma/schema.prismasrc/app/api/schedules/[id]/availability/route.tssrc/app/dashboard/page.tsxsrc/app/schedule/[id]/ScheduleRoomClient.tsxsrc/lib/schedules/store.ts
| const isHostView = useMemo(() => { | ||
| if (!schedule || !("participants" in schedule)) return false; | ||
| if (hostToken) return true; | ||
| // 호스트가 "일정 등록하기"로 진입한 경우(?participate=1)에는 | ||
| // 생성자여도 결과 화면이 아닌 참여(가능 시간 입력) 폼을 보여준다. | ||
| if (forceParticipant) return false; | ||
| if (currentUser && schedule.creatorId === currentUser.id) return true; | ||
| return false; | ||
| }, [schedule, hostToken, currentUser, forceParticipant]); | ||
| }, [schedule, hostToken, currentUser]); |
There was a problem hiding this comment.
creatorId만으로 즉시 호스트 뷰로 보내면 방장 제출 경로가 사라집니다.
이유: 현재는 currentUser.id === schedule.creatorId면 바로 호스트 뷰로 전환되는데, 같은 파일 Line 478-709의 제출 폼은 !isHostView일 때만 렌더링됩니다. 그런데 HostView 쪽에는 방장 자신의 가능 시간을 보내는 경로가 없어서, 이번 PR의 핵심 목표인 “방장도 일정 제출”이 여전히 막힙니다.
수정: 최소한 “내가 이미 제출했는가”를 확인한 뒤에만 호스트 뷰로 넘기거나, 의도대로라면 HostView 상단에 동일한 제출 폼을 함께 렌더링해야 합니다.
핵심 수정 예시
+ const hasOwnSubmission = useMemo(() => {
+ if (!schedule || !("participants" in schedule) || !currentUser) return false;
+ return schedule.participants.some(
+ (participant) => participant.userId === currentUser.id,
+ );
+ }, [schedule, currentUser]);
+
const isHostView = useMemo(() => {
if (!schedule || !("participants" in schedule)) return false;
if (hostToken) return true;
- if (currentUser && schedule.creatorId === currentUser.id) return true;
+ if (
+ currentUser &&
+ schedule.creatorId === currentUser.id &&
+ hasOwnSubmission
+ ) {
+ return true;
+ }
return false;
- }, [schedule, hostToken, currentUser]);
+ }, [schedule, hostToken, currentUser, hasOwnSubmission]);🤖 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/app/schedule/`[id]/ScheduleRoomClient.tsx around lines 284 - 289, The
isHostView logic in the useMemo function (lines 284-289) immediately returns
true when currentUser.id matches schedule.creatorId, which prevents the
host/creator from accessing the submission form that only renders when
isHostView is false (lines 478-709). To fix this, you need to either: (1) modify
the isHostView condition to check if the creator has already submitted their
availability before switching to host view, OR (2) ensure the submission form is
also rendered within the HostView component so creators can submit their
availability. Choose one approach and implement it consistently - if you modify
the isHostView logic, verify the submission form is accessible to creators; if
you add the form to HostView, ensure it's not duplicated elsewhere.
🚀 작업 내용 (What)
📣 핵심 변경 이유 (Why)
ScheduleParticipant모델에userId필드를 추가하여 일정 제출 시 유저 계정과 연동되도록 수정. (prisma db push필요)/dashboard에서 내가 생성한 모임(creatorId)뿐만 아니라, 내가 참여자로 등록된 모임도 함께 불러와 달력과 목록에 표시하도록 쿼리 수정.📸 스크린샷 (Visuals, 선택)
🔗 관련 이슈 (Issue)
Close #