Skip to content

전자결재 모듈 (FE 메인테이너)

독자: FE 메인테이너/AI. 갱신: 2026-07-18. EDS 0.10.0 exact dependency. v2는 Office participant 기반이며 인사 상품 없이 동작한다.

라우트·트리

  • /approval(랜딩) · /approval/app-view 셸 하위: 업무(받은 결재/상신함/참조·수신함/새 기안/전체 문서) · 설정(결재선 템플릿/양식/위임전결규정)
  • approvalNav.js가 메뉴와 탭의 단일 원천이다. 새 기안전체 문서는 1항목 disclosure 없이 업무 그룹의 직속 항목으로 렌더하며 기존 라우트는 유지한다.
  • 셸: src/components/approval/_shell/ (AppHeader/SideNav/AppMain + SheetAsideOrg[sheet-body-flush 적용])
  • 상세: DocumentDetailViewApprovalDocBodyMol + ApprovalLineStepperMol(결재선) + ApprovalHistoryTimelineMol(이력) + ApprovalActionSheetOrg(처리 시트)

소비 컴포저블

approvalMock.js(로컬 fallback과 UI 모델) · approvalRepo.js(Supabase 행 정규화·디렉터리·RPC) · approvalPersistence.js(adapter 선택·공유 reactive 문서·actor·mutation) · useApprovalWorkspace.js(현재 Company/Office 로드) · approvalForms.js · approvalNav.js · approvalOrg.js · approvalSettings.js.

저장소 연결

  • resolveApprovalRepo()는 test/환경변수 없음이면 local, Supabase 설정이 있으면 server repo를 반환한다.
  • 목록/받은 결재/상신/참조/상세 화면은 마운트 시 useApprovalWorkspace()로 RLS가 허용한 문서와 현재 actor를 로드한다. 일반 직원에게는 기안자 또는 결재선 참여자인 문서만 반환되며, approval_admin은 부여된 Company/Office 범위를 조회한다.
  • 기안은 saveApprovalDraft 또는 submitApprovalDraft를 await한다. 서버 상신은 create RPC 결과의 version으로 submit RPC를 연속 호출한다.
  • 상세의 승인/반려는 화면이 가진 document.versiondecideApprovalDocument에 넘긴다. 성공 결과 전체를 공유 documents ref에 upsert하므로 목록·상세가 같은 상태를 본다.
  • 버전 충돌·participant/entitlement·legacy 연결 누락은 repo에서 안전한 사용자 메시지로 바꾸어 EDS alert-error-subtle에 동적으로 노출한다.

approvalRepo.loadDirectory()get_approval_participant_directory RPC만 호출한다. 직접 workforce 테이블을 조회하지 않는다. UI 모델은 participantId/userId를 정본으로 유지하며 ApprovalLineBuilderOrgComposeView도 같은 키로 결재선을 만든다. 기존 HR consumer가 자체 브랜치에서 전환될 때까지 directory 결과에는 employeeId=participantId, assignmentId=null 호환 alias가 있다.

승인 셸은 human-capital의 WorkflowBoundaryMol/hrWorkflowPolicy를 import하지 않고 approval 자체 Office 안내를 렌더링한다. isApprovalActorparticipantId/userId를 비교한다.

EDS SSOT 정렬 (2026-07-10 — 본 세션)

