Conversation
Walkthrough앱 버전이 v1.0.4 → v1.0.6로 상향되고 Order 생성 DTO에 Changes
Sequence Diagram(s)sequenceDiagram
participant VM as ViewModel
participant Repo as OrderRepositoryImpl
participant Pref as AuthPreferences
participant API as OrderApi
VM->>Repo: createOrder(items...)
Repo->>Pref: getStoredUser()
Pref-->>Repo: User(agencyId)
Repo->>Repo: requireNonNull(agencyId)
Repo->>API: POST /orders { items..., agencyId }
API-->>Repo: 200 OK
Repo-->>VM: Result(success)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 |
33Auto-Bot
requested review from
CHOOSLA,
Lee-Jong-Jin,
taemin3,
vivivim and
yangjiseonn
![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
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
app/build.gradle.kts(1 hunks)app/src/main/java/com/sampoom/android/feature/order/data/remote/dto/OrderRequestDto.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-29T02:47:43.820Z
Learnt from: Sangyoon98
Repo: 33-Auto/Sampoom-Management-Android PR: 22
File: app/src/main/java/com/sampoom/android/feature/order/domain/repository/OrderRepository.kt:6-9
Timestamp: 2025-10-29T02:47:43.820Z
Learning: In the Sampoom Management Android project, the backend API returns single Order items wrapped in an OrderList structure even for single-item operations like getOrderDetail(orderId) and createOrder(). The repository layer correctly uses Result<OrderList> as the return type to match the backend response format, rather than Result<Order>.
Applied to files:
app/src/main/java/com/sampoom/android/feature/order/data/remote/dto/OrderRequestDto.ktapp/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt
📚 Learning: 2025-10-29T02:47:47.061Z
Learnt from: Sangyoon98
Repo: 33-Auto/Sampoom-Management-Android PR: 22
File: app/src/main/java/com/sampoom/android/feature/cart/data/repository/CartRepositoryImpl.kt:16-22
Timestamp: 2025-10-29T02:47:47.061Z
Learning: Developer Sangyoon98 prefers to use runCatching for consistent error handling in repository implementations, rather than explicit try-catch blocks, in the CartRepositoryImpl class (app/src/main/java/com/sampoom/android/feature/cart/data/repository/CartRepositoryImpl.kt).
Applied to files:
app/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt
🪛 detekt (1.23.8)
app/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt
[warning] 38-38: A call to the default constructor of an exception was detected. Instead one of the constructor overloads should be called. This allows to provide more meaningful exceptions.
(detekt.exceptions.ThrowingExceptionsWithoutMessageOrCause)
🔇 Additional comments (3)
app/build.gradle.kts (1)
35-36: 버전 증가가 적절합니다.AgencyId 파라미터 추가에 맞춰 버전을 적절하게 증가시켰습니다.
app/src/main/java/com/sampoom/android/feature/order/data/remote/dto/OrderRequestDto.kt (1)
4-4: AgencyId 필드 추가가 올바르게 구현되었습니다.데이터 클래스에
agencyId: Long필드가 적절하게 추가되었습니다. OrderRepositoryImpl에서 해당 필드를 사용하도록 업데이트되었습니다.app/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt (1)
62-66: AgencyId가 올바르게 전달되었습니다.
OrderRequestDto생성 시agencyId파라미터가 적절하게 포함되었습니다. 업데이트된 DTO 시그니처와 일치합니다.
app/src/main/java/com/sampoom/android/feature/order/data/repository/OrderRepositoryImpl.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
app/src/main/java/com/sampoom/android/core/preferences/AuthPreferences.kt (1)
72-115: workspace 검증 제거가 올바르게 적용되었습니다.
getStoredUser메서드에서workspace필드 검증이 제거되고(line 88), User 객체 재구성 시role필드가 사용됩니다(line 99). 주문 요청에 필요한agencyId가 적절히 복호화되어 Long 타입으로 변환됩니다(line 107).Line 88의 null-check가 다소 길어 가독성이 떨어질 수 있지만, 모든 필수 필드가 올바르게 검증되고 있습니다.
선택적 개선사항: null-check 가독성 향상
Line 88의 긴 null-check를 여러 줄로 분리하거나 helper 함수로 추출하면 가독성이 향상될 수 있습니다.
- if (userId != null && userName != null && userEmail != null && userRole != null && - accessToken != null && refreshToken != null && userPosition != null && userBranch != null && userAgencyId != null && userStartedAt != null && userEndedAt != null - ) { + val requiredFields = listOf( + userId, userName, userEmail, userRole, accessToken, refreshToken, + userPosition, userBranch, userAgencyId, userStartedAt, userEndedAt + ) + + if (requiredFields.all { it != null }) {app/src/main/java/com/sampoom/android/feature/user/data/repository/UserRepositoryImpl.kt (2)
177-193: 저장된 사용자의 role 값에 대한 검증을 고려하세요.저장된 사용자에서 role을 읽어 바로 API 호출에 사용하고 있습니다. role 값이 빈 문자열이거나 유효하지 않은 경우에 대한 검증이 없어, API 호출 실패나 예상치 못한 동작이 발생할 수 있습니다.
다음과 같이 role 검증을 추가하는 것을 고려하세요:
return runCatching { val user = preferences.getStoredUser() ?: throw Exception() val role = user.role + if (role.isBlank()) throw Exception("Invalid role") val organizationId = user.agencyId
124-124: 추가 검증이 필요합니다. EditEmployeeResponseDto의 role 필드가 non-nullable String으로 정의되어 있는 것을 확인했으므로, 실제 editEmployee 메서드의 전체 컨텍스트를 검토하겠습니다.
ifBlank()함수로 더 간결한 코드 스타일 사용을 권장합니다.현재 방어 로직
takeIf { it.isNotBlank() } ?: employee.role패턴은 유효하지만, Kotlin에서는 기본값을 제공하기 위해ifBlank()함수를 더 간결한 대안으로 사용할 수 있습니다. 다음과 같이 변경을 권장합니다:role = updatedEmployee.role.ifBlank { employee.role }EditEmployeeResponseDto의 role 필드는 non-nullable String이므로 빈 값을 반환할 수 있으며, 현재의 방어 로직은 적절한 패턴입니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
app/src/main/java/com/sampoom/android/core/preferences/AuthPreferences.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/data/mapper/AuthMappers.kt(0 hunks)app/src/main/java/com/sampoom/android/feature/auth/data/remote/dto/LoginRequestDto.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/data/remote/dto/SignUpRequestDto.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/data/repository/AuthRepositoryImpl.kt(3 hunks)app/src/main/java/com/sampoom/android/feature/auth/domain/repository/AuthRepository.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/domain/usecase/SignUpUseCase.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/ui/SignUpUiState.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/auth/ui/SignUpViewModel.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/data/mapper/UserMappers.kt(2 hunks)app/src/main/java/com/sampoom/android/feature/user/data/remote/api/UserApi.kt(3 hunks)app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/EditEmployeeResponseDto.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/EmployeeDto.kt(0 hunks)app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/GetProfileResponseDto.kt(0 hunks)app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/UpdateEmployeeStatusResponseDto.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/data/repository/UserRepositoryImpl.kt(6 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/model/Employee.kt(0 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/model/User.kt(0 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/repository/UserRepository.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/usecase/EditEmployeeUseCase.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/usecase/GetProfileUseCase.kt(1 hunks)app/src/main/java/com/sampoom/android/feature/user/domain/usecase/UpdateEmployeeStatusUseCase.kt(1 hunks)
💤 Files with no reviewable changes (5)
- app/src/main/java/com/sampoom/android/feature/user/domain/model/Employee.kt
- app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/GetProfileResponseDto.kt
- app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/EmployeeDto.kt
- app/src/main/java/com/sampoom/android/feature/user/domain/model/User.kt
- app/src/main/java/com/sampoom/android/feature/auth/data/mapper/AuthMappers.kt
🧰 Additional context used
🧬 Code graph analysis (1)
app/src/main/java/com/sampoom/android/feature/user/data/repository/UserRepositoryImpl.kt (1)
app/src/main/java/com/sampoom/android/core/util/DelayNetwork.kt (1)
retry(7-30)
🔇 Additional comments (21)
app/src/main/java/com/sampoom/android/feature/auth/data/remote/dto/SignUpRequestDto.kt (1)
3-10: 파라미터 이름 변경이 올바르게 적용되었습니다.
workspace에서role로의 이름 변경이 DTO 레이어에서 정확하게 반영되었습니다.app/src/main/java/com/sampoom/android/feature/auth/data/remote/dto/LoginRequestDto.kt (1)
3-7: 파라미터 이름 변경이 올바르게 적용되었습니다.로그인 요청 DTO에서
workspace가role로 일관되게 변경되었습니다.app/src/main/java/com/sampoom/android/feature/auth/ui/SignUpUiState.kt (1)
6-9: UI 상태에서 프로퍼티 이름 변경이 올바르게 적용되었습니다.
workspace에서role로의 변경이 기본값("AGENCY")을 유지하면서 정확하게 반영되었습니다.app/src/main/java/com/sampoom/android/feature/auth/ui/SignUpViewModel.kt (1)
157-164: ViewModel에서 파라미터 바인딩이 올바르게 업데이트되었습니다.
SignUpUseCase호출 시workspace대신role파라미터를 올바르게 전달하고 있습니다.app/src/main/java/com/sampoom/android/feature/auth/domain/repository/AuthRepository.kt (1)
7-14: Repository 인터페이스의 시그니처가 올바르게 업데이트되었습니다.
signUp메서드에서workspace파라미터가role로 일관되게 변경되었습니다.app/src/main/java/com/sampoom/android/feature/auth/domain/usecase/SignUpUseCase.kt (1)
10-24: UseCase에서 파라미터 변경이 올바르게 적용되었습니다.함수 시그니처와 Repository 호출 모두에서
workspace가role로 일관되게 업데이트되었습니다.app/src/main/java/com/sampoom/android/feature/auth/data/repository/AuthRepositoryImpl.kt (2)
22-48: 회원가입 메서드의 파라미터 변경이 올바르게 적용되었습니다.
signUp메서드에서workspace파라미터가role로 변경되고,SignUpRequestDto생성 시 올바르게 전달되고 있습니다.
50-69: 로그인 시 role 값이 하드코딩되어 있습니다.Line 58에서
LoginRequestDto의role파라미터가"AGENCY"로 하드코딩되어 있습니다. 회원가입 플로우는 동적으로role파라미터를 받는 반면, 로그인은 항상"AGENCY"를 사용합니다. 이것이 의도된 동작인지 확인이 필요합니다.
- 만약 로그인이 항상 AGENCY 역할로만 제한되는 것이 정책이라면 현재 구현이 맞습니다.
- 하지만 다른 role(예: VENDOR)로도 로그인이 가능해야 한다면,
signIn메서드에role파라미터를 추가하거나 저장된 사용자 정보에서 role을 가져와야 합니다.app/src/main/java/com/sampoom/android/core/preferences/AuthPreferences.kt (2)
27-40: LGTM! workspace 키 제거가 올바르게 적용되었습니다.Keys 객체에서
USER_WORKSPACE키가 제거되고USER_ROLE로 대체되었으며, 주문 요청에 필요한USER_AGENCY_ID키가 적절히 정의되어 있습니다.
43-59: LGTM! User 저장 로직이 올바르게 업데이트되었습니다.
workspace필드 저장이 제거되고role필드가 저장되며(line 52), 주문 요청에 필요한agencyId가 적절히 암호화되어 저장됩니다(line 55).app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/EditEmployeeResponseDto.kt (1)
3-8: DTO 필드 이름 변경 적용 완료
workspace에서role로의 필드 이름 변경이 올바르게 적용되었습니다.app/src/main/java/com/sampoom/android/feature/user/data/mapper/UserMappers.kt (2)
49-62: 매퍼 개선: 실제 role 값 사용이전에는
role = ""로 빈 문자열을 할당했지만, 이제 DTO에서 전달받은 실제role값을 사용합니다. 이는 데이터 무결성을 향상시키는 개선사항입니다.
64-77: 매퍼 개선: 실제 role 값 사용이전에는
role = ""로 빈 문자열을 할당했지만, 이제 DTO에서 전달받은 실제role값을 사용합니다. 이는 데이터 무결성을 향상시키는 개선사항입니다.app/src/main/java/com/sampoom/android/feature/user/domain/usecase/GetProfileUseCase.kt (1)
7-11: Use Case 파라미터 이름 변경 적용 완료
workspace에서role로 파라미터 이름이 일관되게 변경되었습니다. 로직 변경 없이 이름만 변경되었습니다.app/src/main/java/com/sampoom/android/feature/user/domain/usecase/EditEmployeeUseCase.kt (1)
7-11: Use Case 파라미터 이름 변경 적용 완료
workspace에서role로 파라미터 이름이 일관되게 변경되었습니다.app/src/main/java/com/sampoom/android/feature/user/domain/usecase/UpdateEmployeeStatusUseCase.kt (1)
7-11: Use Case 파라미터 이름 변경 적용 완료
workspace에서role로 파라미터 이름이 일관되게 변경되었습니다.app/src/main/java/com/sampoom/android/feature/user/data/remote/api/UserApi.kt (1)
18-51: 쿼리 파라미터 변경이 모든 엔드포인트에 일관되게 적용되었습니다코드 검색 결과 4개 엔드포인트(getProfile, editEmployee, getEmployeeList, updateEmployeeStatus) 모두에서
@Query("role")을 사용하고 있으며, 모든 호출 지점이role파라미터를 올바르게 전달하고 있습니다. 클라이언트에서는 대부분 "AGENCY"를 기본값으로 사용하고 있습니다.백엔드 API가 새로운
role쿼리 파라미터를 지원하는지 반드시 확인해주세요. 이는 API 계약 변경이므로 백엔드와의 호환성을 사전에 검증하는 것이 중요합니다.app/src/main/java/com/sampoom/android/feature/user/domain/repository/UserRepository.kt (1)
8-16: 모든 파라미터 변경사항이 일관되게 적용되었습니다.검증 결과:
- ✅
getProfile,editEmployee,updateEmployeeStatus메서드 모두workspace→role파라미터 변경 완료- ✅ 세 메서드 모두 UseCase, RepositoryImpl, API 계층에서 일관되게 업데이트됨
- ✅ EditEmployeeViewModel, UpdateEmployeeStatusViewModel에서 올바르게
"AGENCY"값으로 호출- ✅ 코드베이스 전체에서
workspace키워드 없음Repository 인터페이스의 파라미터 일관성 변경이 완전하게 구현되었습니다.
app/src/main/java/com/sampoom/android/feature/user/data/remote/dto/UpdateEmployeeStatusResponseDto.kt (1)
3-8: 필드 이름 변경이 올바르게 적용되었으며, 모든 관련 계층에서 일관되게 구현되었음을 확인했습니다.검증 결과:
- DTO (UpdateEmployeeStatusResponseDto.kt):
role필드 포함 ✓- 매퍼 (UserMappers.kt 64-77줄):
role = role매핑 확인됨 ✓- 리포지토리 (UserRepositoryImpl.kt 156-160줄): 매핑된
role필드 정상 사용 ✓데이터 레이어 전체에서
workspace→role변경이 일관되게 적용되었습니다. 백엔드 API가role필드를 반환하는지 확인하는 것은 좋은 관행이지만, 클라이언트 코드는 올바르게 구현되었습니다.app/src/main/java/com/sampoom/android/feature/user/data/repository/UserRepositoryImpl.kt (2)
31-62: workspace → role 마이그레이션이 올바르게 적용되었습니다.파라미터 변경과 API 호출이 일관되게 수정되었으며, 저장된 토큰 정보와 프로필 정보를 올바르게 병합하고 있습니다.
160-160: 동일한 방어 로직이 일관되게 적용되었습니다.
editEmployee와 동일한 role fallback 패턴이 적용되어 일관성을 유지하고 있습니다. 위의 검증 스크립트로 두 메서드 모두의 API 응답 처리를 확인하세요.
2 participants
📝 Summary
[FIX] 주문 요청 시 AgencyId 파라미터 추가
🙏 Question & PR point
📬 Reference
Summary by CodeRabbit
버전 업데이트
New Features
Refactor