feat(sn): CS 기준 UI 통일 및 지도 팝업 표준화
This commit is contained in:
@@ -854,3 +854,83 @@
|
||||
- 공통 지도 선택기가 선택된 피처의 실제 OpenLayers 레이어 스타일 함수를 우선 사용하도록 변경했다.
|
||||
- 점 시설은 선택 원형 강조를 먼저 그리고 원래 아이콘을 위에 다시 그려, 선택 중에도 대상 맨홀을 식별할 수 있게 했다.
|
||||
- 선형 시설의 기존 선택 강조 순서는 유지했으며 API·DB·백엔드 동작은 변경하지 않았다.
|
||||
|
||||
## 41. 2026-08-12 CS 기준 조사·처리분구 화면 UI 통일
|
||||
|
||||
### 추적 근거
|
||||
|
||||
- 요구사항정의서 `3. (기능)요구사항정의 및 추적표`의 `SFR-010-004`~`SFR-010-007`을 다시 확인했다.
|
||||
- 화면설계서의 조사관리 화면 `SN_MN040101`~`SN_MN040110`(슬라이드 37, 41~49)을 대조했다.
|
||||
- 이번 변경은 조회·등록·수정·상세 기능과 API 계약을 유지한 UI 설계 보완이다.
|
||||
|
||||
### 변경 내용
|
||||
|
||||
- 메뉴명이 `관리`로 끝나는 목록 카드 제목은 `관리`를 제외하는 규칙을 적용했다.
|
||||
- `조사관리` → `조사 목록`
|
||||
- `처리분구관리` → `처리분구 목록`
|
||||
- 목록의 총 건수 문구와 열 정렬 UI·정렬 동작을 제거해 CS 목록 화면 기준에 맞췄다.
|
||||
- 검색조건은 공통 `Label`, `Input`, `Select`, `Button`으로 바꾸고 `조회`, `초기화` 순서와 간격을 공통 규칙으로 통일했다.
|
||||
- 조사사업·처리분구 목록은 공통 `StandardDataTable`을 사용하며 페이지당 10건, 자연 높이, 윈도우 세로 스크롤을 적용했다. 가로 폭이 충분하지 않은 표만 내부 가로 스크롤을 표시한다.
|
||||
- 조사 상세현황의 종합집계표는 내부 세로 스크롤을 제거하고 서버 제공 순서를 유지했다.
|
||||
- 조사사업 등록·상세/수정은 공통 `StandardFormSection`, `StandardFormField`를 사용해 사업차수·사업년도·정밀조사 연장과 시도·시군구·사업명을 각각 한 행 3개 항목으로 배치했다.
|
||||
- 처리분구는 별도 등록·상세 화면이 없는 기존 계약을 유지해 목록 안의 추가·수정·삭제·저장 방식은 보존하고 표와 버튼 UI만 통일했다.
|
||||
- 백엔드 API, 요청·응답 DTO, DB 구조는 변경하지 않았다.
|
||||
|
||||
### 공통 컴포넌트와 화면 전용 처리
|
||||
|
||||
- 그대로 사용: 공통 `Button`, `Input`, `Label`, `Select`, `StandardDataTable`.
|
||||
- 공통 래퍼 추가: 업무 비종속 `StandardFormSection`, `StandardFormField`. `sn` 접두어와 조사 업무 로직은 포함하지 않아 다른 앱에서도 재사용할 수 있다.
|
||||
- 화면 전용 유지: 조사 상세현황의 합계 행·결함 건수 링크, 처리분구 인라인 편집·변경 상태 표현, 조사 결과 업로드 흐름.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- `node node_modules/typescript/bin/tsc --noEmit --pretty false --ignoreDeprecations 5.0`을 `apps/sn`에서 실행해 오류 없이 통과했다.
|
||||
- 로그인 브라우저에서 `/oper/exmn/register`와 `/oper/trtdst`를 직접 확인했다.
|
||||
- `조사 목록`, `처리분구 목록` 제목, 조회·초기화 버튼, 정렬 버튼 미표시, 표 헤더 가운데 정렬, 페이지당 10건, 내부 세로 스크롤 미표시를 확인했다.
|
||||
- 조사사업 행 선택 후 상세현황 표시, 조사사업 등록의 3열 2행 폼, 처리분구 행 선택 후 인라인 수정 입력 전환을 확인했다.
|
||||
- 사용자가 실행 중인 개발 서버를 보호하기 위해 Next 빌드는 수행하지 않았다.
|
||||
|
||||
## 42. 2026-08-12 조사 상세 그리드·WindowPopup UI 및 순번 규칙 통일
|
||||
|
||||
### 추적 근거
|
||||
|
||||
- 요구사항정의서 `3. (기능)요구사항정의 및 추적표`의 `SFR-010-004`~`SFR-010-007`을 직접 재확인했다.
|
||||
- 화면설계서 슬라이드 37, 41~49의 `SN_MN040101`~`SN_MN040110` 조사사업 목록·등록·상세·결과등록 화면을 대조했다.
|
||||
- 기존 기능·API 계약을 유지하면서 사용자가 지정한 CS UI 기준을 팝업까지 확장한 설계 보완이다.
|
||||
|
||||
### 변경 내용
|
||||
|
||||
- 조사 목록, 관로·맨홀 상세 집계 및 처리분구 목록의 `NO` 헤더를 `순번`으로 통일하고 전체 건수에서 시작하는 내림차순 순번을 적용했다.
|
||||
- 조사 상세현황 그리드를 CS 기본 표의 파란 헤더·흰 글씨·가운데 정렬로 바꾸고 내부의 `관로조사 종합집계표`, `맨홀조사 종합집계표` 제목을 삭제했다.
|
||||
- 업무에 종속되지 않는 `StandardPopupLayout`과 공통 순번 계산 함수 `getStandardRowNumber`를 `business_components`에 추가했다.
|
||||
- 조사사업 등록·수정, 조사 결과 업로드, 조사 상세보기, 관로 조사보고서 WindowPopup을 `StandardPopupLayout`과 공통 `Button`, `Input`, `Select`, `StandardFormSection`, `StandardFormField` 기준으로 통일했다.
|
||||
- 조사 결과 업로드의 파일 표와 조사 상세보기의 복합 그리드·본단위구간 그리드도 CS 기본 표 헤더 색상과 가운데 정렬을 적용했다.
|
||||
- 기존 녹색 팝업 버튼과 화면 전용 파란 헤더를 제거했으며 정렬 UI와 정렬 동작은 추가하지 않았다.
|
||||
- 조사사업 저장·양식 다운로드, 결과 파일 선택·검토·저장, 결함 필터·다운로드, 관로 보고서 PDF 조회 기능은 보존했다.
|
||||
- 백엔드 API, 요청·응답 DTO와 DB 구조는 변경하지 않았다.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- 로그인 브라우저에서 `/oper/exmn/register`를 조회해 목록 `순번`이 `5`부터 `1`까지 표시되는 것을 확인했다.
|
||||
- 첫 사업을 선택해 조사 상세현황의 두 처리분구가 `2`, `1`로 표시되고, 두 종합집계표 제목이 없으며 표 헤더가 CS 기본 스타일로 표시되는 것을 확인했다.
|
||||
- `/popup/exmnBusinessRegister`, `/popup/exmnResultRegister`, `/popup/exmnSurveyDetail`, `/popup/exmnPipeReport`를 직접 열어 카드형 헤더·버튼·폼·표·PDF 상태 영역을 확인했다. 테스트용 임의 ID로 연 화면의 API `ERROR` 표시는 예상된 조회 결과이며 UI 렌더링 검증에만 사용했다.
|
||||
- TypeScript 전체 검사는 이번 변경 파일의 오류가 없음을 확인했으나, 작업 범위 밖 지도·공통 메뉴와 기존 `ExmnSurveyResultSection`, `exmn-business-api`, `ObsltPplFormPage` 오류 때문에 전체 명령은 실패했다.
|
||||
- 사용자가 실행 중인 개발 서버를 보호하기 위해 Next 빌드는 수행하지 않았다.
|
||||
|
||||
## 43. 2026-08-12 조사사업 등록 팝업 버튼·처리분구 영역 재정렬
|
||||
|
||||
- 사용자 확인에 따라 처리분구 선택 UI의 그리드 전환은 보류하고 기존 3열 체크박스 카드와 검색·일괄선택 기능을 유지했다.
|
||||
- 조사사업 등록 상단 버튼을 준설 등록과 같은 공통 기본 규격(높이 32px, 글자 13px)으로 변경하고 취소 버튼을 추가했다.
|
||||
- 처리분구 영역은 CS 카드 헤더 규칙을 적용하고 타이틀, 검색 입력, 선택 버튼, 선택 건수와 빈 상태 안내를 공통 13px 글꼴·색상·간격으로 통일했다.
|
||||
- 동일한 이름의 시군구가 여러 시도에 존재해도 선택 시도의 코드 앞자리 안에서 일치하는 항목을 찾도록 상세값 복원 로직을 보완했다.
|
||||
- 로그인 브라우저에서 `/popup/exmnBusinessRegister`를 직접 열어 상단 버튼 높이·글자 크기, 처리분구 타이틀·검색 입력·선택 건수·빈 상태 안내의 계산 스타일을 확인했다. 인천광역시의 고유 시군구와 동명 시군구를 차례로 선택해 시군구 선택값 유지도 확인했다.
|
||||
- 대상 파일은 Prettier와 `git diff --check`를 통과했다. 앱 전체 TypeScript 검사는 이번 파일 외 지도·API·공통 메뉴 등 기존 오류가 남아 있어 실패했으며, Next 빌드는 실행 중인 개발 서버 보호를 위해 수행하지 않았다.
|
||||
|
||||
## 44. 2026-08-12 버튼 색상·문구·순서 및 팝업 카드 간격 통일
|
||||
|
||||
- 주요 실행 동작인 조회·등록·저장·수정·다운로드는 파란색, 초기화·취소·닫기·상세보기·지도보기는 흰색, 삭제는 빨간색으로 통일했다.
|
||||
- 조사 목록은 `사업등록 → 결과등록 → 수정`, 처리분구 목록은 `추가 → 수정 → 저장 → 삭제` 순서로 정리했다. 처리분구의 삭제대기 상태는 동작 의미에 맞춰 흰색 `삭제취소`로 바뀐다.
|
||||
- 조사사업 등록·수정 팝업은 `양식다운로드 → 조사보고서 양식다운로드 → 저장/수정 → 취소`, 결과 업로드는 `저장 → 취소`, 조사 상세는 `엑셀다운로드 → 닫기` 순서를 적용했다.
|
||||
- Excel 데이터 내보내기는 `엑셀다운로드`, 입력 템플릿은 `양식다운로드`, 일반 첨부파일은 `다운로드`로 구분했다.
|
||||
- `StandardPopupLayout` 본문을 margin 기반 `space-y` 대신 `flex`와 `gap: 1.2rem`으로 변경했다. 자식 카드의 `!m-0` 때문에 간격이 0으로 덮이던 문제를 공통 레이아웃에서 해결했다.
|
||||
- 브라우저에서 조사사업 등록·수정의 `사업 정보`와 `사업대상 처리분구` 카드 사이 실제 간격이 모두 12px인 것을 확인했다.
|
||||
|
||||
@@ -277,3 +277,59 @@
|
||||
|
||||
- 요구사항정의서 `SFR-010-012`, `SFR-010-013`, 화면설계서 51~52번 슬라이드와 화면 ID `SN_MN040201`을 확인했다.
|
||||
- 상세 UI를 수정 기반으로 재사용하고 사진·위치 편집을 추가한 부분은 사용자 지시에 따른 설계 보완이다.
|
||||
|
||||
## 15. 2026-08-12 수정 등록방식·사진 0건 정합성 보완
|
||||
|
||||
- 수정 화면에도 등록 화면과 동일한 `사진 기반 등록`, `사진 없이 직접 등록` 선택을 추가했다.
|
||||
- 사진 기반 등록에서는 유지 사진과 신규 사진을 합쳐 0장이면 저장을 중단하고, 사진 추가 또는 직접 등록 전환을 안내한다.
|
||||
- 직접 등록으로 전환하면 기존·신규 사진을 모두 삭제 대상으로 바꾸고 현재 위치를 지도 지정 위치로 유지한다. 사용자는 필요하면 `위치 수정`으로 좌표와 최근접 관로를 다시 확인할 수 있다.
|
||||
- 부모 목록과 같은 `InputDatePicker`를 유지하되 팝업 전용 글자 규칙으로 18px까지 커지던 날짜 입력을 부모 화면과 같은 12.5px로 맞췄다. 달력 팝오버 자체 크기는 부모와 동일한 공통 컴포넌트 규격을 유지한다.
|
||||
- 추적 근거는 `SFR-010-012`, `SFR-010-013`, 화면설계서 51~56번 슬라이드와 화면 ID `SN_MN040201~203`이다. 수정 화면의 등록방식 전환은 사용자의 오류 재현과 지시에 따른 설계 보완이다.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- 사진 0건·사진 기반 수정 화면에서 두 등록방식 버튼, 사진 필수 안내, 파일 업로드 영역을 확인했다.
|
||||
- 사진 없이 직접 등록 상태에서 파일 업로드가 숨겨지고 `지도 지정`, 사진 0/5장, 위치 확인 안내가 표시되는 것을 확인했다.
|
||||
- 날짜 입력의 브라우저 계산값은 부모 목록과 같은 `font-size: 12.5px`, `width: 155px`, `height: 32px`이다.
|
||||
- 전체 TypeScript 검사에서 이번 변경 파일 오류는 0건이며, 검사는 기존 조사·침수·GIS·노후관로 파일 오류로 종료된다.
|
||||
|
||||
## 16. 2026-08-12 수정 팝업·목록 UI 후속 통일
|
||||
|
||||
- 수정 팝업 상단의 관로번호를 제거하고 `관로 정보` 카드 헤더 우측으로 이동했다.
|
||||
- 준설일자와 자동매핑을 한 행의 두 항목으로 배치해 관로정보 표를 한 행 줄였다.
|
||||
- 부모 목록과 같은 공통 `InputDatePicker`를 그대로 사용하고, 날짜 선택기 래퍼를 입력 폭 안으로 제한해 달력 버튼이 셀 우측으로 분리되지 않도록 했다.
|
||||
- 수정 팝업 상단 버튼은 `저장`, `취소` 순서로 정렬하고 준설 사진 카드의 기존 안내 문구를 제거했다.
|
||||
- 지자체별·관경별·경과년도별 결과 카드 타이틀을 모두 `준설 목록`으로 통일했다.
|
||||
- CS 설문관리 검색 폼의 `gap-2` 규칙을 준설관리 검색조건에도 적용해 조회·초기화 버튼 간격을 10px에서 5px로 맞췄다.
|
||||
- 준설관리는 선행 검증 화면으로만 사용하고, 버튼·입력·달력·선택·목록·페이징 규칙은 하수관망도를 제외한 SN 전체 화면과 WR·DM·FO에서도 재사용할 수 있는 공통 기준으로 관리한다. 업무 고유 사진·관로 매핑 흐름만 준설 화면에 남긴다.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- 수정 팝업에서 상단 버튼 순서, 관로번호 위치, 안내 문구 제거와 5행 관로정보 표를 확인했다.
|
||||
- 날짜 입력은 공통 달력 팝오버가 227×247px로 열리고 달력 버튼이 입력 영역 안에 배치되는 것을 확인했다.
|
||||
- 목록의 관경별·경과년도별 조회구분에서 결과 타이틀이 모두 `준설 목록`으로 유지되는 것을 확인했다.
|
||||
- 조회 버튼 우측 312px, 초기화 버튼 좌측 317px로 계산되어 두 버튼의 실제 간격이 CS와 같은 5px임을 확인했다.
|
||||
|
||||
## 17. 2026-08-12 목록 조회 로딩 UI 통일
|
||||
|
||||
- 준설 목록만 `StandardDataTable` 내부의 `조회 중입니다.` 문구를 표시하던 차이를 제거했다.
|
||||
- 조사관리·처리분구관리·노후 하수관로 정비사업과 같은 공통 `LoadingOverlay`를 준설관리 조회·삭제 처리에도 적용했다.
|
||||
- 조회 중에는 기존 그리드를 유지한 채 화면 전체 로딩 애니메이션으로 사용자 입력을 차단하며, 그리드 내부 조회 문구는 사용하지 않는다.
|
||||
- API 요청·응답, 검색조건, 페이징과 목록 데이터 처리 방식은 변경하지 않았다.
|
||||
- 추적 기준은 요구사항 `SFR-010-012`, 화면설계서 51~56번 슬라이드와 화면 ID `SN_MN040201~203`이며 로딩 표현 통일은 사용자 지시에 따른 UI 설계 보완이다.
|
||||
|
||||
## 18. 2026-08-12 버튼 색상·문구·순서 통일
|
||||
|
||||
- 목록 액션을 `엑셀다운로드 → 등록 → 수정 → 상세보기 → 삭제` 순서로 정리하고 삭제를 항상 마지막에 배치했다.
|
||||
- 엑셀다운로드·등록·수정은 파란색, 상세보기·초기화·취소는 흰색, 삭제는 빨간색으로 통일했다.
|
||||
- 등록·수정 팝업은 `저장 → 취소`, 지도 위치 편집은 `선택 위치 적용 → 취소` 순서를 적용했다.
|
||||
- 등록 건과 사진 삭제 아이콘은 모두 빨간색 destructive 동작으로 표시하고, 사진 행 선택 버튼은 흰색 보조 동작으로 유지했다.
|
||||
- 검색은 `조회 → 초기화` 순서를 유지했으며 기존 이벤트와 비활성화 조건은 변경하지 않았다.
|
||||
|
||||
## 19. 2026-08-13 상세보기 기능 제거
|
||||
|
||||
- 목록 액션에서 `상세보기`를 제거하고 `엑셀다운로드 → 등록 → 수정 → 삭제`만 유지했다. 삭제는 기존 규칙대로 마지막에 배치한다.
|
||||
- 별도 `dredgingDetail` WindowPopup 정의와 레지스트리 항목, 상세 전용 content를 제거해 URL로 직접 진입하는 상세 기능도 함께 정리했다.
|
||||
- 수정 화면은 기존과 같이 관로정보·준설일자·사진·위치·자동매핑 정보를 모두 제공하므로 조회에 필요한 정보 확인과 편집 기능은 유지된다.
|
||||
- 수정 화면에서도 사용하는 검색 파라미터 복원 로직은 중립 유틸 파일로 분리했으며 API, 저장 payload, 부모창 갱신 메시지는 변경하지 않았다.
|
||||
- 요구사항정의서 sheet3의 `SFR-010-013`은 준설 등록·수정·삭제·조회를 요구하지만 별도 상세 버튼을 강제하지 않는다. 화면설계서 슬라이드 51의 `SN_MN040201`과 슬라이드 53의 `SN_MN040202`도 등록·조회·다운로드 중심이며, 슬라이드 57의 별도 세부현황은 `화면 삭제`로 표시되어 있다.
|
||||
|
||||
@@ -0,0 +1,117 @@
|
||||
# SN CS UI 통일 2차 구현 기록
|
||||
|
||||
## 1. 작업 목적
|
||||
|
||||
- CS의 카드, 검색, 버튼, 폼, 목록, 페이징, 팝업 UI를 SN의 도시침수예방사업, 침입수 분석, RDII 분석과 하수관망도 WindowPopup에 적용한다.
|
||||
- 하수관망도 지도 자체는 변경하지 않고 지도에서 여는 WindowPopup만 통일한다.
|
||||
- 기존 API, 파일 업로드, 분석 실행, 부모 지도 메시지와 지도 하이라이트 흐름은 유지한다.
|
||||
|
||||
## 2. 원본 요구사항 확인
|
||||
|
||||
- 원본 `화면설계서.pptx`와 `요구사항정의서.xlsx`를 직접 대조했다.
|
||||
- 하수관망도 WindowPopup은 화면설계서 7~17쪽, 20~25쪽과 SFR-010/011/012 계열의 지도 조회 흐름을 유지했다.
|
||||
- 도시침수예방사업 업무 CRUD와 침입수·RDII 업무 화면은 원본에 직접 대응하는 화면 ID 및 요구사항 ID가 없어, 기존 기능 계약을 보존한 `UI 통일 설계 제안`으로 적용했다.
|
||||
- 도시침수예방사업은 승인된 기존 작업계획의 `/oper/ctyFldngPrvtnBiz`와 기존 호환 경로 `/oper/floodPre`를 함께 유지했다.
|
||||
|
||||
## 3. 공통 적용 규칙
|
||||
|
||||
- 검색 버튼은 `조회` 파란색, `초기화` 흰색 순서로 통일했다.
|
||||
- 엑셀 파일 액션은 `엑셀다운로드`, 업로드 양식은 `양식다운로드`로 통일했다.
|
||||
- 삭제 버튼은 빨간색이며 액션의 마지막에 배치했다.
|
||||
- 목록의 `NO`는 `순번`으로 바꾸고 전체 건수에서 현재 페이지 위치를 차감해 내림차순으로 표시한다.
|
||||
- 목록 타이틀 옆 총 건수 표시는 제거했다.
|
||||
- 헤더는 항상 가운데 정렬하고 데이터 셀은 내용 성격에 따라 정렬한다.
|
||||
- 사용자 헤더 정렬 기능과 관련 정렬 상태·이벤트를 제거하고 서버 기본 최신순만 유지한다.
|
||||
- 일반 페이지 크기의 목록은 내부 세로 스크롤을 만들지 않고 창 스크롤을 사용한다. 열이 많은 표만 내부 가로 스크롤을 사용한다.
|
||||
- 로딩은 공통 `LoadingOverlay`, 사용자 메시지는 CS와 같은 `AlertDialog`와 `ConfirmDialog` 흐름을 유지한다.
|
||||
|
||||
## 4. CS 컴포넌트 그대로 사용한 범위
|
||||
|
||||
- `BaseLayout`, `Header`, `LNB`, `Footer`, `PageTitle`
|
||||
- `Button`, `Input`, `Label`, `Select`, 날짜/월 선택 컴포넌트
|
||||
- `DataTable`, `Table`, `Dialog`, `LoadingWithAnimation`
|
||||
- `AlertDialog`, `ConfirmDialog`와 `useAlertStore`, `useConfirm` 메시지 흐름
|
||||
- 공통 카드 클래스 `card`, `card-border`, `card-header`
|
||||
|
||||
## 5. 커스텀 유지 범위
|
||||
|
||||
- CS 배치 규칙을 재사용 가능하게 묶은 중립 래퍼 `StandardDataTable`, `StandardFormSection`, `StandardFormField`, `StandardPopupLayout`
|
||||
- SN의 서버 페이징·역순 순번 계약을 공통 표에 연결하는 앱 로컬 `MapPopupDataTable`, `ExmnStandardDataTable`
|
||||
- 도시침수예방사업의 다단 Excel 헤더와 시설 가변 행
|
||||
- 관로분석 연도·재질 병합표의 `rowSpan`
|
||||
- 침입수·RDII 결과 차트와 결과 전용 모드
|
||||
- 지도 WindowPopup의 부모창 `postMessage`, 관로 선택, 지도 이동과 하이라이트
|
||||
- 준설 사진 업로드·EXIF 위치·지도 선택과 GIS GeoPackage 업로드/미리보기처럼 CS에 동일 기능이 없는 업무 UI
|
||||
|
||||
## 6. 대상 화면
|
||||
|
||||
- 도시침수예방사업 목록, 등록·상세·수정, 업로드와 Excel 상세 팝업
|
||||
- 침입수 분석 입력·결과 목록·지도 결과 팝업·차트 팝업
|
||||
- RDII 분석 입력·결과 목록·지도 결과 팝업·차트 팝업
|
||||
- 노후관로, 시도별 노후관로, 침수이력, 지반침하, 침수위험지도, 도시침수지도, 관로분석, 보수이력, 통수위험, GIS 관리, 관망도 검색, 보고서, 우수토실, GIS 편집 세션 등 하수관망도 WindowPopup
|
||||
|
||||
## 7. 검증
|
||||
|
||||
- 대상 파일 Prettier 검사를 통과했다.
|
||||
- `git diff --check`를 통과했다.
|
||||
- `pnpm exec tsc --noEmit --incremental false --pretty false --ignoreDeprecations 5.0`을 통과했다.
|
||||
- 실행 중인 사용자 개발 서버를 보호하기 위해 Next build는 실행하지 않았다.
|
||||
- `http://localhost:3002`에서 하수관망도, 도시침수예방사업 목록·등록, 노후 하수관로 목록, 조사·준설·처리분구, 침입수·RDII 분석을 직접 열어 확인했다.
|
||||
- 관망도 검색의 기본·유지관리·보고서 탭, 관로분석, GIS 관리, 노후관로, 지반침하, 침입수 결과와 준설·조사 등록 WindowPopup을 직접 열어 버튼·헤더·스크롤·로딩을 확인했다.
|
||||
- 긴 도시침수예방사업 등록 화면에서 `scrollY=1300` 상태에도 공통 헤더가 `sticky`, `top=0`으로 유지됨을 확인했다.
|
||||
- 일반 목록의 내부 세로 오버플로가 없고, 팝업은 공통 팝업 본문 스크롤만 사용하며, 브라우저 콘솔 오류가 없음을 확인했다.
|
||||
|
||||
## 8. 영향 및 롤백
|
||||
|
||||
- 변경은 `apps/sn` 화면과 `packages/common/business_components`의 중립 신규 컴포넌트·클라이언트 경계 보완에 한정한다.
|
||||
- 현재 `StandardDataTable`, `StandardForm*`, `StandardPopupLayout`의 실제 소비자는 SN뿐이며 WR, DM, FO 화면은 자동 변경되지 않는다.
|
||||
- 기존 훅 기반 비즈니스 컴포넌트의 `use client` 선언은 Next 클라이언트 경계를 명시하는 변경이며 시각 규격이나 공개 props를 바꾸지 않는다.
|
||||
- 롤백 시 SN 업무·지도 팝업 UI, 앱 로컬 어댑터와 중립 `Standard*` 신규 컴포넌트 및 export/dependency 변경을 함께 되돌린다.
|
||||
|
||||
## 9. 남은 리스크
|
||||
|
||||
- 원본에 직접 대응 화면이 없는 도시침수 업무 CRUD와 침입수·RDII 업무화면은 현행 코드와 API 계약을 기준으로 한 설계 제안이다.
|
||||
- 저장·삭제·파일 업로드, 실제 분석 실행과 실데이터 행 선택 후 지도 이동·하이라이트는 데이터 변경을 피하기 위해 이번 전수 UI 회귀검증에서는 실행하지 않았다.
|
||||
|
||||
## 10. 2026-08-13 지도 상단 검색바 정렬 보완
|
||||
|
||||
- 지도 상단의 선택박스는 높이 35px, 조회 버튼은 높이 25px인데 버튼에만 상단 여백이 적용되어 두 요소의 중심선이 5px 어긋난 상태를 브라우저에서 확인했다.
|
||||
- `ProcSearchBar`와 `SearchBar`의 검색 행 및 버튼 영역에 세로 중앙 정렬을 적용하고 버튼의 임의 상단 여백을 제거했다. 버튼 크기, 색상, 이벤트와 선택박스 동작은 변경하지 않았다.
|
||||
- 공통 `SearchBar`는 FO와 WR 지도에서 사용되고, `ProcSearchBar`는 SN 하수관망도에서 사용된다. DM과 WR 일부 화면의 앱 로컬 검색바는 이번 변경 대상이 아니다.
|
||||
- 수정 후 SN 하수관망도에서 선택박스 3개와 조회 버튼의 중심선이 모두 103px로 일치함을 확인했다.
|
||||
- SN 전체 TypeScript 검사와 대상 파일 `git diff --check`를 통과했다.
|
||||
|
||||
## 11. 2026-08-13 분석도구 팝업·버튼·로딩 재점검
|
||||
|
||||
- 침입수·RDII 입력 화면의 상단 액션, 조회, 파일 선택 버튼을 CS 기본 높이 32px로 통일했다. 버튼 순서는 `양식다운로드 → 분석 실행 → 결과보기`, `조회 → 초기화`를 유지했다.
|
||||
- 침입수·RDII 결과 목록에서 최초 조회가 두 번 실행되던 중복 effect를 제거했다. 입력 화면은 전체 화면 로더 하나, 결과 목록은 표 로더 하나만 사용한다.
|
||||
- 관망도 정보검색은 compact underline 탭, 탭별 검색 카드와 기본 높이 버튼을 적용했다. 중첩 카드와 중복 로더를 제거하고 필요한 가로 스크롤만 유지했다.
|
||||
- `mapSearch` WindowPopup은 `maximize: true`로 설정하여 `screen.availWidth`와 `screen.availHeight` 기준의 가용 화면 전체 크기로 연다.
|
||||
- 관로분석·관로현황, 시도별 노후관로, GIS 관리, 통수위험, 침입수·RDII 분석결과 팝업의 검색 필드·버튼·카드·탭·표 헤더를 다시 점검했다. 통수위험은 공통 underline 탭으로 전환했고, 관로분석의 연도·재질 병합표는 업무상 `rowSpan`을 유지하면서 CS 카드와 파란 중앙 헤더를 적용했다.
|
||||
- 분석도구 메뉴 9개 항목을 확인했다. 정보검색, 관로분석, 시도별 노후관로, GIS 관리, 통수위험, 침입수·RDII 결과는 실제 팝업이며, GIS 편집은 지도 내부 편집 토글이다. 침수예측현황은 기존 placeholder로서 요구 기능을 임의 구현하지 않았다.
|
||||
- 전역 로딩 사용처를 정적 감사하고 전체 화면 `LoadingOverlay`와 `StandardDataTable` 로딩을 동시에 쓰던 7개 목록에서 표 로딩을 제거했다. 이후 검사에서 동일 파일 내 전체 화면 로더와 표 로더 중복은 0건이다.
|
||||
- `packages/common`에서 이번 UI 통일 변경이 있는 범위는 사용자 소유의 `packages/common/business_components`뿐이며, 다른 공용 패키지는 수정하지 않았다.
|
||||
- 원본 추적 근거는 화면설계서 슬라이드 8~17, 19~23과 요구사항정의서 sheet3 87~95행이다. 정보검색과 침입수·RDII 업무 화면은 직접 대응 화면 ID가 없어 기존 기능 계약을 보존한 UI 설계 제안으로 분류한다.
|
||||
- 침입수·RDII 네 화면은 브라우저에서 버튼 높이와 콘솔 오류 0건을 확인했다. 목록 로딩은 지연 응답을 주입해 전체 화면 로더 1개·표 로더 0개를 확인했다. 정보검색은 3개 탭 전환과 조회·초기화·엑셀다운로드·지도에서 보기 버튼 32px를 확인했고, 관로분석·통수위험은 파란 중앙 헤더, 순번, 32px 버튼, 내부 세로스크롤 0건을 확인했다. 분석도구의 8개 WindowPopup 경로는 모두 HTTP 200이며 런타임 오류가 없음을 확인했다. 사용자 개발 서버가 일시 중단된 동안에는 임의 재기동하지 않았으며 자동 복구된 뒤 최종 브라우저 회귀검증을 완료했다.
|
||||
|
||||
## 12. 2026-08-13 조사 상세·분석 차트·WindowPopup 취소·GIS 편집 재점검
|
||||
|
||||
- 조사 목록 행 선택 시 상세 카드 헤더 안에 직접 렌더되던 절대배치 스피너를 제거하고 공통 전체 화면 `LoadingOverlay` 하나만 사용하도록 변경했다. 런타임 소스의 직접 `LoadingWithAnimation` 사용처는 안전한 공통 로더 래퍼 한 곳만 남겼다.
|
||||
- 조사 목록과 상세 집계표 헤더 높이를 공통 상수 `5.6rem`으로 묶었다. 브라우저에서 목록과 상세의 첫 헤더 높이가 모두 `56px`임을 실측했다.
|
||||
- 침입수·RDII 차트 팝업을 `StandardPopupLayout`, `StandardFormSection`, `StandardFormField` 기반의 2열 조건·결과 요약·그래프 카드 구조로 통일했다. 두 화면 모두 하단 액션은 `조회 → 초기화 → 취소`이고 버튼 높이는 `32px`이다.
|
||||
- WindowPopup 레지스트리 33개 키를 감사했다. 준설 상세 기능 제거 후 자체 저장·수정 보호 로직을 가진 6개 키는 기존 취소를 유지하고, 나머지 27개 키는 공통 팝업 레이아웃이 마지막 액션으로 흰색 `취소(window.close)`를 제공한다.
|
||||
- GIS 편집세션은 레이어·도구·변경 건수 상태, 변경 항목 선택 강조, `선택 취소/최근 취소/전체 초기화`를 그룹화했다. 지도 하단 편집툴바는 편집도구, 스냅핑, `저장 → 취소` 영역으로 나눠 높이를 `37px` 수준으로 줄였다.
|
||||
- 처리구역 분석 표 셀 안의 직접 스피너도 제거해 카드 단일 로딩 상태로 통일했다.
|
||||
- 팝업 레지스트리의 정적 import가 브라우저 전용 엑셀 모듈을 SSR에서 평가해 모든 `/popup/*` 경로를 막던 결합 문제를 발견했다. 팝업 렌더러를 클라이언트 경계로 이동하고 노후관로·도시침수 Excel 상세를 동적 import하여 팝업 간 의존성 전파를 차단했다.
|
||||
- 브라우저에서 조사 목록·상세 헤더 `56px/56px`, 침입수·RDII 차트 팝업의 `조회/초기화/취소` `32px`, 정보검색 팝업 상단 `취소`, GIS 편집세션과 하단 `저장 → 취소` 그룹을 확인했다. 팝업 경로의 Turbopack 런타임 오류는 클라이언트 경계 보완 후 재현되지 않았다.
|
||||
- SN 전체 TypeScript 검사는 `--ignoreDeprecations 5.0` 조건에서 통과했고 `git diff --check`도 통과했다. 원본 근거는 조사 SFR-010-004~007 및 화면설계서 슬라이드 47~49, GIS 편집 SFR-012-003~004 및 화면설계서 슬라이드 32이다. 침입수·RDII 차트는 원본 직접 화면 ID가 없어 UI 설계 제안으로 유지한다.
|
||||
|
||||
## 13. 2026-08-13 통수위험 분석결과 팝업 표준화
|
||||
|
||||
- 통수위험 팝업에 남아 있던 전용 HTML 표를 앱 로컬 `MapPopupDataTable`로 교체해 다른 지도 분석 팝업과 동일한 CS 카드·표·페이징 구조를 적용했다.
|
||||
- 전용 표의 헤더와 빈 행 높이가 각각 `28.5px`로 눌리고 바로 아래에 가로 스크롤바가 붙던 문제를 제거했다. 빈 결과는 공통 `240px` 중앙 안내 영역으로 표시하며 데이터가 있을 때만 표와 필요한 가로 스크롤을 렌더한다.
|
||||
- 현재 위험과 과거 이력 탭별 열 구성, 전체 건수 기준 내림차순 순번, 수치 소수점, 위험 배지, 행 선택 후 부모 지도 강조, API와 `postMessage` 계약은 유지했다.
|
||||
- `MapPopupDataTable`에는 선택 행 ID를 선택적으로 전달하는 앱 로컬 속성을 추가했다. 기존 소비 화면은 속성을 전달하지 않으므로 동작과 스타일에 영향이 없다.
|
||||
- 팝업 제목을 `통수위험 분석결과 목록`으로 정리하고 공통 흰색 `취소` 버튼, `조회 → 초기화`, 32px 검색 컨트롤, underline 탭과 전체 화면 로더 하나를 유지했다.
|
||||
- 원본 근거는 화면설계서 슬라이드 20~23의 `SN_MN010202~010204`, `SFR-011-007~008`과 요구사항정의서 sheet3 93행 `SFR-011-007`, `PR-SN-026`이다. 현재·과거 목록 팝업 자체의 정확한 원본 화면은 없어 목록 배치는 기존 기능을 보존한 UI 설계 제안으로 분류한다.
|
||||
- 브라우저에서 현재 위험·과거 이력 탭 전환, 검색조건 라벨 변경, 공통 취소, 빈 결과 높이 `240px`, 내부 세로 스크롤 없음과 전체 화면 로더 단일 사용을 확인했다. SN 전체 TypeScript 검사와 대상 파일 `git diff --check`를 통과했다.
|
||||
@@ -0,0 +1,127 @@
|
||||
# SN 전체 화면 인벤토리 및 UI 검증 기록
|
||||
|
||||
## 1. 작업 목적
|
||||
|
||||
- 디지털하수관로 SN 앱의 화면 수를 본창 라우트, WindowPopup, 내부 Dialog로 구분해 재현 가능한 기준으로 확정한다.
|
||||
- 원본 화면설계서·요구사항 추적표와 현재 코드를 대조하고, 실제 브라우저에서 주요 UI 규칙을 전수 확인한다.
|
||||
- 화면 수를 단순 `page.tsx` 파일 수로 오인하지 않도록 리다이렉트, 별칭, 개발용 화면과 실제 업무 화면을 분리한다.
|
||||
|
||||
## 2. 원본 요구사항 추적 근거
|
||||
|
||||
- 화면설계서 `화면설계서.pptx` 전체 58장을 직접 렌더링해 확인했다.
|
||||
- 화면설계서 3쪽의 화면 목차에는 하수관망도·유지관리 관련 화면 항목 33개가 기재되어 있다. 마지막 번호가 준설 상세현황과 준설결과 업로드에 중복 표기되어 있어 번호 값이 아니라 행 수로 집계했다.
|
||||
- 요구사항정의서 `3. (기능)요구사항정의 및 추적표` 73~100행의 SFR-010-001~014, SFR-011-001~009, SFR-012-001~005를 대조했다.
|
||||
- 원본 33개는 지도 내부 패널·상세 상태를 각각 화면으로 센 설계 화면 수이며, Next 라우트 수 또는 WindowPopup 수와 일치하는 개념이 아니다.
|
||||
- 도시침수예방사업 CRUD와 침입수·RDII 업무 화면은 원본에 직접 대응하는 화면 ID가 없어 기존 API와 기능을 유지하는 `UI 통일 설계 제안` 범위로 분류한다.
|
||||
|
||||
## 3. 코드 기준 화면 수
|
||||
|
||||
### 3.1 Next 라우트 파일
|
||||
|
||||
`apps/sn/app/**/page.tsx`는 총 27개다.
|
||||
|
||||
| 구분 | 수 | 설명 |
|
||||
| -------------- | --: | ------------------------------------------------------------- |
|
||||
| 실제 업무 본창 | 17 | 지도, I/I 4개, 운영·유지관리 목록/등록/수정 화면 |
|
||||
| 인증 화면 | 1 | `/auth/login` |
|
||||
| 인프라 라우트 | 2 | `/` 자동 로그인·이동, `/popup/[popupKey]` 동적 팝업 호스트 |
|
||||
| 별칭·호환·시안 | 4 | `/map2`, `/map/agedPipePopup`, `/html/map`, `/html/aged-pipe` |
|
||||
| 개발·시험 화면 | 3 | `/ii/fileupload`, `/ii/test`, `/oper/operStore` |
|
||||
| 합계 | 27 | 실제 사용자 화면 수와 단순 동일시하지 않음 |
|
||||
|
||||
실제 업무 본창 17개는 다음과 같다.
|
||||
|
||||
1. `/map`
|
||||
2. `/ii/irsetting`
|
||||
3. `/ii/rdii`
|
||||
4. `/ii/result`
|
||||
5. `/ii/rdiiResult`
|
||||
6. `/oper/ctyFldngPrvtnBiz`
|
||||
7. `/oper/ctyFldngPrvtnBiz/register`
|
||||
8. `/oper/ctyFldngPrvtnBiz/register/[id]`
|
||||
9. `/oper/dredging`
|
||||
10. `/oper/exmn/register`
|
||||
11. `/oper/exmn/status`
|
||||
12. `/oper/floodPre`
|
||||
13. `/oper/obsltPplBiz`
|
||||
14. `/oper/obsltPplBiz/register`
|
||||
15. `/oper/obsltPplBiz/register/[id]`
|
||||
16. `/oper/oldPp`
|
||||
17. `/oper/trtdst`
|
||||
|
||||
### 3.2 WindowPopup
|
||||
|
||||
- `windowPopupDefinitions` 정의: 33개
|
||||
- `windowPopupRegistry` 구현 매핑: 33개
|
||||
- 정의 누락 또는 레지스트리 초과: 0개
|
||||
- 기능 구현 팝업: 31개
|
||||
- 안내용 placeholder: 2개 (`floodPredictionMapPopup`, `gisEditPopup`)
|
||||
|
||||
| 업무군 | WindowPopup key |
|
||||
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 운영·유지관리 | `cfmtnBgt`, `exmnBusinessRegister`, `exmnResultRegister`, `exmnSurveyDetail`, `dredgingRegister`, `dredgingEdit`, `exmnPipeReport`, `oldPpUpload`, `oldPpTable`, `floodPreUpload`, `floodPreTable` |
|
||||
| 보고서·정보검색 | `reportTab`, `reportFiles`, `mapSearch` |
|
||||
| I/I | `inftwtResultPopup`, `rdiiResultPopup`, `infilChart`, `rdiiChart` |
|
||||
| 지도 시설·분석 | `sscDetail`, `agedPipePopup`, `sinkholePopup`, `sbmrgDngrMapPopup`, `floodDngrMapPopup`, `pipeAnalysisPopup`, `pipeAnalysisDetailPopup`, `repairHistoryPopup`, `agedPipeStatusByCtpvPopup`, `fldngHstryPopup`, `gisEditSessionPopup`, `gisManagementPopup`, `flowRiskPopup` |
|
||||
| 구조만 연결된 안내 | `floodPredictionMapPopup`, `gisEditPopup` |
|
||||
|
||||
### 3.3 내부 Dialog
|
||||
|
||||
- 앱 전역 사용자 메시지 Dialog는 `AlertDialog`, `ConfirmDialog`, `PromptDialog` 3종이다.
|
||||
- `DredgingRegisterModal`의 Dialog는 `dredgingRegister` WindowPopup 본문 자체이므로 별도 논리 화면으로 중복 집계하지 않는다.
|
||||
- `PplSummaryModal`, `PplFacilityDetailModal`은 현재 런타임 호출부가 없는 휴면 컴포넌트다. 활성 업무 화면 수에는 포함하지 않는다.
|
||||
|
||||
따라서 현재 운영 대상으로 보는 논리 화면은 `업무 본창 17 + 기능 WindowPopup 31 = 48개`다. 로그인까지 포함하면 49개이며, placeholder 2개까지 포함한 등록 화면은 51개다.
|
||||
|
||||
## 4. 브라우저 전수 검증
|
||||
|
||||
### 4.1 본창
|
||||
|
||||
- 로그인 후 실제 업무 본창 17개와 인증 화면을 직접 열었다.
|
||||
- 각 본창은 최종 재검증에서 최초 문서 요청 HTTP 200, 애플리케이션 오류 문구 없음, 문서 가로 넘침 0을 확인했다.
|
||||
- 목록·등록·수정 화면의 제목, 검색 카드, 버튼 순서·색상, 표 헤더, 가로 오버플로, 빈 상태와 하단 액션을 확인했다.
|
||||
- `/oper/exmn/status`에서 실제 조사사업과 덕풍처리분구 행을 선택하고, 실제 생성된 `exmnSurveyDetail` 팝업에서 관로 3건과 결함 집계를 조회했다.
|
||||
- 조사 목록과 상세 요약 표의 단일 헤더는 모두 56px 규격을 사용한다. 관로조사 상세 팝업의 결함표는 4단 복합 헤더이므로 전체 높이는 데이터 구조에 따라 더 크지만, 각 헤더 셀의 패딩·색상·가운데 정렬은 같은 표 토큰을 사용한다.
|
||||
- 같은 흐름에서 상세 로딩은 공통 로딩 오버레이 하나만 사용하고, 헤더 내부의 로더·`조회하고 있습니다` 보조 문구가 중복되지 않음을 확인했다.
|
||||
- 긴 등록 화면에서 상단 헤더는 스크롤 후에도 `position: sticky`, `top: 0`을 유지했다.
|
||||
- `/oper/ctyFldngPrvtnBiz/register/228`, `/oper/obsltPplBiz/register/128`의 실제 수정 화면까지 열어 저장·취소·삭제 순서와 크기를 확인했다.
|
||||
|
||||
### 4.2 WindowPopup
|
||||
|
||||
- 33개 key를 모두 `/popup/{popupKey}`로 직접 열었다.
|
||||
- 필수 파라미터가 있는 팝업은 시험 파라미터를 제공해 실제 본문을 렌더했다.
|
||||
- 실제 조사 상세·관로보고서는 실데이터 식별자로 확인했고, 데이터가 없는 팝업은 로더 종료 후 빈 상태를 확인했다. 파일 식별자가 필요한 상세 팝업은 필수 파라미터 안내 상태를 확인했다.
|
||||
- 33개 모두 최종 문서 요청 HTTP 200, 팝업 타이틀과 32px `취소` 버튼이 존재하고, 문서 전체의 불필요한 가로 스크롤은 없었다.
|
||||
- `mapSearch`는 최대화 상태, compact 탭, 기본 정보·유지관리·보고서 흐름을 확인했다.
|
||||
- 관로분석, 통수위험, GIS 관리, 노후관로, 지반침하, 침수지도, 침입수·RDII 결과와 차트의 검색·목록·빈 상태를 확인했다.
|
||||
- 안정화 후 주요 액션 버튼은 32px로 렌더됐다. 표 셀 링크, 지도 확대·축소, 페이지 번호와 같은 컨텍스트 컨트롤은 별도 소형 규격으로 유지했다.
|
||||
- 33개 팝업의 최종 상태에서 가시 로딩 스피너 0, `Internal Server Error`, `Application error`, 미등록 popup key 오류 없음으로 종료했다.
|
||||
|
||||
## 5. 이번 보완
|
||||
|
||||
- 도시침수예방사업 등록·수정과 노후 하수관로 정비사업 등록·수정의 하단 저장·취소·삭제가 `size="lg"`로 40px이던 불일치를 제거했다.
|
||||
- 두 화면 모두 CS 기본 Button 32px로 맞추고 `저장 → 취소 → 삭제` 순서와 색상은 유지했다.
|
||||
- 지도 상단 공통 검색바의 조회·초기화와 지도 분석 팝업에 남아 있던 25px 버튼을 공통 32px Button으로 통일했다.
|
||||
- 공통 SelectBox와 노후관로·침수위험지도·침수이력·보수이력 팝업에 남아 있던 35px 입력을 32px로 통일했다.
|
||||
- 관로조사 상세 팝업의 모드·조회 버튼을 32px로 통일하고 중복 로딩 안내를 제거했다.
|
||||
- `business_components`의 Excel export 모듈이 `xlsx-populate`를 서버 평가하면서 모든 본창·팝업 최초 요청을 500으로 만들던 문제를 동적 로딩으로 격리했다. 보완 후 침입수·RDII 본창과 33개 팝업의 최초 문서 요청이 HTTP 200임을 확인했다.
|
||||
- 화면 수와 팝업 정의·레지스트리 일치 여부를 다시 확인할 수 있도록 `apps/sn/scripts/audit-screen-inventory.mjs`를 추가했다.
|
||||
- 다른 회사 공통 코드인 `packages/common/components`는 수정하지 않았다. 공통 변경은 사용자가 허용한 `packages/common/business_components` 범위에만 적용했다.
|
||||
|
||||
## 6. 재검증 명령
|
||||
|
||||
```powershell
|
||||
node apps/sn/scripts/audit-screen-inventory.mjs
|
||||
pnpm --filter sn exec tsc --noEmit --incremental false --pretty false --ignoreDeprecations 5.0
|
||||
git diff --check -- apps/sn packages/common/business_components
|
||||
```
|
||||
|
||||
사용자가 실행 중인 Next 개발 서버와 `.next` 산출물을 보호하기 위해 `next build`는 실행하지 않는다.
|
||||
|
||||
## 7. 영향·롤백·남은 리스크
|
||||
|
||||
- API, DB, 요청·응답 구조와 저장 로직에는 영향이 없다.
|
||||
- 이번 코드 보완의 롤백은 대상 SN 화면의 Button/Select 규격 변경, `business_components`의 검색바·SelectBox·Excel 지연 로딩 변경, 인벤토리 스크립트·문서를 되돌리면 된다.
|
||||
- `floodPredictionMapPopup`은 원본 요구사항이 있으나 현재 안내 화면만 연결된 미구현 기능이다.
|
||||
- `gisEditPopup` 직접 URL은 안내 화면이지만 실제 메뉴의 GIS 편집은 지도 본창의 인라인 편집 세션으로 동작한다.
|
||||
- 저장·삭제·업로드·분석 실행은 외부 데이터 변경을 피하기 위해 누르지 않았고, 화면 렌더·조회·행 선택까지를 회귀검증 범위로 삼았다.
|
||||
@@ -0,0 +1,113 @@
|
||||
# 2026-08-12 SN CS UI 통일 작업내용
|
||||
|
||||
## 1. 작업 목적
|
||||
|
||||
- 디지털하수관로 `sn` 앱의 UI를 통합플랫폼관리 `cs` 기준으로 통일한다.
|
||||
- 준설관리를 우선 적용 화면으로 삼되, 하수관망도 지도 자체를 제외한 전체 업무 화면에 재사용할 수 있는 구조로 설계한다.
|
||||
- `wr`, `dm`, `fo` 등 다른 앱도 사용하는 공통 영역의 영향을 고려하고, 공통 수정은 사용자 소유 범위인 `packages/common/business_components`로 제한한다.
|
||||
|
||||
## 2. 원본 및 기준 확인
|
||||
|
||||
- 화면설계서 `화면설계서.pptx`와 요구사항정의서 `요구사항정의서.xlsx`를 확인했다.
|
||||
- 조사사업은 SFR-010-004~007, 준설관리는 SFR-010-012, 하수관망도 분석은 SFR-011/012 계열을 기준으로 기존 기능을 유지했다.
|
||||
- 도시침수예방사업 CRUD와 침입수·RDII 업무 화면은 원본에 직접 대응하는 화면 ID가 없어 기존 API·기능을 유지한 `UI 통일 설계 제안`으로 분류했다.
|
||||
|
||||
## 3. 주요 작업 내용
|
||||
|
||||
### 3.1 공통 UI 규칙 수립
|
||||
|
||||
- 검색 액션을 `조회 → 초기화` 순서로 통일했다.
|
||||
- 조회·등록·수정·저장·다운로드 계열은 파란색, 취소·닫기·상세보기 계열은 흰색, 삭제는 빨간색으로 정리했다.
|
||||
- 삭제 버튼은 액션 영역의 마지막에 배치했다.
|
||||
- 다운로드 문구는 데이터 파일이면 `엑셀다운로드`, 업로드 템플릿이면 `양식다운로드`로 구분했다.
|
||||
- 목록의 `NO`와 일련번호 표기를 `순번`으로 통일하고, 전체 건수 기준 내림차순 번호를 사용했다.
|
||||
- 목록 제목의 `(총 N건)` 표시는 제거했다.
|
||||
- 표 헤더는 파란색 배경, 흰색 글자, 가운데 정렬로 통일하고 사용자 정렬 UI는 제거했다.
|
||||
- 일반 목록은 내부 세로 스크롤을 사용하지 않고 브라우저 스크롤로 제어하며, 열이 많은 표만 가로 스크롤을 사용하도록 했다.
|
||||
|
||||
### 3.2 재사용 컴포넌트 구성
|
||||
|
||||
- CS 표 구조를 재사용하기 위한 `StandardDataTable`을 구성했다.
|
||||
- 등록·수정·상세 폼의 2~3열 배치를 위한 `StandardFormSection`, `StandardFormField`를 구성했다.
|
||||
- WindowPopup의 타이틀·본문·액션 배치를 통일하는 `StandardPopupLayout`을 구성했다.
|
||||
- SN 서버 페이징과 역순 순번을 연결하는 앱 로컬 `MapPopupDataTable`, `ExmnStandardDataTable`을 구성했다.
|
||||
- 컴포넌트명에는 `Sn` 접두사를 사용하지 않아 다른 앱에서도 재사용할 수 있도록 했다.
|
||||
|
||||
### 3.3 준설관리
|
||||
|
||||
- 경과년도별·관경별·지자체별 목록 제목을 `준설 목록`으로 통일했다.
|
||||
- 검색 카드, 조회·초기화, 목록 표, 페이징과 액션 버튼을 CS 규격으로 변경했다.
|
||||
- 등록·수정 화면을 공통 팝업과 표형 폼 구조로 변경했다.
|
||||
- 준설일자와 자동매핑을 같은 행에 배치하고 관로번호를 관로정보 영역 우측으로 이동했다.
|
||||
- 사진 기반 수정에서 사진이 없을 때 검증 메시지를 표시하고 직접 등록 방식으로 전환할 수 있도록 기존 흐름을 보완했다.
|
||||
- 달력을 부모 화면과 같은 날짜 선택 컴포넌트로 통일했다.
|
||||
- 사진 삭제·위치정보·저장 후 상세 진입 흐름을 보완했다.
|
||||
- 목록의 중복 세로 스크롤을 제거하고 가로 스크롤과 페이징 사이의 간격을 공통 표 규격으로 맞췄다.
|
||||
|
||||
### 3.4 조사관리·처리분구관리
|
||||
|
||||
- 조사 목록, 조사사업 등록·수정, 결과 업로드, 상세현황 팝업을 CS 카드·표·버튼 규격으로 변경했다.
|
||||
- 처리분구 선택 영역은 기존 체크박스 카드 방식을 유지하면서 제목·검색·빈 상태·간격을 통일했다.
|
||||
- 사업정보와 사업대상 처리분구 카드 사이에 공통 간격을 적용했다.
|
||||
- 맨홀·관로 조사 집계표의 전용 녹색/레거시 스타일을 제거하고 파란 중앙 헤더로 통일했다.
|
||||
- 상세 화면의 불필요한 `맨홀조사 종합집계표`, `관로조사 종합집계표` 중복 타이틀을 제거했다.
|
||||
- 조사사업 등록, 결과등록, 조사상세, 관로보고서 팝업을 공통 팝업 구조로 변경했다.
|
||||
|
||||
### 3.5 노후 하수관로·도시침수 예방사업
|
||||
|
||||
- 노후 하수관로 정비사업 목록·등록·수정과 최종확정예산사업 팝업을 공통 검색·표·폼 구조로 변경했다.
|
||||
- 도시침수예방사업의 신규 CRUD 경로와 기존 파일형 호환 경로를 모두 통일했다.
|
||||
- Excel 다중 탭 상세는 업무상 가변 열을 유지하면서 공통 표, 10건 페이징, 가로 스크롤을 적용했다.
|
||||
- 등록·수정 폼은 기본정보·연도결산·단계별 정보를 2~3열로 배치했다.
|
||||
|
||||
### 3.6 침입수·RDII 분석과 지도 WindowPopup
|
||||
|
||||
- 침입수·RDII 분석 입력, 결과 목록, 지도 결과, 차트 팝업에 공통 카드·폼·표 구조를 적용했다.
|
||||
- 관망도 정보검색, 관로분석, 노후관로, 지반침하, 침수위험지도, 도시침수지도, 보수이력, GIS 관리, 통수위험 등 지도 팝업을 통일했다.
|
||||
- `mapSearch`는 기본정보·유지관리·보고서 3개 탭의 기능과 지도 연계 `postMessage`를 유지했다.
|
||||
- 관로분석의 연도·재질 병합표와 조사 결함 다단 헤더처럼 CS에 동일 구조가 없는 표는 업무 구조를 유지한 커스텀 표로 처리했다.
|
||||
|
||||
### 3.7 사용자 메시지
|
||||
|
||||
- 네이티브 `window.alert`, `window.confirm`을 CS 방식의 `useAlertStore`, `useConfirm`으로 변경했다.
|
||||
- 성공 후 이동·팝업 닫기처럼 확인 이후 수행해야 하는 동작은 Alert callback으로 연결했다.
|
||||
- 화면 내 지속형 오류·검증 메시지는 인라인 상태로 유지했다.
|
||||
|
||||
## 4. 주요 수정 범위
|
||||
|
||||
- `apps/sn/app/(with-base-layout)/oper/**`
|
||||
- `apps/sn/app/(with-base-layout)/ii/**`
|
||||
- `apps/sn/app/(map-layout)/map/**`
|
||||
- `apps/sn/src/features/exmn/**`
|
||||
- `apps/sn/src/features/ctyFldngPrvtnBiz/**`
|
||||
- `apps/sn/src/features/obsltPpl/**`
|
||||
- `apps/sn/src/features/windowPopup/**`
|
||||
- `packages/common/business_components/src/ui/standard_*`
|
||||
|
||||
`packages/common/components`와 다른 회사 앱은 수정하지 않았다.
|
||||
|
||||
## 5. 검증
|
||||
|
||||
- 대상 화면의 목록·등록·수정·팝업을 로컬 브라우저에서 확인했다.
|
||||
- 버튼 순서·색상, 표 헤더, 페이징, 가로·세로 스크롤, 사용자 메시지와 팝업 부모창 연계를 점검했다.
|
||||
- TypeScript `--noEmit --ignoreDeprecations 5.0` 검사를 수행했다.
|
||||
- 대상 파일 Prettier와 `git diff --check`를 수행했다.
|
||||
- 사용자 개발 서버를 보호하기 위해 Next production build는 실행하지 않았다.
|
||||
|
||||
## 6. 영향 범위
|
||||
|
||||
- API endpoint, 요청·응답 구조, DB와 저장 계약은 변경하지 않았다.
|
||||
- 공통 `Standard*` 컴포넌트의 현재 실제 소비자는 SN이며, 다른 앱 화면이 자동으로 변경되지는 않는다.
|
||||
- 지도 자체의 레이어·이동·선택 기능은 유지하고 지도에서 여는 WindowPopup UI만 변경했다.
|
||||
|
||||
## 7. 롤백 방법
|
||||
|
||||
- 각 업무 화면의 CS UI 전환 변경을 되돌린다.
|
||||
- 앱 로컬 `MapPopupDataTable`, `ExmnStandardDataTable`과 `business_components`의 `Standard*` 추가·export를 함께 되돌린다.
|
||||
- 사용자 메시지 전환 시 기존 alert/confirm 이후 실행되던 callback 흐름도 함께 복원한다.
|
||||
|
||||
## 8. 남은 리스크
|
||||
|
||||
- 저장·삭제·파일 업로드·분석 실행은 실제 데이터를 변경하므로 UI 검증 단계에서는 실행하지 않았다.
|
||||
- 원본에 직접 대응 화면이 없는 도시침수예방사업 CRUD와 침입수·RDII 업무 화면은 설계 제안 상태다.
|
||||
- 지도 팝업의 실제 데이터 유무에 따라 빈 상태와 가로 스크롤 폭을 추가 확인할 필요가 있었다.
|
||||
@@ -0,0 +1,149 @@
|
||||
# 2026-08-13 SN CS UI 통일 작업내용
|
||||
|
||||
## 1. 작업 목적
|
||||
|
||||
- 전날 적용한 CS UI 통일 결과를 디지털하수관로 전체 화면에서 실제로 검증한다.
|
||||
- 단순 URL 렌더링이 아니라 본창 조회, 탭 전환, 행 선택, WindowPopup 생성과 실데이터 상세 흐름을 확인한다.
|
||||
- 검증 중 발견한 버튼·입력 높이, 로딩 중복, 팝업 취소, 헤더, 스크롤과 SSR 오류를 보완한다.
|
||||
|
||||
## 2. 원본 및 화면 인벤토리 확인
|
||||
|
||||
- 화면설계서 전체 58장과 요구사항정의서 `3. (기능)요구사항정의 및 추적표` 73~100행을 대조했다.
|
||||
- Next `page.tsx` 라우트는 27개로 확인했다.
|
||||
- 실제 업무 본창은 17개, WindowPopup 정의·레지스트리는 각각 33개이며 누락은 0개다.
|
||||
- WindowPopup 33개 중 실제 기능 팝업은 31개, 안내용 placeholder는 `floodPredictionMapPopup`, `gisEditPopup` 2개다.
|
||||
- 현재 운영 대상 논리 화면은 업무 본창 17개와 기능 팝업 31개를 합한 48개다.
|
||||
|
||||
## 3. 실제 브라우저 검증
|
||||
|
||||
### 3.1 본창 17개
|
||||
|
||||
- `/map`
|
||||
- `/ii/irsetting`, `/ii/rdii`, `/ii/result`, `/ii/rdiiResult`
|
||||
- `/oper/ctyFldngPrvtnBiz` 목록·등록·수정
|
||||
- `/oper/dredging`
|
||||
- `/oper/exmn/register`, `/oper/exmn/status`
|
||||
- `/oper/floodPre`
|
||||
- `/oper/obsltPplBiz` 목록·등록·수정
|
||||
- `/oper/oldPp`
|
||||
- `/oper/trtdst`
|
||||
|
||||
각 화면에서 최초 문서 요청 HTTP 200, 애플리케이션 오류 문구 없음, 문서 가로 넘침 없음, 로딩 종료 후 잔존 스피너 없음으로 확인했다.
|
||||
|
||||
### 3.2 WindowPopup 33개
|
||||
|
||||
- 팝업 33개를 동일한 로그인 세션에서 실제로 열었다.
|
||||
- 실데이터가 있는 팝업은 목록과 상세 데이터를 확인했다.
|
||||
- 데이터가 없는 팝업은 로더 종료 후 공통 빈 상태를 확인했다.
|
||||
- 파일·시설 식별자가 필요한 팝업은 필수 파라미터 안내를 확인했다.
|
||||
- 모든 팝업에 마지막 액션으로 32px 흰색 `취소`가 존재함을 확인했다.
|
||||
- 팝업 문서 전체의 불필요한 가로 넘침은 없고, 열이 많은 표 내부에서만 가로 스크롤이 발생함을 확인했다.
|
||||
|
||||
### 3.3 관로조사 상세현황
|
||||
|
||||
- 조사관리 본창에서 실제 조사사업과 처리분구를 선택해 상세현황을 확인했다.
|
||||
- 덕풍처리분구의 관로 3건과 결함 집계가 조회되는 상태를 확인했다.
|
||||
- `관로`, `본단위구간`, `조회`, `초기화`, `엑셀다운로드`, `취소` 버튼 높이를 모두 32px로 통일했다.
|
||||
- 상세 헤더 내부에 있던 별도 로딩 애니메이션과 `조회하고 있습니다` 문구를 제거하고 전체 오버레이 하나만 사용하도록 했다.
|
||||
- 조사 목록과 단일 상세 집계표 헤더는 56px 규격으로 통일했다.
|
||||
- 결함표는 4단 복합 헤더이므로 전체 높이는 더 크지만 헤더 셀의 파란 배경·흰색 글자·가운데 정렬·패딩 토큰은 동일하게 적용했다.
|
||||
|
||||
## 4. 검증 중 보완한 내용
|
||||
|
||||
### 4.1 버튼과 입력 높이
|
||||
|
||||
- 지도 상단 공통 검색바의 25px 조회 버튼을 32px로 변경했다.
|
||||
- 침입수·RDII 화면의 상단 액션·조회·파일 선택 버튼을 32px로 통일했다.
|
||||
- 관로분석, 노후관로, 지반침하, 침수지도, 보수이력, 침수이력 등 분석 팝업의 주요 액션을 32px로 통일했다.
|
||||
- 공통 SelectBox와 지도 팝업에 남아 있던 35px 선택박스를 32px로 통일했다.
|
||||
- 페이지 번호, 표 셀 링크, 지도 확대·축소처럼 문맥상 소형이어야 하는 컨트롤은 기존 소형 규격을 유지했다.
|
||||
|
||||
### 4.2 로딩 구조
|
||||
|
||||
- 입력 화면은 전체 화면 `LoadingOverlay` 하나만 사용하도록 했다.
|
||||
- 목록 화면은 공통 표 로더 또는 전체 오버레이 중 하나만 사용하도록 정리했다.
|
||||
- 침입수·RDII 결과 목록의 최초 중복 조회 effect를 제거했다.
|
||||
- 정보검색, 조사 상세, 통수위험, 분석 결과 팝업의 중복 로딩 문구와 표 내부 스피너를 제거했다.
|
||||
|
||||
### 4.3 정보검색·분석도구 팝업
|
||||
|
||||
- `mapSearch`를 가용 화면 전체 크기로 열도록 하고 compact underline 탭을 적용했다.
|
||||
- 기본정보·유지관리·보고서 탭의 조회·초기화·엑셀다운로드·지도에서 보기 버튼을 통일했다.
|
||||
- 관로분석, 관로현황, 시도별 노후관로, GIS 관리, 통수위험, 침입수·RDII 결과 팝업을 재점검했다.
|
||||
- 통수위험 전용 표를 `MapPopupDataTable`로 변경해 공통 빈 상태·페이징·순번·가로 스크롤 규칙을 적용했다.
|
||||
|
||||
### 4.4 WindowPopup 취소와 GIS 편집세션
|
||||
|
||||
- `StandardPopupLayout`에 기본 흰색 `취소(window.close)` 액션을 추가했다.
|
||||
- 자체 저장·수정 보호 로직이 있는 팝업은 기본 취소를 끄고 기존 핸들러를 유지했다.
|
||||
- 정의된 33개 팝업 모두 공통 취소 또는 자체 취소 중 하나를 가지도록 점검했다.
|
||||
- GIS 편집세션 상단 패널을 레이어·현재 모드·변경 건수·되돌리기 액션 중심으로 재구성했다.
|
||||
- 지도 하단 편집툴바를 편집도구·스냅핑·`저장 → 취소` 그룹으로 정리했다.
|
||||
|
||||
### 4.5 준설관리
|
||||
|
||||
- 목록의 `상세보기` 기능을 제거하고 `수정` 기능만 유지했다.
|
||||
- 최종 액션은 `엑셀다운로드 → 등록 → 수정 → 삭제`이며 삭제는 빨간색 마지막 버튼이다.
|
||||
- 등록·수정 팝업의 32px 저장·취소, 사진·지도·직접등록 전환 흐름을 재확인했다.
|
||||
|
||||
### 4.6 최초 요청 SSR 500 오류
|
||||
|
||||
- 전체 본창·팝업의 최초 SSR 요청에서 `dynamic usage of require is not supported` 오류가 발생하는 문제를 확인했다.
|
||||
- 원인은 `business_components` Excel export 모듈이 `@xlsx/xlsx-populate`를 서버에서 즉시 평가하는 구조였다.
|
||||
- Excel 스타일 모듈을 사용자 다운로드 시점에 동적으로 로딩하도록 변경했다.
|
||||
- 변경 후 침입수·RDII 본창과 WindowPopup 33개의 최초 문서 요청이 HTTP 200으로 응답함을 확인했다.
|
||||
|
||||
## 5. 공통 컴포넌트 사용 구분
|
||||
|
||||
### 5.1 CS/공통 컴포넌트를 그대로 사용
|
||||
|
||||
- `Button`, `Input`, `Select`, 날짜·월 선택 컴포넌트
|
||||
- `Table`, `Dialog`, `AlertDialog`, `ConfirmDialog`
|
||||
- `card`, `card-border`, `card-header`
|
||||
- `StandardDataTable`, `StandardFormSection`, `StandardFormField`, `StandardPopupLayout`
|
||||
|
||||
### 5.2 업무 특성상 커스텀 유지
|
||||
|
||||
- 관로조사 결함 4단 복합 헤더
|
||||
- 관로분석 연도·재질 `rowSpan` 표
|
||||
- 도시침수·노후관로 Excel 가변 다중 탭
|
||||
- 준설 사진·EXIF·지도 위치 선택
|
||||
- GIS GeoPackage 업로드·미리보기와 지도 `postMessage`
|
||||
- 침입수·RDII 분석 차트
|
||||
|
||||
## 6. 수정 범위
|
||||
|
||||
- `apps/sn/**`
|
||||
- `packages/common/business_components/**`
|
||||
|
||||
다른 회사 코드인 `packages/common/components`와 타 앱은 수정하지 않았다.
|
||||
|
||||
## 7. 테스트 및 검증
|
||||
|
||||
- 브라우저에서 업무 본창 17개와 WindowPopup 33개를 확인했다.
|
||||
- 실제 조사사업 → 처리분구 → 관로조사 상세현황 흐름을 확인했다.
|
||||
- `node apps/sn/scripts/audit-screen-inventory.mjs` 결과 라우트 27개, 팝업 정의 33개, 레지스트리 33개, 누락 0개를 확인했다.
|
||||
- `tsc --noEmit --incremental false --ignoreDeprecations 5.0` 전체 검사를 통과했다.
|
||||
- 대상 파일 Prettier 검사를 통과했다.
|
||||
- `git diff --check -- apps/sn packages/common/business_components`를 통과했다.
|
||||
- 사용자 개발 서버를 보호하기 위해 Next production build는 실행하지 않았다.
|
||||
|
||||
## 8. 영향 범위
|
||||
|
||||
- API, DB, 요청·응답 구조와 저장 로직에는 영향이 없다.
|
||||
- `business_components`의 검색바·SelectBox 규격 변경은 해당 컴포넌트의 다른 소비 화면에 영향을 줄 수 있으므로 32px 공통 규격을 기준으로 적용했다.
|
||||
- Excel 모듈은 사용자 다운로드 시점에만 로딩되며 기존 다운로드 파일 생성 흐름은 유지한다.
|
||||
|
||||
## 9. 롤백 방법
|
||||
|
||||
- SN 각 화면의 32px Button·Select 및 로딩 구조 변경을 되돌린다.
|
||||
- `StandardPopupLayout` 기본 취소와 개별 팝업의 중복 방지 속성을 함께 되돌린다.
|
||||
- `business_components`의 검색바, SelectBox, Excel 동적 로딩 변경을 되돌린다.
|
||||
- 화면 인벤토리 스크립트와 일자별 검증 문서를 삭제한다.
|
||||
|
||||
## 10. 남은 리스크
|
||||
|
||||
- `floodPredictionMapPopup`은 원본 요구사항이 있으나 현재 안내용 placeholder다.
|
||||
- `gisEditPopup` 직접 URL은 placeholder이며 실제 GIS 편집은 지도 본창의 인라인 편집세션으로 동작한다.
|
||||
- 저장·삭제·업로드·분석 실행은 실제 데이터 변경을 피하기 위해 실행하지 않았다.
|
||||
- Next 개발 모드에서 Radix 자동 ID 관련 hydration 경고가 간헐적으로 발생하지만 화면 표시와 기능에는 영향이 없었다. Production build 검증은 사용자 개발 서버 보호 때문에 수행하지 않았다.
|
||||
@@ -0,0 +1,64 @@
|
||||
# SN CS 사용자 메시지 통일 구현기록
|
||||
|
||||
## 1. 작업 목적
|
||||
|
||||
- SN 일반 화면의 브라우저 기본 `window.alert`, `window.confirm`을 CS와 동일한 공통 알림·확인 대화상자 방식으로 통일한다.
|
||||
- 성공 메시지를 확인하기 전에 화면이나 팝업이 닫히지 않도록 후속 이동, 창 닫기, 선택 초기화는 공통 알림의 확인 콜백에서 수행한다.
|
||||
- 기존 API 요청·응답, 저장·삭제 조건과 DB 구조는 변경하지 않는다.
|
||||
|
||||
## 2. 적용 기준
|
||||
|
||||
- 알림은 SN 전역 Provider에 이미 마운트된 `AlertDialog`와 `useAlertStore(state => state.setMessage)`를 사용한다.
|
||||
- 사용자 의사 확인은 전역 `ConfirmDialog`와 `useConfirm()`의 `await confirm(message)`를 사용한다.
|
||||
- 별도 SN 업무 전용 래퍼나 신규 시각 컴포넌트는 만들지 않고 CS가 사용하는 것과 동일한 공통 UI 계약을 따른다.
|
||||
- 조회 오류나 편집 상태처럼 화면에 지속해서 보여야 하는 인라인 안내는 브라우저 기본 알림이 아니므로 유지한다.
|
||||
- 침입수·강우유입수 분석 실행 전 확인도 기존 `confirmToast` 대신 동일한 `ConfirmDialog`를 사용한다.
|
||||
|
||||
## 3. 적용 범위
|
||||
|
||||
- 조사관리, 조사사업 등록·결과 등록·상세 및 처리분구관리
|
||||
- 준설관리 목록·등록·상세·수정
|
||||
- 노후 하수관로 정비사업과 최종확정예산사업 팝업
|
||||
- 노후관로·도시침수 예방사업의 목록, 업로드 및 보고서 파일 팝업
|
||||
- 침입수·강우유입수 분석 접수, 파일 업로드, 결과 조회·삭제 및 분석 완료 감시
|
||||
- 공통 파일 업로드와 도시침수 예방사업 등록·상세·수정
|
||||
- 하수관망도 버튼에서 여는 WindowPopup 21종과 해당 팝업의 조회·검증·다운로드·팝업 차단 메시지
|
||||
- 하수관망도 시설물 상세창의 저장 확인·결과 메시지, 상류관로 조회와 조사보고서 팝업 진입 메시지
|
||||
|
||||
하수관망도의 지도 캔버스·레이어 UI 자체는 UI 통일 예외로 유지하되, 사용자가 추가로 지정한 지도 버튼의 WindowPopup 서비스와 그 진입 메시지는 이번 전환에 포함했다. 실행 화면이 아닌 `app/html` 시안은 제외했다.
|
||||
|
||||
## 4. 동작 보존
|
||||
|
||||
- 등록·수정·삭제 성공 후 목록 이동 또는 팝업 닫기는 사용자가 공통 알림의 `확인`을 누른 뒤 실행한다.
|
||||
- 삭제, 저장, 등록방식 변경과 미저장 변경 폐기는 공통 확인창에서 `확인`한 경우에만 기존 로직을 실행한다.
|
||||
- 로딩 상태, 버튼 비활성화, 목록 재조회, 부모창 `postMessage`, 분석 완료 감시 시작 조건은 기존 흐름을 유지한다.
|
||||
- 지도 버튼의 팝업 키·URL·크기·필수 파라미터와 부모창 연계는 기존 `openWindowPopup` 계약을 유지하고, 팝업 차단 안내만 공통 알림으로 교체한다.
|
||||
- 관로분석 상세 팝업의 두 진입점에도 팝업 차단 안내를 보완했으며 업무 조회 조건은 변경하지 않았다.
|
||||
|
||||
## 5. 검증 결과
|
||||
|
||||
- 로컬 브라우저에서 준설 등록의 필수값 검증 메시지가 CS형 공통 알림창과 `확인` 버튼으로 표시되는 것을 확인했다.
|
||||
- 처리분구 행을 수정한 뒤 저장했을 때 `변경사항을 저장하시겠습니까?` 공통 확인창과 `확인`, `취소` 버튼이 표시되는 것을 확인했다. 검증 입력은 `취소` 후 페이지를 다시 조회해 폐기했다.
|
||||
- 침입수 분석 실행 시 소요시간 안내가 `확인`, `취소` 공통 확인창으로 표시되고, 확인 후 필수 파일 누락 메시지가 공통 알림창으로 이어지는 것을 확인했다. 필수 파일이 없어 API 요청과 데이터 변경은 발생하지 않았다.
|
||||
- RDII 분석 실행에서도 동일한 소요시간 공통 확인창과 필수 파일 누락 공통 알림창이 이어지는 것을 확인했다. 공통 `BaseLayout` 적용으로 침입수와 RDII가 같은 메시지 계약을 사용한다.
|
||||
- 도시침수 예방사업의 파일 기반 목록에서 선택 없이 삭제했을 때와 등록 팝업에서 파일 없이 등록했을 때 CS 공통 알림창이 표시되는 것을 확인했다. 별도 사업정보 화면의 등록·수정 성공과 삭제 확인도 동일한 공통 훅을 사용하며, 지속 표시가 필요한 조회·업로드 상태는 인라인 안내로 유지한다.
|
||||
- 하수관망도 레이어의 `노후관로 > 목록보기` 버튼을 실제 클릭해 WindowPopup 실행 흐름을 확인했다. 별도 팝업 라우트에서도 노후관로 경과년도를 `0`으로 조회했을 때 CS 공통 알림창과 `확인` 버튼이 표시되는 것을 확인했다.
|
||||
- 하수관망도 `정보검색` WindowPopup에서 파일 다운로드를 실행했을 때 장시간 소요 안내가 CS 공통 확인창과 `확인`, `취소` 버튼으로 표시되는 것을 확인하고 `취소`했다. 데이터 다운로드나 저장 변경은 수행하지 않았다.
|
||||
- GIS 관리 WindowPopup을 직접 열어 공통 Provider가 적용된 독립 팝업 렌더링을 확인했다. 테스트 계정에 선택 가능한 관리기관이 없어 업로드 검증 메시지 조작은 수행하지 않았다.
|
||||
- `apps/sn/app/(with-base-layout)`와 `apps/sn/src`를 검색해 `window.alert`, `window.confirm`, `globalThis.alert`, `globalThis.confirm`이 남아 있지 않은 것을 확인했다.
|
||||
- 실제 하수관망도 `apps/sn/app/(map-layout)/map`과 지도에서 도달 가능한 WindowPopup 콘텐츠를 검색해 `window.alert`, `window.confirm`, `globalThis.alert`, `globalThis.confirm`, `confirmToast`, `react-hot-toast`가 남아 있지 않은 것을 확인했다.
|
||||
- `git diff --check`를 통과했다.
|
||||
- 전체 TypeScript 검사는 이번 메시지 변경 파일이 아닌 기존 하수관망도, 조사 API 타입, 공통 메뉴 경로 오류 때문에 완료되지 않았다. 사용자 개발 서버 보호를 위해 Next 빌드는 실행하지 않았다.
|
||||
|
||||
## 6. 영향 범위와 롤백
|
||||
|
||||
- 영향은 사용자 메시지 표시 방식과 확인 시점에 한정되며 백엔드 API와 DB 영향은 없다.
|
||||
- 롤백 시 각 화면의 `useAlertStore`, `useConfirm` 적용 부분과 성공 후 콜백 이동만 이전 호출 방식으로 되돌리면 된다.
|
||||
|
||||
## 7. 원본 확인
|
||||
|
||||
- `요구사항정의서.xlsx`의 기능 요구사항 및 추적표와 `화면설계서.pptx`를 `침입수`, `유입수`, `I/I` 기준으로 직접 확인했다.
|
||||
- 하수관망도 WindowPopup은 화면설계서 슬라이드 7~17의 `SN_MN010102~SN_MN010108`, `SFR-011-001~006` 및 슬라이드 23~25의 GIS 편집·업로드·조회 화면을 확인했다. 요구사항정의서 기능 요구사항 및 추적표의 `SFR-011-005~006`, `SFR-012-002~005`와 `PR-SN-025`, `PR-SN-030`을 대조했다.
|
||||
- 제공 원본에는 침입수 분석 실행 확인창의 표현 방식을 직접 지정한 화면이 없어, 이번 변경은 사용자의 CS UI 통일 지시에 따른 설계 보완으로 기록한다.
|
||||
- 원본은 하수관망도 버튼과 팝업의 업무 흐름을 정의하지만 메시지의 시각 표현 방식은 지정하지 않아, CS 공통 대화상자 적용은 사용자의 UI 통일 지시에 따른 설계 보완으로 기록한다.
|
||||
- 기존 분석 입력값, 파일 검증, 분석 접수, 결과 조회와 완료 감시 흐름은 변경하지 않았다.
|
||||
@@ -48,3 +48,94 @@
|
||||
- 지역 입력 행 제목을 `시군구 선택`에서 `시도,시군구 선택`으로 변경하고 필수 표시를 추가했다.
|
||||
- 저장 전 시도 선택 여부를 검증하며, 미선택 시 `시도는 필수입니다.`를 표시한다.
|
||||
- 시군구는 선택사항으로 유지하여 시도만 선택한 자료도 저장 요청할 수 있다.
|
||||
|
||||
## 2026-08-12 CS UI 기준 목록·입력 화면 전환
|
||||
|
||||
### 요구사항 추적
|
||||
|
||||
- 원본 화면설계서 슬라이드 8~9의 `SFR-011-001`, 화면 ID `SN_MN010102`와 요구사항정의서의 `SFR-011-001`~`SFR-011-004`를 재확인했다.
|
||||
- 원본은 지도 기반 노후관로 관리·현황과 점검 대상 그리드·Excel 다운로드를 다루며, Excel 기반 `노후 하수관로 정밀조사 및 정비사업 현황` 목록과 직접 일치하지 않는다.
|
||||
- 따라서 이번 변경은 원본 기능 요구사항의 신규 구현이 아니라, 사용자가 지정한 CS UI 기준을 기존 목록 기능에 적용한 `설계 보완`으로 구분한다.
|
||||
|
||||
### 구현 내용
|
||||
|
||||
- 검색 영역을 CS와 동일한 공통 `Label`, `Select`, `Input`, `Button` 조합과 카드 구조로 변경하고 `조회`, `초기화` 간격을 공통 `gap-2`로 통일했다.
|
||||
- 등록·최종확정예산사업·업로드·엑셀다운로드는 검색 영역에서 분리해 목록 카드 헤더 우측 액션으로 배치했다.
|
||||
- 22개 컬럼 목록을 공통 `DataTable` 기반 `StandardDataTable`로 교체하고, 컬럼별 실제 폭·정렬과 서버 페이징을 TanStack Table 상태에 연결했다.
|
||||
- `StandardDataTable`은 업무명에 종속되지 않는 공통 컴포넌트로 유지하며 화면별 가로·세로 스크롤 선택, 고정 헤더, 빈 상태, 목록 액션, 스크롤 영역 밖 페이징을 제공한다.
|
||||
- 이 화면은 서버가 10건씩 페이징하므로 내부 세로 스크롤은 사용하지 않고 가로 스크롤만 적용해 브라우저 세로 스크롤과 중복되지 않게 했다.
|
||||
- 공통 표가 실제 `scrollWidth > clientWidth`인지와 운영체제 스크롤바 높이를 측정하여, 가로 스크롤바가 있으면 그 높이만큼 페이징 상단 여백을 줄인다. 가로 스크롤이 없는 표는 CS 기본 24px 여백을 유지한다.
|
||||
- `StandardDataTable` 헤더는 컬럼 본문 정렬값과 분리해 항상 가운데 정렬하고, 사업명·비고·수치 등 본문 셀은 기존 컬럼별 좌·중·우 정렬을 유지한다.
|
||||
- SN 전체 일반 페이지의 flex 항목에 `min-width: 0`을 적용하여 넓은 표가 페이지 전체 폭을 확장하지 않고 그리드 내부에서만 가로 스크롤되게 했다. 지도 레이아웃에는 적용하지 않았다.
|
||||
- 기존 등록·수정 이동, 최종확정예산 팝업, Excel 업로드·다운로드, 검색조건·페이지 복귀 계약은 유지했다.
|
||||
- 목록 카드 제목은 메뉴명 뒤에 `목록`을 붙이는 규칙에 맞춰 `노후 하수관로 정비사업 목록`으로 변경했다.
|
||||
- 등록 및 상세·수정 화면은 공통 `Label`, `Input`, `Select`, `Textarea`, `Button`을 그대로 사용하고 `기본 정보`, `지역 및 일정`, `사업량`, `담당자 및 의견`의 네 구역으로 재구성했다.
|
||||
- 입력 구역은 화면 폭에 따라 1열·2열·3열로 반응하며, 데스크톱에서는 연관된 짧은 항목을 한 행에 2~3개 배치한다. 사업명·연락처는 두 칸, 부진사유·비고·공단 의견은 세 칸을 사용하여 빈 셀과 불필요한 세로 길이를 줄였다.
|
||||
- 사업코드·사업명·시도 필수 검증, 지역 연동, 숫자·연도·일자 처리, 등록·수정·삭제 API 계약은 변경하지 않았다.
|
||||
|
||||
### 영향 범위
|
||||
|
||||
- 현재 직접 전환한 업무 화면은 `/oper/obsltPplBiz` 목록과 `/oper/obsltPplBiz/register`, `/oper/obsltPplBiz/register/[id]` 등록·상세·수정 화면이다.
|
||||
- SN 일반 BaseLayout의 폭 수축 규칙은 다른 일반 페이지에도 적용되지만, 콘텐츠를 넓히지 않고 기존 flex overflow를 정상화하는 규칙만 추가했다.
|
||||
- `StandardDataTable`은 `business_components`에 두어 WR·DM·FO 등에서도 재사용할 수 있으며 SN 또는 노후하수관로 업무 분기는 포함하지 않았다. 다른 앱의 기존 화면 코드는 수정하지 않았다.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- 로컬 브라우저에서 실제 정밀조사 128건을 조회하고 첫 페이지 10행, `128`부터의 역순 번호를 확인했다.
|
||||
- 1,265px 문서 폭에서 문서 `scrollWidth`가 1,265px로 유지되고, 표 스크롤 영역은 `clientWidth 995px / scrollWidth 2,800px`로 내부 가로 스크롤되는 것을 확인했다.
|
||||
- 표의 10행은 `clientHeight 493px / scrollHeight 493px`로 내부 세로 스크롤 없이 자연 높이로 표시된다. 720px 브라우저 높이에서 문서 높이는 993px이므로 페이지 세로 이동은 브라우저 기본 스크롤만 사용함을 확인했다.
|
||||
- 노후 하수관로 표는 가로 스크롤바 높이 15px을 감지해 페이징 상단 여백을 9px로 보정하고, 마지막 행부터 페이징까지 총 24px을 유지함을 확인했다. 가로 스크롤이 없는 준설 목록은 기존 24px 여백과 총 24px 간격을 그대로 유지했다.
|
||||
- 페이징이 스크롤 컨테이너 바깥에 있고, 2페이지 이동 시 첫 번호 `118`, 1페이지·초기화 복귀 시 `128`로 조회되는 것을 확인했다.
|
||||
- 사업명 임시 입력 후 초기화하면 입력값이 비워지고 사업구분 `정밀조사`, 1페이지로 복귀함을 확인했다.
|
||||
- 첫 행 클릭 시 `/oper/obsltPplBiz/register/128`로 이동하는 기존 상세·수정 진입을 확인했다.
|
||||
- 등록 화면을 1,280px 폭에서 확인한 결과 기본 정보 3열·2행, 지역 및 일정 3열·3행, 사업량 3열·1행, 담당자 및 의견 3열·4행으로 배치되며 문서 가로 스크롤은 발생하지 않았다.
|
||||
- 빈 등록 화면에서 저장을 시도했을 때 API 저장 없이 `사업코드는 필수입니다.`, `사업명은 필수입니다.`, `시도는 필수입니다.`가 각 항목에 표시됨을 확인했다.
|
||||
- 상세·수정 화면에서 128번 자료의 사업구분, 사업코드, 사업명, 시도·시군구·환경청, 일정, 사업량, 담당자와 의견 값이 기존 데이터와 동일하게 로딩되고 `저장`, `목록`, `삭제` 버튼이 유지됨을 확인했다.
|
||||
- 목록 제목이 `노후 하수관로 정비사업 목록`으로 표시되고, 공통 표 헤더가 모두 가운데 정렬됨을 브라우저 계산 스타일로 확인했다.
|
||||
|
||||
## 2026-08-12 최종확정예산사업 팝업 UI·순번 통일
|
||||
|
||||
### 설계 구분
|
||||
|
||||
- 원본 요구사항정의서와 화면설계서에는 현재 Excel 기반 노후 하수관로 정비사업 및 최종확정예산사업 팝업과 직접 일치하는 화면이 없어 기존 통합설계와 사용자 지시에 따른 `설계 보완`으로 적용했다.
|
||||
|
||||
### 구현 내용
|
||||
|
||||
- 최종확정예산사업 WindowPopup의 구형 `SearchDiv`, `ListDiv`, `UiTable`을 공통 `StandardPopupLayout`, `StandardDataTable`, `Button`, `Input`, `Select` 구조로 교체했다.
|
||||
- 행정구역·사업 분류·년도·사업명 검색, 조회·초기화, 다중 선택·등록, Excel 다운로드와 부모창 완료 메시지 계약은 보존했다.
|
||||
- 행정구역·사업규모·총사업비·년차 사업비의 다단 헤더를 CS 기본 파란 헤더·흰 글씨·가운데 정렬로 통일했다.
|
||||
- 표 헤더는 `순번`으로 표시하고 전체 건수와 서버 페이지를 기준으로 내림차순 번호를 계산한다. 정렬 기능은 추가하지 않았다.
|
||||
- 백엔드 API, 저장 계약과 DB 구조는 변경하지 않았다.
|
||||
|
||||
### 검증 결과
|
||||
|
||||
- 로그인 브라우저에서 `/oper/obsltPplBiz`의 목록 헤더가 `순번`이며 첫 페이지가 `128`부터 내림차순으로 표시되는 것을 확인했다.
|
||||
- `/popup/cfmtnBgt?bizSe=정비사업`에서 조회 후 다단 헤더, 내부 가로 스크롤, 첫 페이지 `170`부터의 내림차순 번호와 2페이지 첫 번호 `160`을 확인했다.
|
||||
- 검색·초기화·등록 비활성 상태·Excel 다운로드 버튼과 10건 서버 페이징을 확인했다.
|
||||
- TypeScript 전체 검사는 이번 팝업 파일의 오류가 없음을 확인했으나 작업 범위 밖 기존 오류로 전체 명령은 실패했다. 개발 서버 보호를 위해 Next 빌드는 수행하지 않았다.
|
||||
|
||||
## 2026-08-12 SN 일반 화면 상단 헤더 고정 회귀 보완
|
||||
|
||||
- 넓은 표의 페이지 전체 가로 스크롤을 막기 위해 `sn-base-layout` 상위 요소에 적용했던 `overflow-x-hidden`이 공통 `Header`의 `sticky` 기준을 변경해, 세로 스크롤 시 헤더가 콘텐츠와 함께 올라가는 회귀를 확인했다.
|
||||
- 상위 레이아웃의 가로 넘침 처리를 스크롤 컨테이너를 만들지 않는 `overflow-x: clip`으로 변경했다.
|
||||
- flex 레이아웃에는 `min-width: 0`, `max-width: 100%`만 유지하고, 실제 다열 표의 좌우 이동은 `StandardDataTable` 내부 가로 스크롤이 계속 담당한다.
|
||||
- 브라우저에서 준설관리와 노후 하수관로 정비사업 화면을 최하단까지 이동한 뒤 헤더 위치가 `top: 0`으로 유지되는 것을 확인했다.
|
||||
- 노후 하수관로 화면의 문서 폭은 `clientWidth 1265px`, `scrollWidth 1265px`로 페이지 전체 가로 스크롤이 다시 생기지 않았음을 확인했다.
|
||||
- 하수관망도와 팝업 레이아웃, API·DB 계약은 변경하지 않았다.
|
||||
|
||||
## 2026-08-12 버튼 색상·문구·순서 통일
|
||||
|
||||
- 목록 검색은 `조회` 파란색, `초기화` 흰색 순서로 유지했다.
|
||||
- 목록 액션은 `엑셀다운로드 → 등록 → 최종확정예산사업 → 업로드` 순서로 정리하고 실행 동작은 파란색으로 통일했다.
|
||||
- 등록·상세/수정 화면은 `저장` 파란색, `취소` 흰색, `삭제` 빨간색 순서로 변경해 삭제가 항상 마지막에 오도록 했다.
|
||||
- 최종확정예산사업 팝업은 `조회 → 초기화`, 목록 액션은 `엑셀다운로드 → 등록` 순서를 적용했다.
|
||||
- 기존 Excel 업로드·다운로드, 등록·수정·삭제 기능과 비활성화 조건은 변경하지 않았다.
|
||||
|
||||
## 2026-08-13 최종확정예산사업 팝업 여백·검색 배치 보완
|
||||
|
||||
- 원본 화면설계서 슬라이드 8의 `SFR-011-001`, 요구사항정의서 추적표 87~90행의 `SFR-011-001`~`SFR-011-004`를 다시 확인했다. 원본에는 현재 최종확정예산사업 선택 팝업과 직접 일치하는 화면이 없어 기존 조회·선택·등록 계약을 유지한 `설계 보완`으로 처리했다.
|
||||
- 검색조건을 `환경청·시도·시군구·년도`와 `세부사업·내역사업·세부내역·사업명`의 4개씩 두 행으로 고정해 창 너비에 따라 임의로 끊기던 배치를 제거했다.
|
||||
- 팝업에서만 사용하던 25px 소형 버튼을 제거하고 조회·초기화·엑셀다운로드·등록을 CS 공통 32px 버튼 규격으로 통일했다.
|
||||
- 공통 팝업의 12px 간격과 중복되던 별도 여백을 제거하고, WindowPopup 크기를 `1400×720`으로 조정했다. 빈 목록은 목록 카드가 남은 세로 공간을 채우도록 해 카드 밖에 과도한 공백이 남지 않게 했다.
|
||||
- `StandardDataTable`에 팝업 전용 바깥 margin 제거 옵션을 추가해 이 팝업의 검색 카드와 목록 카드 좌우 기준선을 동일하게 맞췄다. 일반 페이지의 기존 카드 margin은 그대로 보존한다. 빈 목록은 남은 높이를 채우고, 조회 결과가 있으면 표의 자연 높이를 보존해 팝업 본문만 세로 이동하도록 공통 동작을 구분했다.
|
||||
- API, 조회조건, 다중선택, Excel 다운로드, 등록과 부모창 메시지 계약은 변경하지 않았다.
|
||||
|
||||
Reference in New Issue
Block a user