전자결재는 SSOT stepper·timeline 강화(2026-06-18, Sub-project 1)의 후행 소비자(Sub-project 2)다. 캐논 정렬 실측·정정 내역:

  1. alert role 3분류(EDS-PRODUCT-CONVENTION §6, ADR ALERT-ROLE-SEMANTICS-2026-07-10): 상주 위임 배너 role="alert"note(SPA 마운트마다 assertive 과다낭독 금지), 처리 시트 정적 힌트 statusnote. 행위 후 주입되는 알림에만 alert.
  2. 결재선 반려 = stepper error 상태(SSOT §4.2 — 전자결재용으로 만들어진 어휘): stepper-indicator-error(X 아이콘)+title-error+separator-error. 반려 존재 시 model-value=0(active 해제 — 반려 문서에 "진행 중" 스텝은 모순이고, active(파랑)가 error(적)를 CSS 특이도에서 덮는다. 실측 확인).
  3. 시각 재작업(2026-07-11 오너 반려 → 정정): 세 Mol(본문·결재선·이력)이 card 직속으로 콘텐츠를 넣어 패딩 0card > .card-body 정본 구조로 정정. 결재선 수직 리듬 = StepperContent pb-6(마지막 제외 — 콘텐츠 높이가 connector 길이인 정본 기하 유지). 이력 indicator에 행위 아이콘(send/check/close/pause/undo/chat_bubble — TimelinePag 정합). 데스크톱+모바일(390px) 스크린샷·패딩·오버플로 실측. 교훈: 기능 검증만으로 통과 금지 — 카드 표면·패딩·리듬 눈검증 필수.
  4. 정본 계약문서 카피본: docs/design/EDS-PRODUCT-CONVENTION.md(byte-identical — 개정은 SSOT에서만) + eds-classes.json manifest 동기.
  5. 카드 해부 전수 종결(2026-07-11 오너 2차 반려 → 모듈 전수검사): §3의 card > .card-body 정정이 상세 Mol 3개에만 적용되고 모듈 나머지 10곳에 동일 결함(card 직속 콘텐츠·패딩 0)이 잔존 — 오너 모바일 실측(양식 선택 화면)으로 재적발. 전 라우트(11개) Playwright 전수(모바일 390+데스크톱 1440) 후 일괄 정정: FormSelectView(양식 카드)·ApprovalListOrg(결재함 3뷰 공유)·LineTemplateView·DelegationView·FormManageView·ApprovalFormFieldsOrg·ApprovalLineBuilderOrg(기안 작성 2카드)·DocumentDetailView notFound·_ComingSoonView. 목록 테이블은 콘솔 목록 캐논으로 정렬: table-sm table-truncate table-divide-y(+결재함 table-hovertable-static 제거(정적 상세 전용 어휘)·식별 셀 whitespace-nowrap·제목 font-medium — 모바일 셀 단어단위 줄바꿈 난도질 해소. 교훈 재확인: 한 결함 유형을 고치면 같은 유형을 모듈 전체에서 grep 전수한다(class="card card − card-body).

DS 소비 상태: CSS·registry 카피본 drift 0 실측(2026-07-10 byte-diff). 패키지 모델(@leysys/eds) 전환은 트리거 대기(baseline §패키지 flip).

확장 포인트·한계

  • 서버 vertical slice는 승인/반려만 노출한다. 전결·대결·의견 단독·보류·회수는 local 데모에서만 기존 버튼이 보인다.
  • 참조/수신은 이번 slice에서 JSON snapshot으로 보관하지만 서버 받은함 권한 모델에는 아직 포함하지 않았다.
  • 설정(양식·결재선 템플릿·위임)은 아직 approvalSettings.js local 상태다.
  • 서버 행 → UI 모델 변환은 approvalRepo.spec.js, v2 SQL·repo·shell 계약은 approvalCoreActorMigration.spec.js가 검증한다.
  • 업무 주체와 결재 문서의 안정 link·최종 결과 outbox는 approval_subject_links와 private outbox에 준비됐다. 범용 create_linked_approval_document 브라우저 RPC는 의도적으로 제공하지 않는다. 구매·근로계약·근태 화면은 각 도메인 전용 repository/RPC에서 업무 권한과 revision을 검증한 뒤 private 원자 helper를 호출해야 한다.
  • 원 업무 화면에서 결재 본문·의견을 직접 join하지 않는다. 원 업무에는 권한 검증된 link 요약만 표시하고, 결재 상세은 기존 전자결재 라우트와 RLS를 사용한다.
  • 다단계 결재의 중간 step 승인은 업무 상태를 바꾸지 않는다. 원 업무는 terminal approved | rejected outbox event UUID를 멱등키로 소비한 결과만 반영한다.