Enable editing Updates from the UI

[giomajo]

• Summary: Add UI and backend support so users can edit an existing Update record from the frontend (inline modal or dialog). Implement a backend edit endpoint, a small Pydantic schema for update payloads, a frontend API wrapper, and a lightweight edit UI that calls the API and updates local state.

• Why: Currently the app only supports listing and creating Update entries. Making updates editable improves UX and enables corrections and small adjustments without DB/back-office intervention.

• Scope

  • Backend: add PATCH/PUT endpoint and schema to edit Update.
  • DB: apply minimal changes if needed (optional updated_at column).
  • Frontend: add API method and a small UpdateEditDialog plus an 'Edit' control on each update card.
  • Tests: backend integration test; frontend unit test for API wrapper and component.

• Files to update

  • Backend router: updates.py — add PATCH /updates/{update_id} (or PUT) handler.
  • Backend schemas: update.py — add UpdateUpdate schema (fields optional: text?: str, task_id?: int).
  • Backend models/CRUD: update.py — ensure fields can be updated; add updated_at column if desired.
  • Frontend API client: api.ts — add updateUpdate(updateId, payload) calling PATCH /api/updates/{id}.
  • Frontend UI: ProjectCard.tsx — render an 'Edit' button per update; create new file frontend/src/components/UpdateEditDialog.tsx for modal editing.
  • Top-level wiring: App.tsx or MainSection.tsx — implement state update after successful API call.

• Backend implementation notes

  • Add schema:
    • UpdateUpdate Pydantic model with optional fields (e.g., text: Optional[str] = None, task_id: Optional[int] = None).
  • Add route handler in updates.py:
    • Route: PATCH /updates/{update_id} (preferred for partial updates) or PUT for full replacement.
    • Behavior: validate payload, fetch Update by id, apply non-None fields, commit session, return UpdateOut.
    • Permissions: reuse existing auth/permission checks used by create/delete endpoints.
  • DB changes (optional):
    • Add updated_at = Column(DateTime, default=func.now(), onupdate=func.now()) to Update model to track edits (optional but recommended).
  • Reuse existing CRUD utilities where possible. If crud.py contains a generic PUT handler, consider enabling or adapting it if that fits project conventions.

• Frontend implementation notes

  • API client:
    • Add updateUpdate(updateId, payload) in api.ts. Use PATCH and return normalized ProjectUpdate.
  • UI:
    • Add a small UpdateEditDialog component that accepts initialText, onSave, onCancel.
    • Add an 'Edit' icon/button next to each update in ProjectCard.tsx. Clicking opens the dialog.
    • On save: call updateUpdate; on success update local state (replace updated item) or re-fetch via fetchUpdates(projectId).
  • UX choices:
    • Keep dialog minimal (textarea + Save/Cancel).
    • Use optimistic UI update or show a spinner while saving; either is acceptable for a first patch.
  • Types: extend types.ts ProjectUpdate if needed.

• Testing

  • Backend: add an integration test that creates an Update, calls PATCH /api/updates/{id} to change text, asserts DB persisted change and response shape.
  • Frontend: add a unit test for updateUpdate API wrapper (mock fetch) and a component test for UpdateEditDialog that verifies onSave triggers API call and parent state update.

• Acceptance criteria

  • User can click Edit on an Update, change text, save, and see updated content in the UI.
  • The backend returns updated resource and persists change.
  • Automated tests cover the new endpoint and client wrapper.

• Implementation hints & low-risk approach

  • Implement backend endpoint first and test with curl/postman.
  • Add frontend API wrapper and a tiny dialog that calls the new endpoint.
  • Keep the UI change isolated to ProjectCard and a new UpdateEditDialog file to simplify review.
  • If adding updated_at, include a small migration (or add column as optional with default for new installs).