mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-09 01:46:46 +08:00
Bohan Jiang
d6ecf4bc8a
Creating a custom issue status whose display name is written entirely in a
non-Latin script — 客户确认, 고객 확인, 確認待ち — failed with "cannot derive a
status key from that name; provide one explicitly". The key alphabet is ASCII,
so such a name slugified to nothing, and the settings form exposes no field for
an explicit key: there was no way to create the status through the UI at all.
The key stays an ASCII machine handle — it is what issue.status stores, what the
CLI takes as an argument, and what the column CHECK permits — so there is NO
migration. When the name has nothing to slug the key falls back to the status's
CATEGORY plus an ordinal (in_review_2), which keeps saying which platform
behavior the status inherits.
Also fixed in the same path:
- Two names that collapse onto one slug ("待客户 Review" and "待供应商 Review"
both slug to "review") no longer make the second create fail with a conflict
blaming a display name nobody took. Disambiguation counts ARCHIVED rows, since
idx_issue_status_workspace_key is not partial.
- Every create takes the exclusive catalog lock, not just the deriving one, so
an explicit-key insert cannot land between a derive's catalog read and its
insert and hand a 409 to a form with no key field.
- The ordinal scan is bounded by the catalog rather than a constant.
A derived key is opaque, so the places that printed a key alone now carry the
name: issue payloads gain status_name (HTTP and background events alike, from
one catalog read), the unknown-status 400 lists `key (Name)`, creating a status
surfaces the key it minted, and `multica issue status --help` says the argument
is a key rather than a display name.
Fixes #7627. Supersedes #7636.