Feat: 시니또용 카테고리별 가이드라인 조회 api 추가 및 기존 api 삭제 (프론트 요청) #114
Conversation
eunsoni
added
✨ Feature
eunsoni
changed the title
| return ResponseEntity.ok(guardGuidelineService.readAllGuardGuidelinesByCategoryAndSenior(memberId, seniorId, type)); | ||
| } | ||
|
|
||
| @Operation(summary = "카테고리에 해당하는 모든 가이드라인 조회(시니또용)", description = "시니또용 앱에서 카테고리에 해당하는 모든 가이드라인들을 요청할 때 필요합니다.") |
There was a problem hiding this comment.
이부분이 콜백 요청 수락하기 전에 확인하는 가이드라인 정보 제공하는 용도인거죠?? 헷갈려가지구 남깁니다!
There was a problem hiding this comment.
네 콜백 수락하기 전에 시니또가 가이드라인 확인하는 용도입니다!
| @Operation(summary = "카테고리에 해당하는 모든 가이드라인 조회(보호자용)", description = "보호자용 앱에서 카테고리에 해당하는 모든 가이드라인들을 요청할 때 필요합니다.") | ||
| @GetMapping("/guard/{seniorId}/{type}") | ||
| public ResponseEntity<List<GuardGuidelineResponse>> getGuardGuidelinesByCategoryAndSenior(@MemberId Long memberId, @PathVariable Long seniorId, @PathVariable GuardGuideline.Type type) { | ||
| return ResponseEntity.ok(guardGuidelineService.readAllGuardGuidelinesByCategoryAndSenior(memberId, seniorId, type)); | ||
| } | ||
|
|
||
| @Operation(summary = "카테고리에 해당하는 모든 가이드라인 조회(시니또용)", description = "시니또용 앱에서 카테고리에 해당하는 모든 가이드라인들을 요청할 때 필요합니다.") | ||
| @GetMapping("/sinitto/{callbackId}/{type}") | ||
| public ResponseEntity<List<GuardGuidelineResponse>> getGuardGuidelinesByCategoryAndCallback(@PathVariable Long callbackId, @PathVariable GuardGuideline.Type type) { | ||
| return ResponseEntity.ok(guardGuidelineService.readAllGuardGuidelinesByCategoryAndCallback(callbackId, type)); |
There was a problem hiding this comment.
카테고리(TAXI, DELEVERY)입니다!
| @Operation(summary = "카테고리에 해당하는 모든 가이드라인 조회(시니또용)", description = "시니또용 앱에서 카테고리에 해당하는 모든 가이드라인들을 요청할 때 필요합니다.") | ||
| @GetMapping("/sinitto/{callbackId}/{type}") | ||
| public ResponseEntity<List<GuardGuidelineResponse>> getGuardGuidelinesByCategoryAndCallback(@PathVariable Long callbackId, @PathVariable GuardGuideline.Type type) { | ||
| return ResponseEntity.ok(guardGuidelineService.readAllGuardGuidelinesByCategoryAndCallback(callbackId, type)); | ||
| } |
There was a problem hiding this comment.
시니또가 콜백을 수행하면서 보는 가이드라인은 어떤 api를 요청하는건가요?
해당 api는 callback의 status가 waiting일때만 응답받을 수 있는 것 같아서요
There was a problem hiding this comment.
와 예리하신데요 ~? 놓친 부분이었어요 감사합니다 👍
api 요청한 시니또가 콜백에 배정된 시니또가 아닌지 검증하고 예외 처리하도록 수정해두었어요!
There was a problem hiding this comment.
엇 해당 부분도 필요할 것 같긴 한데, 제가 궁금한 점은 시니또가 콜백을 수행하면서 보는 가이드라인은 waiting 상태가 아니라 진행중상태일 것 같은데 해당 상황에서 가이드라인을 보기 위해 프론트에서 어떤 api를 요청해야할지 해당 controller에서는 찾을 수 없어서 여쭤봤습니다!
There was a problem hiding this comment.
같은 맥락에서 콜백 상태가 waiting인지 검증하는 로직은 어떤 이유로 넣으셨나요?
There was a problem hiding this comment.
if (callback.getStatus() != Callback.Status.WAITING.name() && callback.getAssignedMemberId() != memberId) { throw new BadRequestException("해당 콜백은 대기 상태가 아니고, 배정 시니또가 아닙니다."); }
수정된 로직에서는 1. 콜백이 대기상태가 아니면서 2. 해당 콜백에 배정된 시니또가 'API 요청한 회원'이 아닌 경우에만 예외처리합니다. 그래서 지호님이 말씀하신 시니또가 콜백을 수행하면서 가이드라인 조회를 요청하는 경우에는 1번 조건에 해당되긴 하지만 2번 조건은 만족하지 않으므로, 예외처리 되지 않고 정상적으로 가이드라인이 조회되게 됩니다!
(Swagger에서 데이터 받아오는 것을 확인했습니다)
There was a problem hiding this comment.
추가로 waiting 상태인지 검증하는 이유는 시니또가 가이드라인을 조회하는 순간에 이미 다른 시니또가 콜백을 수락했다면 더 이상 그 콜백의 가이드라인을 확인할 이유가 없기 때문입니다.
프론트에서 요청을 해주셨고 저도 UX 측면에서 수정하는 것이 좋을 것 같다고 생각했습니다!
There was a problem hiding this comment.
아~ 저는 api 분리로 비슷한 로직을 작성했어서 단순 배정 시니또 검증 로직만 추가한 줄 알았습니다
해당 방식은 하나의 api로 두개의 역할을 할 수 있어 좋네요~~ 👍
늦은 시간인데 빠른 답변 감사드립니다 😄
| Callback callback = callbackRepository.findById(callbackId) | ||
| .orElseThrow(() -> new NotFoundException("존재하지 않는 콜백입니다")); | ||
|
|
||
| if (callback.getStatus() != Callback.Status.WAITING.name()) { |
There was a problem hiding this comment.
배운점:
==는 참조 비교라서 이렇게하면 항상 true 가 될 것이라고 생각했었는데, String Pool 이란걸 자바에서 지원해서 값 비교와 같은 결과를 나오게 해주네요. 책에서 본거같긴한데 이번에 제가 크게 착각한 부분이라 한번 멘트 적어봅니다 😥
https://studywithus.tistory.com/88
https://www.baeldung.com/java-string-pool
https://f-lab.kr/insight/understanding-java-string-pool
* Deploy: PR 생성시 테스트코드 수행 로직 구현 (#94) * deploy: PR 생성시 테스트코드 수행 로직 추가 * feat: jwt.secret키를 깃허브 시크릿에 저장 및 환경변수 설정 * feat: 환경변수 읽어오도록 수정 * feat: 도커를 사용하여 레디스 환경 구축 * Deploy: 깃허브 액션 최신버전으로 업그레이드 (#96) * deploy: deploy.yml 버전 업그레이드 * 깃허브 testcode.yml 버전 업그레이드 * deploy: 가장 최신 버전으로 업그레이드 * deploy: 가장 최신 버전으로 업그레이드 * Fix: 안부전화 Cascade 순환참조 문제 해결 및 관계성 오류 해결 구현 (#100) fix: 안부전화 Cascade 순환참조 문제 해결 및 관계성 오류 해결 * Refactor: 가이드라인 관련 로직 수정 {프론트 요청) (#103) * deploy: 가이드라인 더미데이터 추가 * feat: 콜백과 가이드라인의 시니어가 같지 않을 때 발생하는 예외 구현 * refactor: 타입별 전체 가이드라인 및 특정 가이드라인 조회 시 검증 로직 추가 * refactor: 가이드라인 조회 api 매개변수 수정 * refactor: Reformat code * refactor: 가이드라인 response dto에 id 추가 및 서비스단 수정 * refactor: 중복 주석 삭제 * refactor: 서비스단에서 사용하지 않는 레퍼지토리 선언 삭제 * fix: url 중복 오류해결 (#106) * Refactor: 예외 처리 관련 리팩토링 (#92) * refactor: 콜백 도메인 예외 처리 리팩토링 * refactor: Auth 도메인 예외 처리 리팩토링 * refactor: Guard 도메인 예외 처리 리팩토링 * refactor: GuardGuideline 도메인 예외 처리 리팩토링 * refactor: HelloCall 도메인 예외 처리 리팩토링 * fix: 리팩토링후 콜백 Test 코드 수정안하여 생긴 테스트 실패 수정 * refactor: Member 도메인 예외 처리 리팩토링 * refactor: Point 도메인 예외 처리 리팩토링 * refactor: Review 도메인 예외 처리 리팩토링 * refactor: Sinitto 도메인 예외 처리 리팩토링 * refactor: 사용안되는 exception class, advice class 제거, * refactor: HelloCallPriceService 에서 IllegalArgumentException -> BadRequestException * refactor: 포인트로그 Content 멘트 수정 * refactor: 포인트로그 Content 멘트 최종 수정 * refactor: MultiStatusException->ConflictException * refactor: TokenService의 응답코드 다양화 * refactor: 예외 클래스 이름 더 명확하게 수정 * Feat: 가이드라인 삭제 기능 추가 (#108) * refactor: id 속성 이름 Id로 수정 * feat: 서비스 레이어 가이드라인 삭제 메서드 추가 * feat: 컨트롤러 가이드라인 삭제 api 추가 * refactor: 사용하지 않는 가이드라인 예외클래스 삭제 * refactor: id 속성 코드컨벤션에 맞게 수정 * refactor: 삭제 api를 delete 요청으로 수정 * Feat: 콜백 단건조회 api 응답값에 boolean isAssignedToSelf, String seniorPhoneNumber 추가 (#104) * feat: 콜백 단건 조회 응답 요소 추가 * refactor: 더 명확한 메서드 명으로 수정 getCallback->getCallbackForSinitto * test: 시니또용 콜백 단건 조회 테스트 작성 * chore: 프론트 테스트를 더 명확히하기위해 콜백 더미 데이터에 할당된 시니어 추가 * refactor: 본인에게 할당된 콜백이 아닌것에대한 콜백 상세조회 할때는 시니어 번호 없도록 수정 * test: 테스트 통과하도록 수정 * chore: 더미데이터 개선 * Deploy: 더미데이터 실행 과정 중 initial()과 saveRefreshTokenToRedis() 메서드 실행을 별도의 트랜잭션으로 관리 (#113) deploy: 더미데이터 실행 별도의 트랜잭션에서 수행 * Deploy: 할당되는 콜백 더미 데이터에 각각 `callbackRepository.save(callback{id});` 추가 (#117) chore: 할당되는 콜백 더미 데이터에 각각 callbackRepository.save(callback?); 추가 * Feat: 시니또용 카테고리별 가이드라인 조회 api 추가 및 기존 api 삭제 (프론트 요청) (#114) * refactor: 시니또용 카테고리별 가이드라인 조회 메서드 추가 * refactor: 시니또용 카테고리별 가이드라인 조회 api 추가 * refactor: Swagger @tag 수정 * refactor: 시니또용 가이드라인 조회에서 기존 state 검증로직에 회원이 배정된 시니또인지 검증하는 로직 추가 * refactor: 서비스 레이어 회원 검증 로직 추가를 위해서 memberId 파라미터 추가 * refactor: Reformat Code * Deploy: 로컬과 개발 환경에 따라 카카오 리다이렉트 주소를 다르게 리턴하는 로직 구현 (#120) * feat: 카카오 devRedirectUri 추출 로직 추가 * feat: httpServletRequest를 통해 Referer 또는 Origin을 확인하여 다른 프론트 주소 리다이렉트 * 카카오 로그인 요청 헤더 추출 로직에서 NULL 예외처리 구현 (#122) fix: 카카오 로그인 요청 헤더 추출 로직에서 NULL 예외처리 추가 * Feat: 콜백 단건 조회 로직 개선 (#123) feat: 콜백 단건 조회 로직 개선 - 상태에 따른 검증 로직 추가 - 예외 처리 추가 - 가독성 향상 - 테스트 꼼꼼히 * 더미데이터로 로그인 기능 SSR로 구현 (#128) * feat: 저장 로직 초기세팅 * feat: DummyProperties 추가 * 비밀번호 및 오류 출력 로직 추가 * refactor: 코드 정렬 * feat: 이메일 목록에서 찾는 로직 추가, 에러 메시지 이후에도 목록 유지 * teat: findAllByEmailIn로직 테스트 코드 추가 * feat: css추가 * Feat: 시니또 회원 정보와 계좌 정보 조회 API 및 로직 분리 (#126) * Feat: 서비스 레이어 시니또 계좌정보 조회 메서드 추가 * refactor: 사용하지 않는 api와 관련 로직 삭제 * refactor: 시니어 정보 조회 api 전달 데이터 변경과 로직 수정 * refactor: 계좌정보 삭제 api 삭제 * Feat: Swagger 멘트 수정 * Refactor: SinittoRequest email 속성 삭제 및 Member 엔터티 update 메서드 수정 * Refactor: 중복 url 수정 * Refactor: GuardRequest에서 email 삭제 * Refactor: 계좌 정보가 존재하지 않으면 예외처리 대신 null을 담은 response 반환하도록 수정 * Refactor: Reformat Code * Feat: Member 정보 업데이트 테스트 추가 * Fix: 더미데이터 로그인 SSR input창 좌우여백 조정 (#130) fix: css 수정 --------- Co-authored-by: JIHO LEE <[email protected]> Co-authored-by: eunsoni <[email protected]>
#️⃣ 연관된 이슈
📝 작업 내용
스크린샷 (선택)
💬 리뷰 요구사항(선택)
⏰ 현재 버그
✏ Git Close