2021-03-08(Mon)

항목

내용

학습 날짜

2021-03-08(월)

학습 시간

11:00~24:00

학습 범위 및 주제

Admin 모듈

학습 목표

Admin PR 리뷰에 대응한다.

동료 학습 방법

eunhkim님과 페어코딩 진행

상세 학습 내용

eunhkim님과 함께 admin 모듈의 프론트엔드와 백엔드의 싱크를 맞추는 작업을 하였다.

채팅룸의 유저 권한을 변경할 경우의 동작에 대해서 경우의 수가 많다보니 예외를 처리하는데 시간이 많이 소요되었다. 이후 아래 PR 내용에 해당하는 작업을 마쳤다.

작업내용 or 이슈링크

Admin 페이지를 구현했습니다.

  • user 테이블의 position 컬럼 값이 web_owner이거나 web_admin인 경우 'service_manage'가 가능하다고 간주하기로 했습니다.

  • 'service_manage'가 가능한 유저는 우측 하단에 admin버튼이 표시되고, 이 버튼을 눌러 Admin 페이지로 진입할 수 있습니다.

Admin Index 페이지

api/admin/db 라우터 URL을 추가했습니다. 이 URL로 GET 요청을 날리면 Admin index 페이지 렌더링에 필요한 데이터가 응답됩니다. 굳이 라우터 URL을 추가한 이유는 1) 각 자원별로 요청을 날리는 것이 번거롭고, 2) admin 페이지는 특수하게 처리해도 무방하다고 판단했기 때문입니다.

조작하고자 하는 자원의 버튼을 클릭하면 action과 resource, membership, position이 각 자원의 성격에 맞게 셋팅됩니다. 덕분에 하나의 UI로 여러 자원을 컨트롤 할 수 있습니다. 은휼짱 완전 굿굿 아이디어입니다!

각 admin 버튼

  1. 유저

  • 유저 권한 변경하기

    • 유저의 권한을 web_admin, user로 변경가능합니다.

  • 유저 접속 금지하기

    • 특정 유저가 접속하지 못하도록 막고, 로그아웃시킵니다(ban)

    • 서브젝트 요구사항에 따라, ban 당한 유저를 챗룸, 길드 등에서 나가거나 탈퇴하는 동작은 구현하지 않았습니다.

  1. 채팅 채널

  • 그룹 챗 대화내역 보기

    • 렌더링할 대화가 없으면 렌더링할 대화가 없다고 표시됩니다.

  • 그룹 챗 채널 삭제하기

    • 해당 챗룸에 참여하고 있는 모든 유저를 내보낸 후 챗룸을 삭제합니다.

  1. 채팅 멤버십

  • 그룹 챗 멤버십 변경하기

    • 그룹 챗 멤버십의 position을 변경합니다.

    • 챗룸에는 반드시 1명의 owner가 존재해야하기 때문에 아래 예외처리들이 추가되었습니다.

      • 만약 특정 유저를 owner로 임명한다면, 기존의 owner를 챗룸에서 내보내며 동시에 member로 변경합니다. 이는 owner였던 유저가 여전히 owner에게 허용된 메뉴 등을 조작하는 것을 막기 위함입니다.

      • 만약 owner였던 유저를 다른 position으로 변경한다면, 또 다른 유저가 owner로 변경됩니다. 이 때 owner였던 유저가 1명이였다면, 다른 position으로 변경이 불가하다고 안내됩니다.

  • 그룹 챗 멤버 제명하기

    • owner를 제명할 경우 다른 유저를 owner로 임명하고 제명합니다.

    • 만약 챗룸에 1명 남은 멤버를 제명한 상황이었다면, 해당 유저를 내보내고 챗룸이 삭제됩니다.

  1. 길드 멤버십

  • 길드 멤버십 변경하기

    • 챗룸의 owner와 마찬가지로 길드의 master도 반드시 1명 존재해야하므로, 챗룸에서 내보내는 동작만 하지 않을 뿐 대부분 비슷하게 예외처리되었습니다.

  • 길드 멤버 제명하기

    • 챗룸의 owner와 마찬가지로 길드의 master도 반드시 1명 존재해야하므로, 챗룸에서 내보내는 동작만 하지 않을 뿐 대부분 비슷하게 예외처리되었습니다.

  1. 토너먼트 토너먼트 생성 페이지로 연결됩니다.

구현방법

admin인지 여부를 확인하는 메서드

admin 컨트롤러에는 admin이 아닌 유저가 요청 날리는 것을 막기 위해 current_user_is_admin_or_owner?으로 권한검사를 합니다. 이 때 요청의 HTTP_ADMIN 헤더를 검사에 활용합니다.

특이사항

딱히 없습니다.

학습 내용에 대한 개인적인 총평

그룹 챗과 길드 멤버십 관련해서 연관 객체 destroy 관련 처리를 하는게 상당히 번거로웠다. 권한 변경이 프론트엔드에 실시간으로 반영되도록 구현하려다보니 난이도가 좀 더 올라간 느낌! 특히 '챗룸, 길드에 owner는 하나만 있어야한다'는 제약하에 챗룸에 포함되어있는 유저들을 owner로 임명하거나 챗룸에서 kick하는 동작 구현의 예외처리가 까다로웠다. ActionCable 같은 웹소켓 관련된 메서드들은 어떻게 테스트를 작성해야하는 걸까.. 갈 길이 멀다.

그리고 챗룸에 web_owner, web_admin 같은 'super' 권한을 가진 유저들을 추가하는 과정에서 리팩토링을 많이 진행했다. 유저 권한 관련하여 cancancan 같은 gem이 왜 따로 있는지 체감할 수 있었다.

다음 학습 계획

  • 백엔드 리팩토링, docker-compose up 커맨드로 애플리케이션 작동가능한 상태 만들기

Previous2021-03-09(Tue)Next2021-03-07(Sun)

Last updated