feat: 동아리 내 권한 관리 기능 구현 #133

JanooGwan · 2026-01-19T10:54:11Z

동아리 내 권한 관리 기능 구현 완료했습니다.

'부회장' 권한(ClubPositionGroup) 추가하였고,
동아리 생성 시 '회장', '부회장', '운영진', '일반회원' 각각 한 개씩(ClubPosition) 기본 생성되도록 하였습니다.

또한 동아리 내 권한을 관리하거나, 동아리 내 회원 종류(ClubPosition)를 새로 만들거나 변경할 수 있도록 하였습니다.

동아리 권한 변경 관련하여 어떤 방식으로 구현했는지는 하단에 서술하도록 하겠습니다.

ClubPositionGroup 종류

PRESIDENT ("회장")
VICE_PRESIDENT ("부회장") // 새로 추가
MANAGER ("운영진")
MEMBER ("일반회원")

인원 제한

회장: 정확히 1명
부회장: 0~1명 (초기 생성 시에는 0명)
운영진(MANAGER 그룹 전체): 0~20명
일반회원: 제한없음

권한 계층

회장 > 부회장 > 운영진 > 일반회원
상위 직급만 하위 직급 관리 가능
자기 자신 작업 불가
회장 본인 탈퇴 불가 (위임 필요)

회장/부회장 관리

회장 위임: 다른 회원에게 위임 → 기존 회장 자동으로 일반회원
부회장 변경: 새 부회장 지정 → 기존 부회장 자동으로 일반회원

ClubPosition 관리 권한

회장, 부회장만 가능
MANAGER(운영진)/MEMBER(일반회원) 에 대한 새로운 회원종류(ClubPosition) 생성 가능
이름 중복 불가
positionGroup 변경 불가

ClubPosition 수정/삭제 규칙

회장(PRESIDENT)과 부회장(VICE_PRESIDENT)은 이름을 변경할 수 없고, 삭제도 불가능함
운영진(MANAGER)과 일반회원(MEMBER)에 해당하는 ClubPosition은 그 이름을 변경할 수 있고, 삭제도 가능함. 단 삭제 시에는 특정 조건(그룹 내 인원이 없고, 삭제하고자 하는 그룹이 1개만 있는게 아닌 경우)을 만족해야함

동아리 생성

생성 시, 생성한 사용자로 회장 자동 설정
기본 4개 직책 자동 생성
부회장은 일단 null로 기본값

API 구현 범위

회원 직급 변경
회장 위임
회원 강제 탈퇴
부원 명부 조회 (전체 + 직급별)
ClubPosition CRUD

정렬

회장 → 부회장 → 운영진 → 일반회원
같은 그룹 내 이름순

…ithub.com/JanooGwan/KONECT_BACK_END into feat/CAM-175-update-club-member-authority

dh2906

고생하셨습니다.
웬만해서는 하나의 API당 하나의 PR로 작업을 올려주세요! 작업의 볼륨이 커진다면 더 쪼개주시면 좋고요.
그리고 개발한 API는 테스트 후 PR 올리시는 지 궁금합니다!

dh2906 · 2026-01-19T12:00:59Z

src/main/java/gg/agit/konect/domain/club/dto/ClubPositionsResponse.java

+        @Schema(description = "우선순위 (낮을수록 높은 직급)", example = "0", requiredMode = REQUIRED)
+        Integer priority,


우선순위를 넣은 이유가 무엇인가요??

우선순위를 이용해서 직급 간 관리를 수행할 수 있도록 하려고 했습니다
(ex. 회장은 운영진보다 우선순위가 높음 -> 회장은 운영진 관리 가능, 그 반대는 못함)
하지만 권한 종류가 4개(회장, 부회장, 운영진, 일반)로 많지 않기 때문에,
priority 필드를 지우고, repository에서 다음과 같이 수정하려고 하고 있습니다.

@Query(""" SELECT cp FROM ClubPosition cp WHERE cp.club.id = :clubId ORDER BY CASE cp.clubPositionGroup WHEN gg.agit.konect.domain.club.enums.ClubPositionGroup.PRESIDENT THEN 0 WHEN gg.agit.konect.domain.club.enums.ClubPositionGroup.VICE_PRESIDENT THEN 1 WHEN gg.agit.konect.domain.club.enums.ClubPositionGroup.MANAGER THEN 2 WHEN gg.agit.konect.domain.club.enums.ClubPositionGroup.MEMBER THEN 3 END ASC, cp.name ASC """) List<ClubPosition> findAllByClubId(@Param("clubId") Integer clubId);

