@ai-matrx/records-ui 0.70.0 → 0.75.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +114 -0
- package/dist/index.cjs +2990 -2612
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +135 -7
- package/dist/index.d.ts +135 -7
- package/dist/index.js +2853 -2468
- package/dist/index.js.map +1 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,119 @@
|
|
|
1
1
|
# Changelog — @ai-matrx/records-ui
|
|
2
2
|
|
|
3
|
+
## 0.75.0
|
|
4
|
+
|
|
5
|
+
**0.74.0 was tagged and never reached npm** — its release gate failed on
|
|
6
|
+
`view-deep-link.test.tsx`, which still asserted the switcher offered five views on the
|
|
7
|
+
day the archive made it six. The contract test was corrected on main; these are the
|
|
8
|
+
same contents, released under the next number because a version number that reached
|
|
9
|
+
the registry can never be reused and one that did not should not be argued about.
|
|
10
|
+
|
|
11
|
+
**An archived record has a way back, on every table.** (lane FIX-10A-ARCHIVE, from VERIFIER-10 finding F4.)
|
|
12
|
+
|
|
13
|
+
* Archiving was a **one-way door**. The grid's row action soft-deleted correctly — `deleted_at`
|
|
14
|
+
stamped, `version` bumped, nothing removed — and then, in the verifier's words, *"it is gone for
|
|
15
|
+
good as far as any screen is concerned… The door is there; nothing reaches it."* The store's
|
|
16
|
+
`custom.record_restore` had existed the whole time.
|
|
17
|
+
* **`ArchivedView` is the sixth way of looking at one table**, a `PageView` like the board and the
|
|
18
|
+
dashboards: pressed from the same row of buttons, named by the same `?view=` parameter, and
|
|
19
|
+
therefore inherited by **every** Table in every organization the moment this file exists. It is
|
|
20
|
+
one primitive over the whole store, never a per-table screen.
|
|
21
|
+
* It obeys the archived-items law in full: the default still hides archived rows, revealing them is
|
|
22
|
+
one click **on the surface itself**, the two lanes (**mine** and the organization's) are a control
|
|
23
|
+
rather than a guess, and each row says **who archived it and when** — read from
|
|
24
|
+
`history.row_versions`' own SOFT_DELETE actor, so nothing was backfilled and nothing is invented.
|
|
25
|
+
* Absent or honest, never dead: Restore is not drawn at all for somebody who may not write, with
|
|
26
|
+
the store's own sentence in its place; a read the store refuses is a sentence rather than an empty
|
|
27
|
+
list; and an empty list **names its lane**, so "nothing here" can never be read as "nothing was
|
|
28
|
+
ever archived" while the other lane holds twenty records.
|
|
29
|
+
* **Consumer action:** none, but it needs `custom.read_records_archived` on the database — applied
|
|
30
|
+
and granted to `authenticated` on 2026-09-22.
|
|
31
|
+
|
|
32
|
+
**A signature's verdict is read through the door that can answer it.** (lane FIX-10B, from VERIFIER-10 finding F6.)
|
|
33
|
+
|
|
34
|
+
* `SignBlock` asked `doc_signature_intact` once per signature to find out whether each seal still
|
|
35
|
+
held. That function is the internal half of the pair — SECURITY INVOKER over a doors-only table —
|
|
36
|
+
so from a browser every one of those calls answered `permission denied for table doc_signature`,
|
|
37
|
+
and the screen printed a refusal exactly where the verdict belongs. Measured live on 2026-09-22
|
|
38
|
+
against a signature that had just been written successfully: the e-sign half of Documents could
|
|
39
|
+
write a seal it could never verify out loud.
|
|
40
|
+
* It now asks `client.docSignatureRead`, the definer door, which answers the seal and the verdict
|
|
41
|
+
together. Proven live: *"intact: the record still says exactly what Ama Osei signed on 22
|
|
42
|
+
September 2026."*
|
|
43
|
+
* **Consumer action:** none. Needs `@ai-matrx/records` ≥ 0.51.0.
|
|
44
|
+
|
|
45
|
+
## 0.73.0
|
|
46
|
+
|
|
47
|
+
**"Signature" is on the Add-field menu, so the e-sign half of Documents can be reached.** (lane FIX-10B-F6, from VERIFIER-10 finding F6.)
|
|
48
|
+
|
|
49
|
+
* The Documents section told a person, under a rendered document, that their table needed
|
|
50
|
+
"a signature column — a text column whose format is signature", and section 1 — this
|
|
51
|
+
package's `FieldEditor` — offered Name, what it holds, required, multi, dated,
|
|
52
|
+
sensitivity, context policy and a validation check. **No format control and no signature
|
|
53
|
+
choice.** The precondition the product stated could not be met from any screen.
|
|
54
|
+
* **The menu is the store's list now.** `PickableFieldType` was a union assembled here — the
|
|
55
|
+
parity floor plus two words this file knew about — and that union WAS the defect: a kind
|
|
56
|
+
the store took and the menu omitted was invisible, with no error and no red test.
|
|
57
|
+
`FIELD_TYPE_CHOICES` is now checked against `DECLARABLE_FIELD_KINDS` (generated from
|
|
58
|
+
`custom.field_kinds()`), and `kindsWithNoChoice()` is the guard: the suite fails the day
|
|
59
|
+
the store learns a kind nobody put on the menu. Proven failing-then-passing on 2026-09-22
|
|
60
|
+
— it named `signature` before the choice was written.
|
|
61
|
+
* **`save()` gained the arm every future kind arrives through.** It had exactly two branches,
|
|
62
|
+
relation and plain, and everything else was sent as `parity_type` — so a menu entry that is
|
|
63
|
+
not one of the fourteen would have been refused "There is no field type called signature".
|
|
64
|
+
A kind that is neither parity nor plain nor a relation now goes as its WORD, which is what
|
|
65
|
+
`custom._field_document_for` resolves.
|
|
66
|
+
* **And an existing signature column opens as one.** `editorKindFor` answers which EDITOR to
|
|
67
|
+
draw and correctly says "text" for it; the panel asks which KIND somebody picked, so it
|
|
68
|
+
reads the format the store wrote. Without that, opening the column would have said "Text"
|
|
69
|
+
and saving it would have quietly retyped the column out from under the seal it holds.
|
|
70
|
+
* Known gap, stated rather than hidden: the grid and the record form still draw a signature
|
|
71
|
+
column as an ordinary text box, because `fieldKindFor` classifies it as text. Typing there
|
|
72
|
+
is not how a signature is made — `custom.doc_sign` is — and nothing is sealed by it, but
|
|
73
|
+
the box is not yet honest about that.
|
|
74
|
+
* Consumer action: none required.
|
|
75
|
+
|
|
76
|
+
## 0.72.0
|
|
77
|
+
|
|
78
|
+
**The board stopped saying it held the whole table over four rows of forty-two.** (lane DRILL.)
|
|
79
|
+
|
|
80
|
+
* Seen on Rincon Plumbing Co's own board the moment 0.70.0 let a dashboard number narrow
|
|
81
|
+
it: the column read "Scheduled 4", every card under it was real, and the line above them
|
|
82
|
+
read *"This view has no Rule, so it holds the whole table."* That sentence was written
|
|
83
|
+
when a view had exactly two possible answers — a Rule, or everything. A question from
|
|
84
|
+
the address is a third, and it now has its own words: *"These are only the records
|
|
85
|
+
behind the number you clicked — the store narrowed them, not this screen."*
|
|
86
|
+
* Found by looking at the screenshot of the thing that had just been proved working, which
|
|
87
|
+
is the only way this class is ever found: every assertion in the drill proof passed.
|
|
88
|
+
|
|
89
|
+
## 0.71.0
|
|
90
|
+
|
|
91
|
+
**A public form no longer takes the page down when it asks for a choice, a linked record or a
|
|
92
|
+
person.** (lane FIX-10A, from VERIFIER-10 finding F1.)
|
|
93
|
+
|
|
94
|
+
An agent built and published a job-request form for a plumbing company in forty seconds and
|
|
95
|
+
handed over its link. Opened by a signed-out stranger — the only person that link is for — it
|
|
96
|
+
answered **HTTP 500**, on production, with `useRecordsClient was called outside
|
|
97
|
+
<RecordsProvider>` in the console.
|
|
98
|
+
|
|
99
|
+
The public arm of `FormRunner` is deliberately the arm that mounts **no store client**: the
|
|
100
|
+
server resolved the Fields through `custom.form_public`, and the browser on that page holds no
|
|
101
|
+
key, knows no organization and may not read a row. `useOptionalRecordsClient` exists in
|
|
102
|
+
`@ai-matrx/records` for exactly that screen. But three of the editors `FieldControl` can draw
|
|
103
|
+
asked for the client with `useRecordsClient`, which throws by design — so **any** public form
|
|
104
|
+
carrying a drop-down, a relation or a person question died, whatever it was about.
|
|
105
|
+
|
|
106
|
+
* **`OptionControl`, `RelationPicker` and `PersonPicker` now take the optional client** and,
|
|
107
|
+
with none mounted, are **absent and honest** instead of fatal. A choice question takes the
|
|
108
|
+
answer as text and says why the list cannot be read on a page answered without an account; a
|
|
109
|
+
relation question says it cannot be answered here and to leave it blank; a person question
|
|
110
|
+
already had that sentence and now reaches it instead of throwing above it.
|
|
111
|
+
* **The guard** — `src/a-public-form-needs-no-store-client.test.tsx` — walks `FIELD_KINDS`, the
|
|
112
|
+
store's own closed list of the nineteen kinds a Field can be, and renders the public arm with
|
|
113
|
+
a question of every one of them and no provider of any sort above it. Red on the bytes before
|
|
114
|
+
this release (4 of 19), green on these. A twentieth kind whose editor reaches for the store
|
|
115
|
+
turns it red the day it is added, not the day a stranger opens a link.
|
|
116
|
+
|
|
3
117
|
## 0.70.0
|
|
4
118
|
|
|
5
119
|
**The bar that said four now opens four.** (lane DRILL.)
|