boha_admin/app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 26 Wiki Activity

fix(warehouse): add migration for warehouse permissions

Browse Source 
The warehouse module v1.8.0 deploy created the warehouse tables via Prisma
migration but left the corresponding permissions (warehouse.view/operate/
manage/inventory) and admin role assignments un-inserted, because those
rows only existed in prisma/seed.ts, which is dev-only and cannot be run
against production.

This migration inserts the same 4 permissions seed.ts would (with
identical display_name and description) and assigns them to the admin
role. INSERT IGNORE makes it idempotent and preserves existing role
assignments. No data is modified or deleted.

Also strengthens CLAUDE.md: every database change or manipulation must
be a tracked Prisma migration. No external SQL, no seed-only data,
no manual fixes — reviewable, reversible, reproducible from a fresh
checkout.
This commit is contained in:
BOHA
2026-06-03 23:26:34 +02:00
parent 5233db2002
commit 652e3f91fc
2 changed files with 48 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
CLAUDE.md
View File

@@ -289,6 +289,23 @@ When entity A embeds/references entity B, A's mutation handlers invalidate B's d
**Golden rule: NEVER use `prisma db push`.** It bypasses migration history and causes drift
between the schema and migration tracking. Always use `prisma migrate dev` for every schema change.
**Every database change or manipulation must be a tracked Prisma migration.** This includes:
- Schema changes (tables, columns, indexes, constraints) — via `prisma migrate dev`
- Permission/role/seed data changes — via a migration that does the INSERTs/DELETEs explicitly
- Lookup data, default settings, or any other row-level baseline that production needs
- Backfills, data fixes, and one-shot corrections that should be in sync across environments
**What is NOT acceptable:**
- Running raw SQL against production (`mysql -e "..."`, `npx prisma db execute`, `pm2 exec`)
- `npx prisma db seed` as the only way to populate data (seed is dev-only convenience; prod must run the same SQL via a migration)
- "I'll fix it in the seed file" or "I'll add a row manually" without a migration to back it
The reason: every change to the production database must be reviewable, reversible, and reproducible from a fresh checkout. External SQL commands and seed-only changes cause drift — prod and dev diverge, rollback gets harder with every manual change, and the next deploy surprises us.
If you need to insert/update/seed data on production, write a migration. The migration's `migration.sql` is a normal SQL file — `INSERT INTO ...`, `UPDATE ...`, `DELETE ...` are all valid. Prisma will run it via `prisma migrate deploy` like any other migration.
### Making schema changes
```
@@ -369,6 +386,8 @@ npx prisma migrate resolve --applied <migration_name>
10. **Czech locale hardcoded** — Error messages, month names, and some business logic strings are Czech. This is intentional.
11. **Seed file is dev-only** — `prisma/seed.ts` is for local dev convenience. It is **not** the production data source. Any data the production database must have (permissions, default roles, baseline rows) belongs in a migration's `migration.sql`, not in the seed file. `npx prisma db seed` must never be run against production.
---
## Release Process