structure

Changes a column's own fields. A field that is not sent is left alone; sending color_token as null clears it, and sending wip_limit as null or 0 removes the limit. The name stays unique in the collection. Where the column sits is not here - that is :reorder, so that a rename and a rearrangement are two operations with two audit entries.

Takes the column off the board. Its entries are not deleted with it: they move to the leftmost remaining column, or out of any column when this was the last one. What became of them is in the answer rather than left to be discovered.

Moves a column along its board. An absent before_bucket_id moves it to the right hand end.

Adds a label to a collection's vocabulary. The name has to be free in the collection, compared without regard to case or accents. The colour is required: a label is rendered as a chip and nothing else, so with none a client would have to invent one.

Changes a label's own fields. A field that is not sent is left alone; sending description as null clears it. The colour cannot be cleared - a label is rendered as a chip and nothing else. The name stays unique in the collection.

Takes the label out of the collection's vocabulary. The entries that carried it are not rewritten: they stop showing it because it is gone, which is what makes the deletion undoable without having to remember who wore it.

The custom field definitions in force, by key. Naming a collection answers the ones that apply inside it: its own, and the workspace-wide ones above it. Naming none answers the workspace-wide ones alone. Deleted definitions are not in the answer - their values stay in the entries and stop being visible, which is what makes the deletion undoable.

Defines a custom field. The key has to be free in its scope - a collection's keys are free of each other's and of the workspace-wide ones - and it is an identifier rather than a label: lower case, digits and underscores, and it never changes afterwards. Which types carry the field is applies_to, bounded by the CUSTOM_FIELDS capability: an activity has no custom fields, so naming one is refused.

Changes what a definition permits. A field that is not sent is left alone. The key and the kind are not among them: a key that moved would orphan every value stored under it, and a kind that changed would reinterpret them - both are a new definition rather than an edit. Narrowing the options of a SELECT does not rewrite the entries that hold a value which is no longer offered; they keep it until somebody sets the field again.

Takes the definition out of use. A soft delete: the values stay in the entries and stop being visible, because rewriting custom_fields across every entry in a collection would be an unbounded write from one request. A definition recreated under the same key is a new definition and shows none of what the old one held.