feat(ui): apply inquiry list and modal design
Apply the supplied inquiry layout to the list and native write/detail dialogs while preserving existing API requests, author controls, attachments, comments and search. Keep legacy entry links and confirm before discarding drafts. Validation: 98 tests and syntax checks pass; mocked Chromium desktop/mobile and six author/session visibility scenarios pass.
This commit is contained in:
1 parent
dbf5dc3611
commit
c62630e22d
19 files changed
+1362
-277
No files matched your search
@@ -1,6 +1,8 @@
|
||||
# EG-BIM Q&A static pages
|
||||
|
||||
`egbim/` 아래의 `index.html`, `write.html`, `detail.html` 세 페이지로 구성한 EG-BIM Q&A UI입니다. 원본 `egbim_homepage`의 Q&A 화면 구성과 패키지 S/W 메뉴 방향을 참고해, PHP/그누보드/DB 의존성 없이 정적 호스팅에서 동작하도록 분리했습니다.
|
||||
`egbim/index.html`의 목록 위에 작성·상세 모달을 여는 EG-BIM Q&A UI입니다. `SW문의_소스패키지`의 히어로·제품 탭·목록·모달 디자인을 적용하고, 기존 첨부·댓글·비밀글·작성자 권한·검색을 유지합니다. 회사 홈페이지의 헤더·메뉴·푸터는 포함하지 않습니다. 기존 `write.html`, `detail.html?id=...` 주소는 같은 목록의 모달로 연결됩니다.
|
||||
|
||||
EG-BIM을 우선 제공하며 TOVA·GAIA는 준비중 탭입니다. 원격지원은 `https://939.co.kr/saman/`으로 열립니다. UI 적용 범위·검증·남은 배포 확인은 [작업 목록](docs/qa-inquiry-ui-redesign-tasks.md)에 정리했습니다.
|
||||
|
||||
로그인부터 글 저장까지의 화면·처리 전이맵은 [`docs/qa-login-to-save-transition.md`](docs/qa-login-to-save-transition.md)에 정리했습니다.
|
||||
|
||||
@@ -12,7 +14,7 @@
|
||||
python3 -m http.server 4173
|
||||
```
|
||||
|
||||
그 다음 `http://localhost:4173/egbim/`에 접속합니다. 브라우저 보안 정책 때문에 `file://` 직접 열기보다 정적 서버를 사용하는 편이 안전합니다.
|
||||
그 다음 `http://localhost:4173/egbim/`에 접속합니다. 정적 서버는 화면 배치 확인용이며 로그인과 저장 API를 제공하지 않습니다. 브라우저 보안 정책 때문에 `file://` 직접 열기보다 정적 서버를 사용하는 편이 안전합니다. 실제 서버 데이터를 변경하지 않는 모달 회귀 검증은 별도 Playwright 환경에서 `npm run test:ui`로 실행할 수 있습니다.
|
||||
|
||||
## feedback.hmac.kr DB 기준 연동
|
||||
|
||||
@@ -24,7 +26,7 @@ python3 -m http.server 4173
|
||||
- 신규 상태: `support_tickets.status_code = RECEIVED`, `feedback_status = NEW`
|
||||
- 첨부 저장소: `storage_bucket = qa_cdn`
|
||||
|
||||
작성 시 브라우저가 UUID를 하나 생성합니다. 같은 UUID를 `feedback.id`, `feedback.source_record_id`, `support_tickets.idempotency_key`에 사용하므로 중복 제출을 판별할 수 있습니다. API 서버는 envelope를 받아 다음 DB 레코드를 하나의 트랜잭션으로 생성해야 합니다.
|
||||
작성 시 브라우저가 기존 UUID v7 방식으로 `feedbackId`를 생성하고 같은 Worker의 `POST /api/feedbacks`에 전달합니다. API 서버의 저장 구조와 작성자·조직 매핑은 이번 UI 변경 범위에 포함하지 않습니다. 기존 저장 대상은 다음과 같습니다.
|
||||
|
||||
- `feedbacks`: `id`, `channel_id`, `source_namespace`, `source_record_id`, `data`
|
||||
- `support_tickets`: 작성자/테넌트/제목/내용/분류/상태/`idempotency_key`
|
||||
@@ -42,7 +44,7 @@ python3 -m http.server 4173
|
||||
## 연동 지점
|
||||
|
||||
- SSO: Q&A는 홈페이지 로그인 정보를 전달받지 않고, `https://sso.hmac.kr/oidc`에 등록된 독립적인 PKCE Public Client로 직접 인증합니다. callback은 `https://qa-test.baroncs.co.kr/auth/callback`이며, Worker가 검증한 claim을 버전이 지정된 HttpOnly 세션 쿠키에 저장합니다. 브라우저의 `GET /auth/session`은 Q&A 세션에 저장된 작성자 정보를 반환합니다. feedback 서버는 반드시 SSO 세션 또는 토큰을 서버 측에서 검증해야 합니다.
|
||||
- 작성자 식별자: `ssoSubject`/`requesterId`, `userUuid`, `tenantId`/`requesterTenantId`, `tenantIds`, `scope`, `roles`, 이메일·이름·부서·전화번호를 payload에 넣습니다. `requester_id`와 `requester_tenant_id`가 없으면 제출을 차단합니다.
|
||||
- 작성자 식별자: Worker가 검증한 세션의 `requesterId`와 `requesterTenantId`를 사용합니다. 브라우저는 회사·부서·이름·이메일을 읽기 전용으로 표시하고, 필수 UUID가 없으면 제출을 차단합니다. 서버가 요청의 작성자·조직 정보를 결정합니다.
|
||||
- API: 작성페이지는 같은 Worker의 `POST /api/feedbacks`를 호출합니다. Worker가 Q&A 세션 쿠키를 검증하고, SSO requester 정보와 `ABC_API_KEY` Secret을 추가한 뒤 `POST https://feedback.hmac.kr/api/projects/{projectId}/channels/{channelId}/feedbacks`로 전달합니다. API Key와 내부 ABC 주소는 브라우저에 노출하지 않습니다.
|
||||
- 첨부파일: 작성페이지가 `multipart/form-data`의 반복 `images` 필드로 파일을 Worker에 전달하고, Worker가 검증된 requester 정보와 API Key를 추가해 ABC API로 전달합니다. ABC API가 `qa_cdn` 저장소에 파일을 저장하므로 R2 access key/secret은 정적 페이지에 넣지 않습니다.
|
||||
- 텍스트만 등록할 때는 기존 JSON 요청을 사용하고, 파일이 있을 때만 multipart 요청을 사용합니다.
|
||||
@@ -99,7 +101,7 @@ Cloudflare API Token에는 최소한 다음 권한이 필요합니다.
|
||||
|
||||
`.gitea/workflows/deploy.yml`은 `main` push 또는 수동 실행 시 세션 secret을 Worker에 등록하고 R2 업로드 후 `baron-qa-gateway-test`를 배포합니다. 실제 secret 값은 로그에 출력하지 않습니다.
|
||||
|
||||
현재 화면은 API 설정 전에도 QA 흐름을 확인할 수 있도록 샘플 글과 로컬 테스트 저장을 포함합니다. 운영 배포 시에는 Gitea Secret `ABC_API_KEY`가 Worker에 등록되어야 하며, 작성페이지는 Worker 프록시를 통해 ABC API를 호출합니다.
|
||||
화면에는 디자인 목업의 예시 글·공지를 넣지 않습니다. 브라우저는 실제 Worker API를 호출하며 기존 localStorage는 조회·저장 결과의 캐시로 유지합니다. API 설정 전 로컬 저장 성공으로 대체하지 않습니다. 운영은 [production 파이프라인 안내](docs/qa-production-pipeline.md)의 `PROD_` 등록값과 기존 수동 배포 절차를 사용합니다.
|
||||
|
||||
|
||||
## 회사·부서 조직 연동 (스테이징)
|
||||
|
||||
Reference in new issue
Block a user