전결규정 개편 설계 (전결규정 메뉴)

프로세스포탈의 전결규정 메뉴를 다음 세 축으로 개편한다. 이 문서는 구현 전에 합의한 결정을 기록하는 정본이며, 세부 규칙은 구현과 함께 여기서 갱신한다.

1. 도메인 규칙 (확정)

• 전결규정 = 결재선. 특정 업무의 결재 흐름을 뜻한다. 원칙적으로 업무(프로세스노드)와 매핑된다.
• 미매핑 수용 + 워닝. 프로세스노드가 아직 확정되지 않았지만 결재가 실재하는 경우를 수용한다 (targets가 비어 있는 규정). 다만 워닝으로 표시해 결국 노드와 매핑하도록 유도한다.
• 결재 4속성. 기안(draft)·합의(consult)·결재(approve)·통보(notify)의 조합으로 결정되며, 기안은 정확히 1개만 존재한다.
• 부착 지점. 결재가 붙는 의사결정 엔티티는 L5 워크플로우 안의 의사결정(다이아몬드, L6와 같은 레벨)이다. workflow_steps.kind = "gateway" 이면서 approvalPolicyId가 채워진 단계 = "결재 부착 엔티티".
• 매핑 cardinality (N:1). 프로세스 노드 ↔ 전결규정은 N:1 — 같은 내용의 결재선을 여러 업무(노드)가 함께 쓴다. 그래서 한 규정에 의사결정 노드가 여럿 매달릴 수 있고, 노드를 추가해도 다른 노드의 연결은 유지된다(approvalPolicyTargets·workflow_steps.approvalPolicyId 둘 다 다대일을 이미 지원).
• 권한. 전결규정을 수정할 수 있는 사람은 해당(단일) L5 노드의 수정권한자(RACI R 담당자) 또는 관리자다. 다중 L5 대상·AD_HOC·미매핑(대상 없음)은 관리자만 수정할 수 있다.

2. 초기화면 (레벨별 개수)

업무프로세스 화면과 같은 결로, 등록된 전결규정을 L1·L2·L3·L4 단위로 보여준다. 동시에 보여주면 중복되므로 레벨을 선택하고, 선택한 레벨 기준으로 "몇 개의 노드에 몇 개의 전결규정이 등록되어 있는지"를 보여준다.

• 레벨 탭(L1~L4) 선택 → 그 레벨 노드 목록 + 노드별 전결규정 K건 · 결재 부착 엔티티 N개 + 상단 집계줄.
• 롤업: L6/게이트웨이를 parentId 체인으로 L1~L4 조상까지 역산한다.

3. 계약 (API/UI)

3.1 approval.list

기존 규정 목록에 규정별 canEdit: boolean(서버가 현재 사용자 기준으로 계산)을 더한다.

3.2 approval.overview

• 입력: { level: "L1" | "L2" | "L3" | "L4" }
• 반환:

  {
    level: "L1" | "L2" | "L3" | "L4";
    totals: {
      nodeCount: number;          // 해당 레벨 노드 수
      mappedNodeCount: number;    // 전결규정이 1건 이상 등록된 노드 수
      policyCount: number;        // 해당 레벨 하위에 등록된 고유 활성 전결규정 수
      decisionEntityCount: number;// 해당 레벨 하위 결재 부착 엔티티(gateway+policy) 수
      unmappedPolicyCount: number;// 노드에 매핑되지 않은 활성 전결규정 수(워닝)
    };
    nodes: Array<{ id: number; code: string; name: string; nameEn: string | null; policyCount: number; decisionEntityCount: number }>;
  }

• "등록된 전결규정"(policyCount)은 활성 규정의 활성 대상(target) 기준. L5 대상은 그 L5, L6 대상은 그 L6의 부모 L5로 보고 조상 레벨까지 롤업한다.

3.3 권한 검사 (save / deactivate)

• save(신규): 입력 targets가 단일 L5로 수렴하면 그 L5 수정권한자 허용.
• save(수정): 기존 규정의 targets와 입력 targets 모두 단일 L5 수렴·수정권한을 확인해 재지정 권한상승을 막는다.
• deactivate: 기존 규정의 targets 기준.
• 수렴하지 않으면(다중 L5·AD_HOC·미매핑) 관리자만. 위반 시 FORBIDDEN.

