Implements tester feedback against API Q1 §5.9.1.2 / §6.4.2:
- Root Cause field + 6M Root Cause Category lookup (Man/Machine/Method/
Material/Measurement/Environment), separate from Deviation Detail/Category
- "Corrective Action Required?" Yes/No gate on every NCR with a required
justification
- Corrective action plan with owner + due date; owner is notified by email
- Effectiveness verification (result, notes, server-stamped verifier/date)
required before an NCR can close when corrective action is required —
costing returns 409 listing the missing pieces
- Recurring-issue flag with bidirectional NCR-to-NCR links; prior NCRs show
a warning when later NCRs reference them
- Dashboard metrics: % root cause completed, % CAPA verified effective,
avg CAPA close time, overdue CAPA count, NCRs by root cause category
- CAPA section in the NCR detail UI, printable PDF, CSV export, and the
vw_ncr_full Power BI view; admin list manager for root cause categories
- Migrations 0003 (schema + seeded 6M lookup) and 0004 (view refresh);
demo seed data exercises every metric
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Detail routes, queue navigation, and notification email links now use the
business identifier instead of the database id — friendlier for end users
quoting NCR numbers. The API resolves both forms (case-insensitive number,
or legacy numeric id) so existing bookmarks and email links keep working.
Adds regression tests incl. a guard that /ncrs/export.csv isn't shadowed
by the path parameter.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The MUI Tooltip stayed anchored while the Select menu was open (the select
keeps focus) and overlapped the first user options. Use a native title
attribute instead, which browsers suppress while the popup is open.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Passing the DB URL through config.set_main_option() runs it through
ConfigParser, which treats '%' as interpolation syntax — so any password
character that URL-encodes to %xx ('!', '@', '#', ...) crashed migrations
('invalid interpolation syntax'). Build the engine directly from the URL
instead of routing it through the ini config.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Oracle Linux based mysql:8.4 image requires x86-64-v2 and fails on the
PESCO Docker host even with the Proxmox CPU type set to host. The Debian
build runs on baseline x86-64; MYSQL_IMAGE still allows overriding.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mysql:8.4 (Oracle Linux 9 build) aborts with 'Fatal glibc error: CPU does
not support x86-64-v2' on generic VM CPU types (kvm64/qemu64) and pre-2009
hardware. MYSQL_IMAGE env var (default mysql:8.4) lets such hosts run the
baseline-x86-64 mysql:8.0-debian build instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Without the exec bit the MySQL entrypoint sources the script instead of
executing it, leaking set -euo pipefail into MySQL's own startup shell and
aborting first-time initialization (container exits -> unhealthy -> compose
dependency failure).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