dh2906 · 2026-01-19T12:01:39Z

src/main/java/gg/agit/konect/domain/club/dto/ClubPositionsResponse.java

+        @Schema(description = "이름 변경 가능 여부", example = "false", requiredMode = REQUIRED)
+        Boolean canRename,
+
+        @Schema(description = "삭제 가능 여부", example = "false", requiredMode = REQUIRED)
+        Boolean canDelete


이런건 너무 과한 것 같아 보입니다!

필드로 꼭 추가할 필요는 없다는 말씀이신가요??
다시 보니 굳이인가 싶기도 하긴 합니다
필드 없이 비즈니스 로직 만으로도 충분할 것 같습니다

dh2906 · 2026-01-19T12:04:31Z

src/main/java/gg/agit/konect/domain/club/controller/ClubApi.java

+    @PatchMapping("/{clubId}/positions/{positionId}")
+    ResponseEntity<ClubPositionsResponse> updateClubPositionName(
+        @PathVariable(name = "clubId") Integer clubId,
+        @PathVariable(name = "positionId") Integer positionId,
+        @Valid @RequestBody ClubPositionUpdateRequest request,
+        @UserId Integer userId
+    );


PATCH로 지정한 이유가 따로 있나요?

positionId를 요청 바디에서 받는 형태는 어떻게 생각하시나요? 다른 API에서도 마찬가지 입니당

ClubPosition의 name만 변경하게 되는 것이라 PATCH 로 일부 필드만 변경되게끔 하는게 적절하다고 생각했습니다.

~~그렇게 하는게 더 좋을 것 같습니다. uri 길이도 짧아지면서 깔끔해질 것 같습니다~~
(수정) 좀더 생각해봤는데 지금처럼 두는게 좋다고 생각합니다.
그 이유는 ClubPosition 내에서 변경 가능한 필드는 name 밖에 없어서,
여러 필드를 수정하지 않고 name 필드만 수정하기 때문에 지금처럼 uri 설계하고 매개변수에 positionId 를 두는 것이 적절하다고 생각했습니다.

dh2906 · 2026-01-19T12:05:26Z

src/main/java/gg/agit/konect/domain/club/controller/ClubApi.java

+        동아리 회장 또는 매니저만 직책을 삭제할 수 있습니다.
+        PRESIDENT와 VICE_PRESIDENT 직책은 삭제할 수 없습니다.
+        해당 직책을 사용 중인 회원이 없어야 하며, 해당 그룹에 최소 2개의 직책이 있어야 삭제 가능합니다.


직책 삭제의 경우 회장, 부회장만 가능하도록 하는 것이 좋아 보여요!

알겠습니다 매니저는 직책 삭제 못하도록 하겠습니다!

dh2906 · 2026-01-19T12:07:09Z

src/main/java/gg/agit/konect/domain/club/controller/ClubApi.java

+        동아리 회장 또는 매니저만 회원의 직책을 변경할 수 있습니다.
+        자기 자신의 직책은 변경할 수 없으며, 상위 직급만 하위 직급의 회원을 관리할 수 있습니다.


어차피 회장, 부회장은 직급과 이름이 고정되어 있기에 여기도 마찬가지로 회장, 부회장만 변경 가능하도록 해야할 것 같습니당.

확인했습니다

dh2906 · 2026-01-19T13:08:04Z

src/main/java/gg/agit/konect/domain/club/controller/ClubApi.java

