오늘의 작업 목표는 게시판을 생성하는 기능인데 게시판을 그냥 생성하는 게 아니라 게시판 하나를 선택하면 선택한 게시판의 하위 게시판이 생기는 기능이었다. 예를 들어 EPL 게시판이 존재하면 하위 게시판으로 토트넘, 아스날 등등 팀 게시판을 생성할 수 있고 또 토트넘 팀 게시판에 손흥민, 헤리케인 같은 선수 게시판을 생성하는 것이었다. 기존에 게시판 Entity를 만들 때 위와 같은 기능을 구현하기 위해 게시판 Entity를 설계할 때 게시판 필드에 상위 게시판 아이디 값을 참조하기 위한 parentId 값을 생성했었다. 그래서 관리자 페이지에서 게시판을 생성할 때 작업 설계를 아래와 같이 했다. 1. 관리자 페이지에 현재 게시판을 리스트 시킨다. 2. 현재 존재하는 게시판 중 하위 게시판을 생성할 게시판..
어제 구현하지 못해 오늘로 미뤄진 작업인 관리자 페이지에서 사용자를 강제 탈퇴하는 기능을 구현해봤다. 사용자를 DB에서 지우기 위해서는 해당 사용자의 아이디를 칼럼으로 갖고 있는 Entity도 같이 제거해줘야 했다. 사용자가 작성한 게시글, 댓글, 대댓글이 있는데 여기서도 게시글과 댓글, 대댓글 사이에 연관관계가 맺어져 있어 지우는 순서도 중요했다. 대댓글이 댓글의 아이디를 갖고 있고 댓글이 게시글의 아이디를 갖고 있기 때문에 지우는 순서를 대댓글 -> 댓글 -> 게시글 순으로 지운 다음 사용자를 제거해야 했다. 그런데 위와 같은 과정을 거치지 않고 Entity를 지울때 연관관계에 있는 모든 것들을 한 번에 같이 지우는 방법이 JPA에 존재하지 않을까 생각해서 검색을 해봤다. 역시 특정 entity를 지..
오늘의 작업 목표는 관리자 페이지에서 모든 회원 정보(아이디, 닉네임, 프로필 사진, 작성한 게시글 수, 작성한 댓글 + 대댓글 수)를 확인하고 선택한 사용자의 등급을 변경하거나 강제 탈퇴시키는 기능 그리고 사용자의 아이디를 입력하면 해당 사용자를 찾아오는 기능을 구현하는 것이었다. 우선 작업 결과에 대해 먼저 말하면 계획한 기능을 모두 구현하지 못했다. 계획을 세우면서도 약간 무리하는 것 같은 느낌도 있었지만 이 정도는 해야 일정 안에 최소한의 관리자 기능은 만들 수 있을 것 같아 진행했었는데... 그래도 회원 정보를 불러오는 것과 선택한 유저의 등급을 변경하는 기능은 구현했다. 체크박스로 선택한 사용자의 등급을 변경하는건 이전에 마이페이지에서 선택 한 게시글이나 댓글을 지우는 갓을 구현한 적이 있었기..
오늘은 사용자가 등업 게시판에 등업 신청 게시글을 올리면 관리자가 이를 확인하고 승인해주는 기능을 구현했다. 우선 사용자의 페이지에서 등업 신청 폼이 필요했다. 리액트의 Hook Form을 이용해서 신청 폼을 만들고 신청 폼에서는 신청 등급, 신청 사유를 적고 해당 정보들과 신청자의 닉네임을 백엔드로 post 요청한다. 이때 중복 신청을 방지하기 위해 이미 신청 중에 있는 사용자는 신청 못하게 해야 했다. 그래서 신청한 유저 닉네임으로 신청 게시글 레파지토리에서 신청한 게시글이 존재하는지 (existsByApplicant_Name) 확인 후 있으면 예외처리를 해주었다. 성공적으로 POST 요청된 신청 게시글은 어드민 페이지에서 게시글 리스트들을 확인할 수 있다. 관리자가 신청자의 정보를 확인하고 승인이 ..
오후에 동료분이 노아님께 어드민에 관련해서 여러 가지 질문을 하시는 것을 보고 마침 어드민 관련해서 고민하고 있던 터라 같이 듣다가 궁금했던 것 몇 가지를 물어보면서 오해하고 있던 사실과 몰랐던 정보를 얻을 수 있었다. 우선 어드민을 맨 처음 기획할 때 네이버 카페처럼 서비스를 이용하는 사용자가 어드민의 역할(카페 매니저)을 얻을 수 있는 형태로 어드민 계정을 따로 관리하려고 하지는 않았다. 사실 이때만 해도 어드민 계정 같은걸 이용해 본적이 없어서 어드민 계정을 따로 관리해야 한다는 개념을 몰랐었다. 그래서 그냥 네이버 카페처럼 사용자가 어드민의 역할을 부여받으면 어드민 계정이 되는 줄 알 있던 나... 이 무튼 노아님이 어드민 계정은 어드민 레파지토리를 만들어서 관리해주는 게 좋다고 말해주셨다. 컨트..
오늘 5번째 스프린트 회고를 끝냄으로써 남은 기간은 디자인 주를 한 주를 제외하면 일주일밖에 남지 않았다. 남은 일주일간 관리자 페이지를 만들어야 하기 때문에 오늘 관리자 등급을 어떻게 구현할 것인지에 대해 알아봤다. 우선 내 프로젝트의 경우 관리자 or 일반 사용자 등급이 두 가지로 나뉘는 게 아니라 사용자의 여러 가지 등급이 존재하도록 초반에 기획했었다. 각 사용자의 등급에 따라 접근할 수 있는 콘텐츠가 다르게 하기 위함이었다. 그래서 프로젝트 초반에 설계했던 객체 다이어그램을 보면 User Entity와 Grade Entity가 존재하고 Grade Entity는 User를 List로 갖는 형식으로 설계를 했었던 기록이 있다. 하지만 최근에 객체의 구조가 바뀌면서 Grade가 Entity일 필요가 없..