6 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	193dfb9e94	tags: renaming onto an existing tag merges them, and the older row survives ... The three surfaces did not agree on what renaming a tag onto a name another one already holds should do, and none of the three answers was good. I described this wrongly first time and the correction matters. The local store does NOT silently create a duplicate: `idx_labels_name` is unique on `lower(name)`, so the bare UPDATE in `rename_label` failed, and the user got a raw SQLite "UNIQUE constraint failed" as their error message. The server meanwhile answered 409 "a tag with that name already exists" — and only on an EXACT match, because its constraint is on the raw name while every client's index is on `lower(name)`. That last part is the sharper bug. The server would happily hold "Groceries" beside "groceries"; no synced client can store both. Creating that pair on the web armed a pull that fails later, on a phone, in a path with no UI. Operator's call: a rename onto an existing name means merge — typing an existing tag's name onto this one says they are the same thing. * `store::rename_label` and the server's PATCH now implement one rule. THE OLDER ROW SURVIVES and takes the new spelling. Age rather than "the one that already held the name", so that renaming A→B and B→A land on the same survivor; otherwise the outcome depends on which way round someone typed it, and two devices tidying the same pair disagree about which id still exists. Ties go to the incumbent, so it stays deterministic. * The core reuses `merge_labels` rather than reimplementing the move. That is the only place that knows to mark every affected NOTE dirty before the delete cascades the membership rows away, which is what makes a merge reach the server at all. * The server's rename and its `/merge` route now share one `_merge_into` helper, for the same reason. * Both server lookups became case-INSENSITIVE, matching every client. The create path is included: it was the one actually minting the unstorable pair, so fixing only the rename would have left the door open. * The web asks before merging, naming both note counts. A merge cannot be undone by repeating it and is now reachable by a typo in a text field — the same reasoning as the delete confirmation in #2116. The confirmation lives in the shared store, so the desktop gets it too; the FFI does not ask, because that belongs to the surface with a person in front of it. * The web store detects the merge from the LIST, not the response: the survivor may be the row we asked to rename, so an unchanged id proves nothing. Tests: three integration tests over a real database (both rename directions land on the older row; a case-varied create returns the existing tag) and two through the Android FFI, which is the binding the phone will use. Also fixes a straggler from 8c7553d — the delete confirmation still said "the label". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 16:46:15 -04:00
bvandeusenandClaude Opus 5	8c7553d619	copy: the product says "tags" now, and the schema keeps saying Label ... Two words for one concept cost real comprehension: over a single exchange the operator concluded that auto-tagging did not exist (it does, in `derive.rs`) and that a tag-management view did not exist (it does, `LabelsModal.vue`). The `#` is how most of these get made, so the `#` wins the noun. User-visible strings only, on all three surfaces plus the server's errors. `Label`, `NoteLabel`, `via_tag`, `label_id`, the tables, `/api/labels` and the FFI names are all untouched — renaming those touches migrations and the wire format to buy nothing a reader can see. Two of these were more than a find-and-replace: * Android's `label_from_tag` said "from #tag", sitting beside a chip that already renders as `#name`. Once every one of them IS a tag that hint is circular. What it actually tells you is that the note's BODY owns this one — which is why it alone has no remove cross — so it now says "from the text". * The web's empty state said "No labels yet — create one above" while Android's already mentioned the `#` route. The web now says it too. That is the exact fact the operator did not have. The paired `aria-label`s went with their `title`s; a screen reader saying "label" while the tooltip says "tag" is the same confusion with a smaller audience. Left alone deliberately: `json_error("invalid label")` and `"label_ids must be a list"` in `notes/__init__.py` name the `?label=` query parameter and the `label_ids` request field. Those are wire surface, not the word a person reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c	2026-08-31 15:53:28 -04:00
bvandeusenandClaude Opus 4.8	f1033da75e	M9 S3 (backend): organize routes adopt toolkit + shared label reconciliation ... DRY across the "organize/recall" backend surface: - serialize.py (new): serialize_label(label) — the base {id,name,color} shape. labels.py builds on it (adds count); sync deltas will (S4). - labeling.py (new): resolve_owned_label_ids() + reconcile_manual_labels() — the "set a note's MANUAL (picker) labels, leave the via_tag rows alone" logic was duplicated line-for-line between notes.set_note_labels and sync._apply_note_manual_labels. Now one home; both adopt it (removes the redundant `chosen`==owned recompute in notes). Behavior-preserving. - labels.py: json_error/not_found/parse_uuid, colors.normalize_color, and serialize_label; dropped local LABEL_COLORS + _normalize_label_color (NOTE_COLORS is the single palette) and `import uuid` (rule 22). - saved_filters.py: json_error/not_found/parse_uuid for its 2 uuid parses + error shapes. - graph.py: no change — no error/uuid/palette-normalize duplication to fold. Test: DB-free test_serialize_label_shape guards the base shape. sync.py's reconciliation swap is behavior-identical; operator-verified on deploy (no Postgres CI lane). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-23 21:26:59 -04:00
bvandeusenandClaude Opus 4.8	ae0c748507	M6: label management — usage counts + merge ... Extends the existing label manager (create/rename/color/delete) with the two missing maintenance tools (task 1904), so the label list stays clean — which matters more now that #tags mint labels automatically. Backend: GET /api/labels returns a per-label note count (one grouped query); new POST /api/labels/<id>/merge moves the source label's notes onto a target and deletes the source (repoint via delete+reinsert to avoid mutating the composite PK; preserves via_tag; dedupes notes already on the target). Body #tags are NOT rewritten, so a tag-sourced label re-mints on next edit if its #tag text remains — a documented nuance. Frontend: LabelsModal shows each label's note count and a 'merge into…' picker; also restores the previously-missing close (x) and merge icons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-22 12:36:50 -04:00
bvandeusenandClaude Opus 4.8	f321c2bf70	labels: per-label color ... Give labels a color (migration 0011 adds labels.color, server_default 'default' so existing labels keep the neutral chip). The PATCH endpoint now updates name and/or color; note serialization carries each label's color. Frontend: a swatch picker per label in the Edit-labels modal, colored chips on cards + in the editor (LABEL_CHIP_CLASSES), and a color dot on each sidebar label. Reuses the note color vocabulary. (Graph node coloring rides this in the graph-liveliness task.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-20 13:11:50 -04:00
bvandeusenandClaude Opus 4.8	4d1fc1bdf9	M2 labels backend: labels + note_labels, CRUD, note-label set, filter ... - Label + NoteLabel models; migration 0004 (labels unique per owner + note_labels join, cascade). - /api/labels: list/create(idempotent)/rename(clash-checked)/delete, owner-scoped. - PUT /api/notes/<id>/labels to set a note's labels (validated against owned). - Note responses now include labels[] (merged via one explicit join query — no lazy relationship); GET /api/notes?...&label=<id> filters by label. - DB-free auth-guard tests for labels endpoints. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-19 21:43:21 -04:00