+    @Operation(summary = "동아리 회원을 강제 탈퇴시킨다.", description = """
+        동아리 회장 또는 매니저만 회원을 강제 탈퇴시킬 수 있습니다.
+        자기 자신은 강제 탈퇴시킬 수 없으며, 회장은 강제 탈퇴시킬 수 없습니다.
+        상위 직급만 하위 직급의 회원을 강제 탈퇴시킬 수 있습니다.


굳이 상위, 하위 직급을 나눈다면 발생할 수 있는 케이스가 복잡해지니 일반 멤버에 대해서만 탈퇴를 시키는건 어떻게 생각하시나요?

만약 임원진이나 부회장을 탈퇴시켜야 한다면 회장의 권한으로 직급을 일반 멤버로 내린 뒤에 탈퇴하면 되니까 더 간단해질 것으로 보여요

알겠습니다
말씀해주신 대로 탈퇴는 일반 멤버에 대해서만 가능하도록 하겠습니다

dh2906 · 2026-01-19T13:18:15Z

src/main/java/gg/agit/konect/domain/club/service/ClubMemberManagementService.java

+        if (targetUserId.equals(requesterId)) {
+            throw CustomException.of(CANNOT_CHANGE_OWN_POSITION);
+        }
+
+        ClubMember requester = clubMemberRepository.findByClubIdAndUserId(clubId, requesterId)
+            .orElseThrow(() -> CustomException.of(NOT_FOUND_CLUB_MEMBER));
+
+        ClubMember target = clubMemberRepository.findByClubIdAndUserId(clubId, targetUserId)
+            .orElseThrow(() -> CustomException.of(NOT_FOUND_CLUB_MEMBER));
+
+        if (!requester.canManage(target)) {
+            throw CustomException.of(CANNOT_MANAGE_HIGHER_POSITION);
+        }


if문은 따로 private 메소드로 분리하는건 어떠세요?

repository에서 조회한 엔티티도 검증하는 로직을 getBy~~~처럼 인터페이스의 default 메소드를 만들어 활용하는건 어떠신가요?

아 이거 전에도 말씀해 주셨던거 같은데 수정하도록 하겠습니다..

dh2906 · 2026-01-19T13:23:12Z

src/main/java/gg/agit/konect/domain/club/service/ClubService.java

+            ClubPosition.builder()
+                .name("회장")
+                .clubPositionGroup(PRESIDENT)
+                .club(savedClub)
+                .build(),
+            ClubPosition.builder()
+                .name("부회장")
+                .clubPositionGroup(VICE_PRESIDENT)
+                .club(savedClub)
+                .build(),
+            ClubPosition.builder()
+                .name("운영진")
+                .clubPositionGroup(MANAGER)
+                .club(savedClub)
+                .build(),
+            ClubPosition.builder()
+                .name("일반회원")
+                .clubPositionGroup(MEMBER)
+                .club(savedClub)
+                .build()


for-each? 였는지 기억은 잘 안나지만 enum에 있는 내용을 반복할 수 있는 방법이 있는 것으로 알고 있습니다!

아 그런가요? 조사해보고 수정하도록 하겠습니다!

JanooGwan and others added 8 commits January 18, 2026 19:31

새 브랜치 커밋 테스트

5ad96f3

feat: 동아리 권한 관리 기능 구현

1e95ca4

feat: 동아리 생성 기능 구현(기본 권한 그룹 생성)

cd44c7f

chore: 코드 정렬

4096130

Merge branch 'main' into feat/CAM-175-update-club-member-authority

648d69c

feat: 직급 내 회원 가나다 순으로 정렬 기능 구현

da78a29

Merge branch 'feat/CAM-175-update-club-member-authority' of https://g…

a894236

…ithub.com/JanooGwan/KONECT_BACK_END into feat/CAM-175-update-club-member-authority

fix: 불필요한 중복 메소드 제거

a01dc72

JanooGwan force-pushed the feat/CAM-175-update-club-member-authority branch from a7ad764 to a01dc72 Compare January 19, 2026 12:14

JanooGwan and others added 2 commits January 19, 2026 21:25

Merge branch 'main' into feat/CAM-175-update-club-member-authority

fd928a4

refactor: 중복 코드 제거, ClubPositionRepository의 정렬 방식 수정, 코드 정렬

641ee0b

dh2906 requested changes Jan 19, 2026

View reviewed changes

refactor: 동아리 내 직책&권한 변경 관련 수정

1cc9a42

JanooGwan changed the title ~~동아리 내 권한 관리 기능 구현~~ feat: 동아리 내 권한 관리 기능 구현 Jan 20, 2026

feat: 권한 관련 검토 및 수정

6729d47

		@Schema(description = "우선순위 (낮을수록 높은 직급)", example = "0", requiredMode = REQUIRED)
		Integer priority,

		동아리 회장 또는 매니저만 회원의 직책을 변경할 수 있습니다.
		자기 자신의 직책은 변경할 수 없으며, 상위 직급만 하위 직급의 회원을 관리할 수 있습니다.

feat: 동아리 내 권한 관리 기능 구현 #133

Are you sure you want to change the base?

feat: 동아리 내 권한 관리 기능 구현 #133

Uh oh!

Conversation

JanooGwan commented Jan 19, 2026

Uh oh!

dh2906 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JanooGwan Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dh2906 left a comment •

edited

Loading

JanooGwan Jan 20, 2026 •

edited

Loading