David/kanban-dev-webapp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kanban-dev-webapp/pocketbase/pb_migrations
History
Dave b3aac9ba4f feat(plan): Plan Puzzle v1 backend — proposal fields, server actions, Done-column guards 
Adds the three proposal fields (proposed_target_date, proposed_by,
proposed_at) to the cards collection with a partial index that backs
the 'pending proposals' query, plus two new ActivityAction values
(date_proposed, date_proposal_resolved) and column_changed for
return-to-scheduled.

New server actions under src/app/actions/:
  - client-proposal.ts: client-manager drag creates a proposal (not
    a target_date write); 404 (not 403) on cross-tenant failures and
    Done-column cards, matching the rest of /api/client/*.
  - owner-plan.ts: accept and dismiss clear the three proposal
    fields together and emit the audit rows; returnToScheduledAction
    moves a Done card back to the first working column.

Server-side Done-column guards added to:
  - src/app/actions/reschedule.ts (was UI-only)
  - src/app/api/client/cards/[id]/route.ts (was UI-only)

Both pass through the new writeCardWithAudit helper at
src/lib/cards/write-with-audit.ts — single source of truth for
'patch card + emit activity rows', replacing the inline copies in
the PATCH route and rescheduleCardAction.

Adds src/lib/roadmap/slot-date.ts (slot <-> target_date mapping)
consumed by Pixel's puzzle UI; named SlotId API rather than the
plan's numeric indices for self-documenting callers.

CLIENT_EDITABLE_CARD_FIELDS stays at priority + target_date per
the brief; proposals go through the dedicated action so they get
their own audit row type.
2026-09-19 18:35:33 +02:00
..
1789600100_created_clients.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600200_created_projects.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600300_extended_users.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600400_created_columns.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600500_created_cards.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600600_created_subtasks_comments.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600700_created_activity.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600800_created_settings.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789600900_applied_api_rules.js feat(schema): all collections + role-scoped API rules on remote PB 2026-09-16 09:41:20 +02:00
1789601000_locked_user_rules.js fix(security): lock the users collection against privilege escalation 2026-09-16 11:18:13 +02:00
1789601100_added_user_active.js feat(users): active flag, backfilled, enforced at sign-in 2026-09-16 11:26:16 +02:00
1789601200_added_card_proposals.js feat(plan): Plan Puzzle v1 backend — proposal fields, server actions, Done-column guards 2026-09-19 18:35:33 +02:00
README.md docs: Coolify-only setup, and mark pb_migrations as non-executing 2026-09-16 10:32:26 +02:00

README.md

These migrations never run

PocketBase applies files in pb_migrations/ when its own server starts. This project does not start a PocketBase server — it uses one hosted instance on Coolify, and the schema is applied to it over the admin API by scripts/setup-remote.ts.

So every file in this directory is reference only. Editing one changes nothing, anywhere.

To change the schema, edit scripts/setup-remote.ts and run npm run setup-remote.

These files are kept because they are the most readable statement of the schema and its reasoning, and because they are what you would mount into the container if this project ever moves to PocketBase's native migration flow. If you update setup-remote.ts, update these too — but understand that doing so is documentation, not deployment.