Schema: column form builder UI (12 field types)

[Adron]

Scope

A column editor in Views/ListsView.xaml — the app's equivalent of the web's schema form builder — for creating and editing a list's columns.

Per column

• key (machine key; unique, immutable once rows exist — warn on change),
• type from the twelve supported types,
• label, required, defaultValue, placeholder, helpText,
• options (required for select/multiselect),
• visible, displayOrder (reorderable).

priority defaults to low/medium/high/urgent when no options are supplied.

Acceptance criteria

• Add / edit / remove / reorder columns; at least one column is always enforced client-side.
• Duplicate keys are blocked before the request is sent.
• select/multiselect require at least one option before save is enabled.
• Used both at list-create time (POST /api/lists with schema) and for an existing list.
• Strata tokens only; 4px corners; 4pt grid.

[Adron]

Live-verified findings from the schema service (#17 / PR #143) — three change the design here

⚠️ 1. The non-destructive properties form accepts only SIX types, not twelve

400 Unknown propertyType 'textarea'. Allowed: text, number, boolean, date, url, email

propertyType is also mandatory on every item (omitting it gives the same error for 'undefined'/'null').

Consequence: a list using textarea, datetime, tel, select, multiselect or priority cannot be edited non-destructively at all — every change to it has to go through the destructive DSL rebuild. That is a real, permanent constraint on #22's guard, not an edge case: the moment a user picks one of the six richer types in #18's builder, they lose safe editing on that list forever.

Exposed as ListFieldType.PropertiesEditable and ListSchema.SupportsPropertiesEdit so the UI can tell the user before they choose.

2. "Destructive" means columns, not rows — so #22's confirmation copy must not say "rows will be deleted"

Confirmed live. The DSL rebuild:

• drops and recreates every column with a new id, losing any validation / options / visibility the new DSL omits;
• leaves rows intact, but values whose keys no longer exist are orphaned in rowData — still stored, not shown, not validated.

And it renames the list: schema.name overwrote the title ('ZZ Throwaway Schema Probe' → 'ZZ Renamed By DSL Rebuild'), and schema.description overwrites the list description too — clearing it when omitted. #22's confirmation needs to say all three things.

3. Deleting a data-bearing column requires ?force=true

409 {…, "propertiesWithData": ["link"]}

?force=true then strips that key from every row. The shared EnsureSuccessAsync discards the propertiesWithData array, so a dedicated ListSchemaException carries Issues / PropertiesWithData / RequiresForce. #18 should name the affected columns in its confirmation rather than showing a bare 409.

4. The server never validates conditional visibility — #20 must

An unknown operator, a missing watched key, and a forward reference all return 200 and then silently never match. So there is no server-side safety net: ListSchema.Validate() does these checks client-side, and #20's editor should surface them rather than letting a rule quietly do nothing.

5. properties PUT definitively preserves row data — #22's guard is sound

A rename + column-add on a list holding two rows returned 200 and both rows came back with identical ids, identical version (still 1), and identical rowData. Column ids were preserved too, and the validationRules / helpText / visibilityCondition that the properties shape cannot even express survived untouched.

Note the envelope differs between the two directions: GET returns {"data":{…}}, the properties PUT returns {"properties":[…]} ordered by displayOrder — no data wrapper.

6. Schema-less lists are unaffected

Created without a schema they answer {"data":{"name":"<list title>","description":…,"fields":[]}} and accept rows with arbitrary, even nested, keys. Unknown keys are accepted on a schema'd list too — nothing is stripped. fields: [] cannot be PUT back (DSL must have at least one field), so ListSchema.Validate() catches that locally.

Also relevant to #21

Row-write validation returns 422 with details:[{field,message}], which the current plumbing flattens — so #21 can't currently attach a message to the offending field without unpacking that itself.

Separately, #144/PR #146 fixed a crash on the row-read path (ListDataRow.ListId was required but absent) and modelled version, which is the hook for optimistic concurrency on row edits.

[Adron]

Implemented in #161 — work continues in the PR from here. The builder covers all twelve types with add/edit/remove/reorder, blocks duplicate keys and option-less select columns before the request, and is wired both into list creation (as POST /api/lists' schema) and into a saved list, where it writes only through the non-destructive properties PUT.

Three live-probed behaviours shaped it: a properties defaultValue must be a JSON string (a raw number or boolean answers 500 and discards the whole request), an omitted field on a properties item is cleared rather than preserved, and a saved column's key can't change — so the key box locks and every draft sends its full projection. The 409 propertiesWithData case became an in-place confirmation naming the affected columns.

The destructive DSL rebuild is deliberately absent; it lands as the separate labelled action in #22, stacked on top of this.