Site Configuration
호스트가 소유하는 선언적 설정 계층 — group·section·item을 어떻게 등록하고, 값이 어디에 저장되며, Shell 어디에 노출되는지.
Site Configuration
App에서 업무 시간대를 읽을 때는 App SDK 사용하기의 Nexia\Tenancy\Contracts\TenantSettings를 사용하세요. App 고유 설정은 설정 페이지 추가로 만듭니다. 아래 레지스트리는 호스트 전용이며 운영자는 필요한 테넌트 권한으로 기존 설정 화면을 편집합니다.
개요
Site Configuration은 평범한 스칼라 테넌트 설정을 위한 호스트 소유 경로입니다.
정적 레지스트리 하나, App\Settings\SiteConfigRegistry가 부팅 중에 세 단계
선언 — group → section → item — 을 받고, 그 선언 이후는 전부 제네릭합니다.
렌더링과 권한 방출, 영속화가 모두 등록된 메타데이터에서 파생됩니다.
| 단계 | 등록 방법 | 담는 것 |
|---|---|---|
| Group | registerConfigGroup() | 점 표기 키(platform.security), 정렬, 아이콘, 제목, 영역, surface, 읽기·수정 권한 키 |
| Section | registerConfigSection() | 그룹 안에서의 제목 |
| Item | registerConfigItem() | 타입(text, number, toggle, select, …), 기본값, 항목별 권한(선택) |
값은 테넌트 site_configs 테이블에 (key, scope)당 한 행으로 저장되고,
SiteConfig::valueFor()로 다시 읽습니다.
구조 속 위치
boot() 호출과 렌더링된 컨트롤 사이를 다섯 단계가 잇습니다.
- 등록. 서비스 프로바이더가 group과 section, item을 선언합니다.
SiteConfigRegistry::registerConfigGroup('platform.approval', 170, [
'icon' => 'stamp',
'area' => 'tenant',
'surface' => 'work-management',
'permission' => 'tenant.settings.read',
'update_permission' => 'tenant.settings.update',
]);
SiteConfigRegistry::registerConfigSection('platform.approval', 'line_presets');
SiteConfigRegistry::registerConfigItem(
'platform.approval',
'max_line_presets',
type: 'number',
default: 20,
sectionKey: 'line_presets',
);코드에는 label을 두지 않습니다. label은 등록 키에서 관례적으로 파생되는 locale catalog의 키에 있고, 요청 시 locale별로 해석됩니다.
"site-configuration.groups.approval.label": "결재 정책",
"site-configuration.groups.line_presets.label": "결재선 프리셋",
"site-configuration.items.max_line_presets.label": "사용자별 프리셋 한도"inline 'title' => __(...) metadata는 label이 site-configuration.*
prefix에 없는 group의 fallback일 뿐입니다. 관례 키가 있으면 metadata는
무시됩니다.
- 조립.
TenantSiteConfigurationCatalog::build()가 등록된 그룹을 돌며SiteConfig::valueFor()로 현재 값을 읽어groups → sections → items페이로드를 반환합니다. 테넌트 이름과 심볼 같은 정체성 필드는 같은 카탈로그가 직접 조합합니다. - 렌더링.
SettingsConfigRenderer가 그 페이로드를 선택된 설정 화면에서 제네릭하게 그립니다 — 초안 상태, itemtype별 컨트롤, 파일 미리보기, 저장 버튼. 데이터 조회도 권한도 도메인 규칙도 소유하지 않습니다. - 인가.
SiteConfigPermissionAdapter가 등록된 모든permission과update_permission키를 걸어 권한 정의로 방출하므로,nexia-access:sync-permissions가 설정 키를 설정별 권한 클래스 없이 카탈로그에 올립니다. - 영속화. 저장하면 키마다
site_configs행 하나가 쓰입니다. 모델은 검증을 갖지 않습니다 — 등록된 타입과 소비하는 컨트롤러가 쓰기 형태를 소유합니다.
카탈로그는 기본값이 site-configuration인 surface 구분자를 포함합니다. 위 Approval 그룹은 work-management를 명시하므로 /settings/work-management에 표시됩니다. 그룹 등록이 내비게이션 목적지를 만드는 것은 아닙니다.
경계
평범한 값 전용입니다. 제네릭 경로는 tenant.settings.read/update로
게이트되는 부수효과 없는 스칼라 값에 맞습니다. 자기만의 권한 네임스페이스,
감사 이벤트, 제네릭하지 않은 검증, 컬렉션 모양 데이터가 필요한 설정은 자기
카탈로그와 Surface를 갖습니다 — TenantSecurityPolicyCatalog는 같은
site_configs 테이블에 저장하지만 tenant.security_policy.* 권한과 자기
라우트, auth.security_policy.changed 이벤트를 소유합니다.
등록은 내비게이션이 아닙니다. 레지스트리는 Site Configuration
페이로드를 채우고, Settings Menu 구조는 shell.settings 컨텍스트의 목적지
기여에서 옵니다. group_id가 사용자에게 보이는 영역을, subgroup_id가
접히는 하위 그룹을 고릅니다.
사례
Settings → Site Configuration에서 보는 테넌트 브랜딩이 이 체인 전체가 한
화면에 모인 예입니다. platform.tenant가 기본 로케일과 기본 업무 타임존을
등록된 item으로 나르고, 정체성 섹션은 테넌트 이름과 회사, 연락처,
symbol_url — 정사각 PNG로 제한된 file item — 을
TenantSiteConfigurationCatalog가 직접 조합합니다.
tenant.settings.update 권한을 가진 관리자가
/settings/site-configuration을 열어 새 심볼을 올리고 저장합니다. 렌더러가
site-configuration API로 보내고, 값은 site_configs 행
(platform.tenant.default_locale)이나 테넌트 컬럼(정체성 필드)에 남으며,
테넌트 심볼을 읽는 모든 화면 — 로그인 페이지, Shell 사이드바 — 이 다음
요청에서 새 값을 읽습니다.