4. 마이그레이션

스키마 변경 없음. approval_policy_targets가 0건인 규정으로 "미매핑"을 표현한다(zod min(0)).

5. 레이아웃 (프로세스 화면과 다름)

전결규정 메뉴는 프로세스 화면과 달리 목록 중심으로 둔다.

• 요약 탭(초기화면): L1~L4 레벨별 개수(§2).
• 규정 목록 탭: 제목/설명 헤더 없이 헤더 있는 표로 나열한다(수백 건 이상을 다룰 수 있다).
  • 컬럼: 코드 · 결재선명 · 버전 · 상태 · 적용 대상(매핑된 노드 수 / 미매핑 배지). 코드·결재선명·버전·적용 대상은 헤더 클릭 정렬(PortalDataTable = AntD Table sorter).
  • 툴바에서 필터: 코드·이름 검색, 상태(전체/활성/비활성), 매핑(전체/매핑됨/미매핑). 상단에 “신규 추가” 버튼.
  • 인라인 편집기·미리보기는 두지 않는다(행을 누르면 상세 팝업).
• 등록·수정은 레이어팝업(ApprovalPolicyFormDialog)에서 한다. 목록 행을 누르면 같은 팝업이 수정 모드로 열린다.
  • 팝업 흐름: ① 결재선을 매핑할 L5 선택 → ② 그 L5 워크플로우의 의사결정(다이아몬드) 노드 선택 (approval.decisionNodes) → ③ 결재선 구성(기안·합의·결재·통보).
  • 저장하면 규정을 만들고 고른 의사결정 노드(들)에 매단다(workflow_steps.approvalPolicyId, 노드 ↔ 규정 N:1).
  • "적용 대상"은 노드 목록이다 — 여러 의사결정 노드를 추가/제거할 수 있다(같은 결재선을 여러 업무가 공유).
  • 규정의 대상(targets)은 매핑된 노드들의 L5에서 파생한다(고유 L5마다 하나).

5.1 권한

• 등록/수정은 관리자이거나 해당 L5의 RACI R 담당자여야 한다(§1·§3.3).
• L5 선택 목록은 관리자면 전체, 아니면 수정권한이 있는 L5만 보여준다(approval.permissions).
• 목록 행을 눌러도 수정권한이 없으면 팝업을 열지 않고 안내한다.

5.2 관리자 콘솔 진입

같은 화면을 관리자 콘솔에도 둔다 — 좌측 "전결규정 관리"(/admin/approval, AdminWorkspace). 관리자는 initialView="manage" 로 규정 목록부터 시작해 곧바로 관리할 수 있다(사용자 포털은 요약부터).

5.3 두 개의 등록 입구 (선후관계)

원칙은 전결규정을 먼저 등록하고 의사결정 노드에 매핑하는 것이다(§1). 거꾸로, 프로세스(흐름맵)에서 작업하다 이어서 전결규정을 만들고 싶을 때를 위해 의사결정 노드에서 등록창을 바로 연다:

• L5 흐름맵의 의사결정(다이아몬드) 상세에 "전결규정 등록" 버튼을 둔다 (WorkflowGatewayEntityDetail, data-testid="gateway-create-approval-policy").
• 누르면 같은 레이어팝업(ApprovalPolicyFormDialog)이 이 L5와 이 노드를 미리 채운 채 열리고, 저장하면 규정이 만들어져 이 노드에 매핑된다(등록 즉시 연결).
• 두 입구는 같은 팝업·같은 저장 경로를 쓴다(중복 구현 없음).

5.4 상세(조회)와 수정

목록에서 결재선명을 누르면 편집이 아니라 상세(조회) 가 열린다 — 기안·합의·결재·통보가 누구인지, 어느 L5·의사결정 노드에 붙는지를 읽기 전용으로 보여준다(mode="view", data-testid="approval-policy-detail").

• 권한자(관리자 또는 해당 L5 R 담당자)에게만 상세 안에 "수정" 버튼이 보이고, 누르면 편집 모드로 전환한다.
• 권한이 없으면 조회 모드로만 열린다(수정 버튼 없음). 저장·비활성화는 서버가 다시 검증한다.
• 신규 등록은 상세를 거치지 않고 곧바로 편집 모드로 연다.