2024년 5월 26일

작업 현황 공유

추태욱

1) middleware를 활용해서 사번을 이용한 로그인 체계 구현 -> request.session(인증방식) 사용

• 세션 사용 시 다양한 정보를(사용자 추적) 통해 얻을 수 있다.
• 세션을 통한 로그인 구현 상태 후 session/is_authenticated 결정필요
• ~22일 토요일 3시 zoom(2024년 5월 25일 완료)
  • is_authenticated로 유지하며 middleware.py 코드 정리

김의석

1) User Model(DB_table) 확장

(1) 예상 되는 User Model 확장 도식화

• 기존 User Model은 emali, First_name, Last_name만 수집 가능
• CustomUser Model을 통해 User Model을 확장
• 확장 시 PM이 수집하기 원하는 교사데이터 추가 가능

(2) 비밀번호 찾기시 인증에 필요한 교사 데이터(제안)
1) 교사 이름(full name)
2) 사용자 코드

• 별도의 개인 이메일을 받지 않기 때문에 비밀번호 찾기 시 어떤 교사 데이터를 사용하여 사용자 인증을 할 것인지에 대한 논의 필요

• 두 데이터 입력 후 비밀번호 재설정 url로 redirect 계획

(3) 온보딩-프로필 UI로 확인 된 수집 교사 데이터
1) 교사이름(full name)
2) 담당 학년 데이터
3) 담당 학년의 성별

• 반 구분 방식에 대한 논의 필요
  학년 + 반 성별 or 교사 이름(full name, 제안)

• 반 구분이 학년 + 반 성별일 때 제한사항
  - 중1 / 남,여
  - 중2,3 / 여
  - 고3 / 남,여

2) 모델링 필드 타입 수정(보류) -> 양육일지 UI 완료 시 참고하여 수정할 것, 완성된 UI에 따라 필드의 종류와 옵션을 설정할 수 있다.

• pray_time -> intfiled
• 네/아니오 -> booleanfield
• comment model -> reprot app으로 이동

3) 전체 UI 구성 변경

• 네비게이션 바의 활용
  • 원티드 스페이스 참고
• Use Flow 수정
  • 로그인 후 종합 대시보드가 아닌 반별 대시보드로 출력(2024년 5월 15일 완료)

지난목표

• 비밀번호 찾기와 프로필 작성 시 수집할 교사 데이터 추가 여부를 PM과 논의 후 결정하고 User 모델을 확장하여 수집할 데이터를 위한 필드를 추가

• 완성 양육일지 UI를 참고 한 MemberCheck와 UserCheck의 필드 옵션 수정

기타

• Get image model 삭제
  • 관련 html 정리 및 load static 사용
  • Get image model은 삭제(예정)

• 레퍼런스 UI 리서칭, 벤치마킹
  • 시프트
  • flex
  • 원티드
  • 네이버 폼 UI(개발자모드 참고)

~0525 작업

이현진(PM)

1) 서비스 기획/디자인 시 기준 환경 고민

• A안 : 모바일 친화적 인터페이스 → 단계 세분화, 모달, 바텀시트 활용 중심
• B안 : 웹 친화적 인터페이스 → 단계 최소화, 복잡도 높은 데이터 집약적 피쳐는 페이지 처리

→ B안! 웹 중심으로 진행
현재 사용자가 가장 익숙한 사용 환경
a안의 경우, 사용자가 주로 웹을 사용한다면 의미가 없음.
타부서(청년부)의 경우 비슷한 서비스를 이용중이며 모바일/웹 둘다 사용 가능하나 사용의 불편함으로 작성은 모바일 보다는 웹을 주로 이용한다고 함.
B안을 채택하고 추후 A안 구현 고려

최혜정(FE)

1) UI-스텝 사용

• 사용자 편의성
• 사용자 입장에서 단계별 임시저장이 용이
• 실시간 자동 저장 -> 서버에 많은 부하
• UI 스텝

2) FE-PM figma로 싱크소통

김의석(BE)

1) 추가 수집 교사데이터에 대한 PM 요구사항

(1) 프로필 작성 시

• 교사 이름(full name)
• 생년월일
• 담당 학년(보류, 데이터 무결성 위반)
• 담당 학년의 성별(보류, 데이터 무결성 위반)
• 이외 데이터는 필히 PM 논의 후 추가

(2) 비밀번호 찾기 시

• 교사 이름 / 생년월일로 식별

2) 사용자 코드를 이용한 로그인에 대한 피드백(FE)

(1) 처음부터 개발의 확장 범위를 차단해서 개발할 필요는 없다.

(2) 사용자 인증 절차 및 보안 강화 필요

• 내부적으로 사용자를 식별할 데이터를 선정하고 이를 통해 인증 시 보안을 강화할 것(FE)
• 사용자 코드를 이용한 로그인은 보안이 내부적으로 개발하는 서비스라도 강도가 낮다 생각.(FE)
• sns 및 회원 가입을 이용한 로그인은 사용자에게 많은 요구가 필요해서 지양(PM)
• 내부적으로 사용자 식별을 어떤 교사데이터를 가지고 통해 보안을 강화할 것인가?를 고려(BE)

(3) 사용자 코드 분실 시 프로세스가 자동화 되지 않음.

• 사용자 코드를 이용한 로그인 시 분실 프로세스는 개발팀에 직접 문의 하는 것으로 설계 되어있음.
• 추가로 본인이 사용하는 익숙한 아이디가 아닌 개발팀에서 일괄적으로 배포하는 사용자 코드는 분실의 위험이 높다고 함.

3) 양육일지 UI를 반영한 Model 필드 상세 옵션 수정

• 횟수 범위 1~7회로 지정
• 관리자 관점에서 정확한 집계를 위해

현재목표

PM

(1) 로그인 UI
(2) 양육일지 UI 완성

FE

(1) reat 환경 세팅

(2) 로그인 UI 완료 시 구현

BE

회원가입을 통한 로그인 체계 구현

(1) 추가 교사데이터 수집을 위한 User 모델 확장(5월 28일 완료)

(2) 양육일지 UI를 참고한 모델 필드 옵션 수정

(3) 사용자 인증/보안강화 및 개발확장을 위해 회원가입 로그인 /사번코드 로그인 추가 내용 파악 및 구현(~5월 31일)