Benjamin Admin
a616b64273
CI / detect-changes (push) Successful in 10s
CI / guardrail-integrity (push) Has been skipped
CI / branch-name (push) Has been skipped
CI / sbom-scan (push) Has been skipped
CI / validate-canonical-controls (push) Successful in 14s
CI / loc-budget (push) Failing after 19s
CI / go-lint (push) Has been skipped
CI / python-lint (push) Has been skipped
CI / nodejs-lint (push) Has been skipped
CI / secret-scan (push) Has been skipped
CI / dep-audit (push) Has been skipped
CI / test-go (push) Successful in 47s
CI / nodejs-build (push) Successful in 2m46s
CI / iace-gt-coverage (push) Successful in 28s
CI / test-python-backend (push) Has been skipped
CI / test-python-document-crawler (push) Has been skipped
CI / test-python-dsms-gateway (push) Has been skipped
[migration-approved] Task #22. The IACE module is used by a single Maschinenhersteller, but their plants land at many different end customers. When the safety expert commissions the second or third plant at the same customer, whole classes of mitigations (company-wide PPE rules, locked-out energy isolation, customer-standard signage) are already in place there — but rediscovered from scratch every project. Migration 031: iace_projects.customer_name TEXT + partial index. The customer is stored as a plain text field rather than a normalised iace_customers table (option A from the design discussion). A proper customer-management screen can promote this to a FK later without data loss. Backend store_customer_standards.go: - ListCustomerStandardSuggestions(projectID, includeVerified) collects mitigations from all non-archived prior projects sharing the same tenant_id AND case-insensitive customer_name. Aggregates by mitigation.name (since same-named measures from different prior projects collapse into one suggestion) and surfaces: • source_project_count + source_project_names • is_customer_standard / has_verified_instances flags includeVerified=false → strictly is_customer_standard=true includeVerified=true → also status='verified' - ImportCustomerStandardSuggestion(projectID, name): for every prior (mitigation.name → hazard.name) pairing, finds matching hazards in the current project (by name) and ensures a customer-standard mitigation exists. New rows via CreateMitigation (idempotent through the UNIQUE(hazard_id, name) from migration 030); existing rows are flipped to is_relevant=true + is_customer_standard=true + status='verified' via UPDATE. Routes: GET /api/v1/iace/projects/:id/customer-standards?include_verified= POST /api/v1/iace/projects/:id/customer-standards/import body {name} Frontend: - New page /sdk/iace/[projectId]/customer-standards with: • empty-state hint pointing to Auftrag → Kundenname • per-suggestion checkbox + per-row Übernehmen button • bulk "N übernehmen" button • toggle "Auch verifizierte einbeziehen" widening the pool • per-suggestion source_project_count + status badges - Sidebar item "Kundenstandards" (building icon) placed between Verifikation and Nachweise. - Order-page now mirrors Auftraggeber.Firmenname into the top-level customer_name column on save, so the Reuse feature is fed automatically without a separate input field. The same expert effect from migration 029's is_customer_standard flag — "I already know it's covered, no evidence needed" — now becomes a cross-project asset rather than a per-project annotation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
28 lines
1.4 KiB
SQL
28 lines
1.4 KiB
SQL
-- Migration 031: customer_name on iace_projects + reuse-helper index
|
|
-- ==========================================================================
|
|
-- The IACE module is operated by a single Maschinenhersteller (the SDK
|
|
-- user), but their plants land at many different end customers. A safety
|
|
-- expert who commissions the second or third plant at the same customer
|
|
-- often finds that whole classes of mitigations are already in place
|
|
-- there (company-wide PPE rules, locked-out energy isolation, customer-
|
|
-- standard signage, etc.). Today, this expert knowledge is rediscovered
|
|
-- per project.
|
|
--
|
|
-- This migration introduces a plain customer_name field on the project
|
|
-- (no separate customer table yet — Option A from the design discussion;
|
|
-- normalised iace_customers can come later when a real customer-management
|
|
-- screen is built). The field is optional so existing projects without a
|
|
-- customer remain valid.
|
|
--
|
|
-- The partial index makes the customer-standards lookup cheap: only
|
|
-- projects with a non-empty customer_name participate, since reuse is
|
|
-- meaningless without it.
|
|
-- ==========================================================================
|
|
|
|
ALTER TABLE iace_projects
|
|
ADD COLUMN IF NOT EXISTS customer_name TEXT;
|
|
|
|
CREATE INDEX IF NOT EXISTS idx_iace_projects_customer_name
|
|
ON iace_projects(customer_name)
|
|
WHERE customer_name IS NOT NULL AND customer_name <> '';
|