Statuses
- Migration 006: card_statuses table (project-scoped) and cards.status_id, a
nullable FK with ON DELETE SET NULL. Every new project is seeded with
"To do" / "Doing" / "Done"; GET /api/projects/{id}/statuses lists them.
- New cards have no status -- they sit in an "inbox" until moved.
Project view
- Full-width and tabbed: "All tasks" (a flat list, sorted by name
case-insensitively) and "Kanban" (Inbox plus one column per status).
- Drag a card within or between columns to reorder / restatus; the Inbox
column has its own name + Add form.
Ordering
- Migration 007: `position` is now a dense 0..n-1 rank within a
(project_id, status_id) column, not a project-wide order. New composite
index idx_cards_project_status_position; existing rows re-ranked.
- PUT /api/projects/{id}/cards/order takes { status_id, card_ids } and sets one
column's contents and order, re-parenting moved-in cards and re-packing their
source column in a single transaction. PATCH status_id appends the card to the
end of the destination column.
58 phpunit tests pass; the frontend type-checks and builds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.9 KiB
Project Manager — web
Vue 3 + TypeScript + Vite PWA. Talks to the REST API in the parent directory.
Develop
npm install
npm run dev # http://localhost:5173
The dev server proxies /api to http://localhost:8080 (the Dockerised API —
run docker compose up -d in the parent directory first). Override the target
with VITE_PROXY_TARGET, or point the app at a different API entirely with
VITE_API_BASE_URL (see .env.example).
Build
npm run build # type-checks, then emits dist/
npm run preview
The parent Dockerfile runs this build in a Node stage and copies dist/ into
the PHP image's public/, so the app container serves the compiled SPA at /.
There is no separate frontend container — a production image is docker compose build app from the parent directory.
Layout
src/main.ts App bootstrap; resolves the stored session before mount
src/router/index.ts Routes + guard (redirects to /login when unauthenticated)
src/stores/auth.ts Pinia store: token in localStorage, register/login/fetchMe
src/stores/projects.ts Pinia store: the user's projects (fetch + create)
src/stores/cards.ts Pinia store: one project's cards (CRUD + reorderColumn)
src/lib/api.ts fetch wrapper, bearer token, typed ApiError
src/components/CardRow.vue editable text + status chip + delete, one card
src/components/KanbanCard.vue small draggable card for the board columns
src/views/ HomeView, ProjectView, LoginView, RegisterView,
ProfileView, VerifyEmailView
Project detail
/projects/:id shows one project. It renders on a full-width layout (the
route sets meta.wide, which widens .app__main in App.vue). The title and
description are inline-editable (saved on blur via PATCH /api/projects/:id; the
description shows an "Add a description" placeholder when empty). A Manage
menu (top right) has a Delete project action that opens a confirmation modal;
confirming calls DELETE /api/projects/:id and returns to the all-projects view.
Below the header are two tabs (local activeTab state, v-show so both stay
mounted):
All tasks
The flat card list, sorted by name (case-insensitive) via a sortedCards
computed — there is no manual order here. Each row is an inline-editable text
field (saved on blur), a status chip (card.status.name or "No status"), and a
delete button.
Kanban
Columns, left to right: Inbox (cards with no status) then each project
status in position order. board is derived from cards.cards + the
project's statuses and rebuilt by a watch whenever either changes.
Every drop — whether reordering within a column (moved) or dragging in from
another (added) — calls cards.reorderColumn(column.statusId, ids) →
PUT /api/projects/:id/cards/order with { status_id, card_ids }. The server
re-parents any moved-in card, re-packs the source column, and returns the whole
project's cards, which replaces local state; on failure the board reloads.
The Inbox column has a small name + Add form at the bottom (cards.add);
new cards have no status, so they land straight in it.
Auth flow
- The token from register / login / opening a magic link is kept in
localStorageand sent asAuthorization: Bearer …. - On load,
fetchMe()validates the stored token viaGET /api/me; a failure clears it. - Routes with
meta.requiresAuthredirect to/login(preserving the intended path) when there is no authenticated user. - Registration signs the user in immediately; the new account's email is
unverified (
user.email_verified === false). The header shows a "verify email" badge linking to/profile. LoginViewdefaults to magic link: an email field and a "Log in with email" button that callsPOST /api/auth/magic-link. A "Log in with password" link reveals the password field and switches the button to a plain "Log in" (POST /api/auth/login); the link then reads "Get a magic link" to switch back.
Email verification & profile
/verify-email?token=…is the target for every magic link (verification, passwordless login, email change).VerifyEmailViewPOSTs the token to the API, which returns a session — so opening any link both verifies the address and signs the user in — then redirects to the projects./profile(ProfileView) shows the address and verification status. When unverified it offers a Resend button; the API throttles to once a minute, and the button shows a live countdown (driven byretry_after, and by429responses).- The Change email form takes the new address and the current password.
On success the API has emailed a confirmation link to the new address and
set
user.pending_email; the change only lands when that link is opened. The resend and change actions share the one-minute cooldown.