Leyve Docs

다크모드

프로퍼티 설정 페이지 프론트엔드 메인테이너 ​

라우트와 진입 ​

  • 라우트: /administration/organization/workspace/property
  • 유닛 목록: /administration/organization/workspace/property/console/unit
  • 진입: 본사 콘솔 /headquarters/console/office/general의 현장 마스터
  • 전제: useAccountContext().activeOffice가 상단에서 선택한 Office를 가리킨다.

컴포넌트 트리 ​

text
views/.../property/IndexView.vue
├─ HeaderOrg.vue  현재 Office 이름·코드·주소·호실 수·공공데이터 연결 상태
└─ MainOrg.vue
   ├─ 프로퍼티 기본정보 카드 (read ↔ inline edit)
   ├─ 공공데이터 연결 카드 (health → search → area preview → connect)
   └─ 다음: 부과항목 설정

초기 시안의 가짜 계정 usercode123, 라이선스 999, 샘플 현장, 목록 CRUD 오버레이는 제거했다. 이 화면은 목록이 아닌 현재 Office의 단일 정보 페이지다.

데이터 흐름 ​

  1. 로그인 후 loadCurrentCompanyAccount()가 Office와 property_* 컬럼을 읽는다.
  2. useAccountContext()가 현재 Office를 제공한다.
  3. resolvePropertyMasterRepo()가 Supabase 또는 테스트 mock 구현을 고른다.
  4. 기본정보 저장과 공공데이터 후보 연결은 update_company_office_property RPC를 호출한다.
  5. 공공데이터 조회는 인증된 property-public-data Edge Function에 { mode: 'search', name, address }를 보낸다.
  6. 성공 응답은 account.updateOfficeRecord()로 로컬 Office에 병합한다. 기존 상품 권한 배열은 보존한다.
  7. propertyUnitMaster가 propertyData.units[]를 동·호 기준 부과 유닛으로 정규화하며 부과항목 배분값과 첫 부과 준비 게이트가 함께 소비한다.
  8. 유닛 목록의 헤더와 표도 같은 useAccountContext().activeOffice와 usePropertyUnitMaster()를 소비한다. 별도 데모 행·999 카운트·현장명 접두어를 두지 않는다.

편집 패턴 ​

단일 정보 페이지 규칙에 따라 다른 시트로 이동하지 않고 카드가 제자리 필드폼으로 전환된다.

  • read: table-static
  • edit: field + input input-bordered
  • footer: 편집 ↔ 취소/저장
  • 저장 게이트: valid && dirty && !saving
  • 긴 설명: InfoHint

데스크톱과 모바일은 같은 1열 카드 흐름이다. 기본정보의 두 짧은 입력만 sm:grid-cols-2이고, 공공데이터 후보의 합계는 grid-cols-2 sm:grid-cols-3으로 전환한다. 면적 유형 표는 좁은 화면에서 overflow-auto로 가로 스크롤한다.

공공데이터 상태와 면적 UI ​

상태UI
health 확인 중상태 문구, 조회 버튼 비활성
Secret 미설정키 설정 필요 문구, 조회 버튼 비활성
조회 가능·미연결공공데이터에서 찾기
후보 있음건물명·주소·호실 수·A~E 합계와 연결 + 접힌 호실 목록 disclosure
호실 수 불일치등록 수와 대장 수 경고, 연결 비활성
연결됨출처·확인시각·A~E 합계·용도별 면적 유형 표와 다시 확인·호실 목록 보기

후보의 호실 목록은 candidate.snapshot.units[](동·층·호·용도·A 전용·E 계약)를 기본 접힘 disclosure(disclosure disclosure-sm) 안에 max-h-64 overflow-y-auto + sticky-thead 표로 보여준다 — 연결 전에 개별 호가 실제로 존재하는지 검증하는 용도다. 연결 후에는 카드에 표를 중복하지 않고 card-footer의 호실 목록 보기 버튼으로 정본 유닛 콘솔(…/property/console/unit)로 이동한다(대장 연결 linked일 때만 — MANUAL 직접 입력은 개별 호 데이터가 없다).

화면은 A 전용, B 주거공용, C 기타공용, D 공급(A+B), E 계약(A+B+C)을 모두 표시한다. 관리비 부과 기준은 A 또는 E만 사용하며 분양면적 파생값은 UI와 데이터 모델에 두지 않는다. 공용면적 용도가 명확하지 않은 호실 수는 경고 alert로 노출한다. 후보의 areaSummary는 비교용이고, 연결 후 정본은 activeOffice.propertyData.areaSummary, areaTypes, units다.

운영 UUID Office에서는 건축물대장 units[]가 없거나 그 수가 unitCount와 다르면 면적 유형 합계가 있어도 첫 부과 준비로 보지 않는다. 후보 단계에서도 candidateUnitCountMatches()가 등록 호실 수와 대장 호실 수를 비교해 불일치 연결을 막는다. 직접 입력 areaTypes[]를 임의의 1호…N호로 확장하지 않는다.

건축물대장 PK는 내부 연결 식별자이므로 후보와 연결 결과 UI에 표시하지 않는다. 긴 숫자의 문자열 보존은 Edge Function 정규화 테스트가 담당한다.

비밀키나 원문 오류는 UI에 노출하지 않는다. 법정동 누락과 코드 검색 실패는 사용자가 고칠 수 있는 문장으로 변환한다.

도움말과 테스트 ​

  • 도움말 topic: property-setting. /administration 범용 계정·보안 topic보다 먼저 매칭한다.
  • 단위 테스트:
    • src/composables/__tests__/propertyMasterRepo.spec.js
    • src/composables/__tests__/propertyUnitMaster.spec.js
    • src/composables/__tests__/propertyPublicDataNormalization.spec.js
    • src/components/administration/organization/workspace/property/propertyMaster.spec.js
    • src/components/administration/organization/workspace/property/console/unit/UnitPage.spec.js
    • src/composables/__tests__/useAccountContext.spec.js
  • 다음 단계 라우트: /service-charge/setting/item/general