Schema: column form builder UI (12 field types) #18

Activity

1. Adron

   added

   parityWeb/API feature-parity workWeb/API feature-parity work

   P0Must have for a credible parity claimMust have for a credible parity claim

   area:listsArea: listsArea: lists

   on Sep 15, 2026
2. Adron

   added a parent issue on Sep 15, 2026

   • Epic: List schema / columns (DSL) — no longer API-blocked #16
3. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   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.
4. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   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.
5. Adron

   closed this as completedon Sep 16, 2026
6. Adron

   added a commit that references this issue on Sep 16, 2026

   docs: correct my own claim — `version` is NOT optimistic concurrency

   ...

   c9b1f25
7. Adron

   added a commit that references this issue on Sep 24, 2026

   merge origin/main into issue-73-github-backed-list, and consolidate c…

   ...

   f6c2743