6b1f4c483f
프로젝트 8개 차원 감사(종합 82/100)에서 확정된 상위 3건 수정. 1. 개선 조치(move_actions)가 유일하게 site 스코프 규율에서 이탈 — 스코프 운영자가 타 현장의 조치 기록(카메라 ID·메모·작성자)을 목록에서 읽고, 타 현장 카메라에 조치를 기록해 그 현장 리포트의 전후 효과 지표를 오염시킬 수 있었다. - move_actions.site 컬럼 + (site, taken_at) 인덱스, 기존 행 백필 마이그레이션 - 카메라 소유 현장은 이벤트에서 해석 (move_cameras는 등록 플로우가 없어 항상 비어 있음) - 오타 카메라는 400: 전후 효과가 영원히 0/0이 되는 조치를 애초에 못 만들게 한다 - 타 현장 카메라는 404: 존재 여부를 숨기는 기존 규약 유지 2. README-UPLOAD 업그레이드 절차가 마이그레이션 7종 중 1종만 지시했다. move_ 접두 리네임을 건너뛰면 이후 전부 실패하고 전 요청이 500이 된다 — 순서·적용조건·재실행 비안전성을 표로 명시. 문서 4곳의 테이블 수(10→11)·비프리픽스 표기도 정정. 3. 두 납품 번들 재생성: 8/6 이후 4개 기능 커밋이 반영되지 않아 Report/Export/Actions 컨트롤러와 8/7 마이그레이션이 빠진 채였다. 엣지 소스 패리티도 회복. 검증: pytest 235 passed / PHPUnit 147 passed (PDO 4 skip), 번들 산출물 내부 검증 (28 클래스 해석·전 파일 php -l·SHA256SUMS 55행·휠 11개·HEF 다이제스트 일치).
22 lines
1.2 KiB
SQL
22 lines
1.2 KiB
SQL
-- 개선 조치(move_actions)에 site 스코프 추가.
|
|
-- 이 표만 site 컬럼 없이 추가되어, 스코프 운영자가 타 현장의 조치 기록(카메라 ID·메모·
|
|
-- 작성자)을 목록에서 그대로 읽을 수 있었다. 다른 표(events/devices/zones)와 동일하게
|
|
-- site 를 비정규화해 SQL 단계에서 걸러낸다.
|
|
--
|
|
-- 적용 조건: 2026-08-07-improvement-actions.sql 이후.
|
|
|
|
ALTER TABLE move_actions
|
|
ADD COLUMN site VARCHAR(64) NULL AFTER camera_id,
|
|
ADD KEY ix_actions_site_taken (site, taken_at);
|
|
|
|
-- 기존 행 백필: 조치가 달린 카메라가 이벤트를 남긴 현장을 그 조치의 현장으로 본다.
|
|
-- (카메라는 별도 등록 표가 없고 events.site 가 유일한 소유 근거다.)
|
|
UPDATE move_actions a
|
|
SET a.site = (SELECT e.site FROM move_events e
|
|
WHERE e.camera_id = a.camera_id AND e.site IS NOT NULL
|
|
ORDER BY e.event_id DESC LIMIT 1)
|
|
WHERE a.site IS NULL;
|
|
|
|
-- 검증: site 가 채워졌는지 확인한다. NULL 로 남은 행은 해당 카메라의 이벤트가 없거나
|
|
-- 현장 미지정(devices.site IS NULL)인 경우로, 전역 관리자에게만 보인다.
|
|
-- SELECT site, COUNT(*) FROM move_actions GROUP BY site;
|