2023-09-20 정기 개발 회의

[not-using]

안건을 자유롭게 추가해주세요.

[not-using]

[도서 수정시 청구기호 결정문제]

청구기호 생성? 추천? 혹은 최소한 검토 기능이 필요합니다

문제 상황

1. 수정시 임의로 결정해야 하는 청구기호

도서 등록시에는 백엔드에서 DB 조회후 결정되지만
도서 수정시, 카테고리가 변경될 경우 사용자가 임의로 DB 상황을 추측해서 결정해야 하는 상황입니다.

ex. 모던 리액트 책이 현재 총류 => 웹으로 변경필요 하지만 청구기호는 어떻게 ...?
https://42library.kr/info/1017

2. 청구기호 검증 절차 추가 필요

추가적으로 유효한 청구기호인지 체크가 부족합니다.
수정 시도시 프론트/백엔드에서 표현식 및 카테고리와의 일치여부 등 일부 확인하긴 하지만 실제로 카테고리 내에 같은 책은 없는지, 없다면 가장 최신의 번호가 맞는지 검증하지는 않습니다
(ex. B10004.23.c1.v1으로 수정 시도하면 성공할 것으로 보임)

제안

1. 수정시 카테고리 선택 후 청구기호 자동생성 체크

체크시 입력값 무시, 백엔드에서 DB 조회후 결정

2. 청구기호 검증 버튼

3. 청구기호 입력시 검증 api 호출, 바로 적합여부 안내

다른 아이디어나 의견 부탁드립니다!

[nyj001012]

제안

• 청구기호 재생성 버튼을 클릭했을 때에만 청구기호 자동 생성 (수정 완료 전까지는 DB 반영 X)
• 사용자 임의 수정 불가

[not-using]

사용자가 임의로 수정할 수 있는가?

논의

• 개정판 v1 v2의 경우 사람이 판단하는게 맞다
• 알고리즘이 완벽하지 않을 경우 개발팀이 손수 수정해야 함

결정

일단 논의에 벗어나서 수정하지 않음

도서 수정시 청구기호 결정 문제

결정

api를 변경해야 함 변경 방향은 고민해봐야

[not-using]

문제가 된 책 모던리액트 https://42library.kr/info/1017

-> DB 삭제 후 재등록하면 될 듯 이 책은 @jimin52 님이 해결하시기로

[nyj001012]

V2 리팩토링

작업 사항

API 경로 수정

• /books/search의 경우, GET /books의 형식으로 Restful하게 변경

API 반환값 수정

• Users API의 반환값 중, overDueDay 같이 프론트엔드에서 직접 계산 가능하면서 백엔드에서 보유하지 않은 값은 프론트엔드에서 취급.
• roles를 숫자 대신 프론트 친화적(?)인 cadet, user, staff 등의 문자열로 반환

백엔드 스키마 정리

• 백엔드 내부 리팩토링

[scarf005]

해당 리팩토링은 일요일까지 배포 가능하게 준비해놓겠습니다.

[jimin52]

소셜로그인

다음주에 로직 및 endpoint 공유드리겠습니다

[mink97]

고생하셨습니다~