@object-ui/plugin-tree 17.6.0 → 17.7.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 +2204 -0
- package/README.md +153 -20
- package/dist/ObjectTree.d.ts +43 -3
- package/dist/ObjectTree.d.ts.map +1 -1
- package/dist/index.d.ts +27 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +263 -177
- package/dist/index.umd.cjs +1 -1
- package/package.json +14 -10
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,2209 @@
|
|
|
1
1
|
# @object-ui/plugin-tree
|
|
2
2
|
|
|
3
|
+
## 17.7.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 990a2d6: refactor(plugin-tree)!: retire the bare `tree` node type key; `object-tree` is the one spelling (objectui#10859, batch 8)
|
|
8
|
+
|
|
9
|
+
**BREAKING (authoring):** the plugin no longer registers `tree` (and with it `view:tree`), the second key it registered on the `object-tree` renderer with the same inputs. `objectui validate` refused a `tree` node at `type`, because only `object-tree` has a declaration (`@objectstack/spec`'s `ComponentPropsMap` row), and nothing in this repository authored the alias. A node authored `type: "tree"` now renders the "Unknown component type" panel.
|
|
10
|
+
|
|
11
|
+
Migration:
|
|
12
|
+
|
|
13
|
+
- `{ "type": "tree", … }` → `{ "type": "object-tree", … }`, with the same keys.
|
|
14
|
+
|
|
15
|
+
The host-composition VIEW type `tree` and the FIELD type `tree` are different layers and are unchanged: `ObjectView` and `ListView` already compose a stored tree view into an `object-tree` node.
|
|
16
|
+
|
|
17
|
+
**Clause-②: yes** — a registration leaves the runtime (narrowing), released as `minor` with this banner.
|
|
18
|
+
- 20d23be: `object-tree` publishes the keys its `@objectstack/spec` 17.5.0 row declares and its renderer honours (objectui#11168 slice 3, objectui#11111 decision 3 = B). Each key was measured on the real renderer first.
|
|
19
|
+
|
|
20
|
+
- `data`, `staticData`, `filter` and `navigation` are now registration inputs on both tags (`object-tree` and `view:tree`). The page validator used to report each as an unknown prop, even though the tree reads it. Each description says what the tree does with the key, including the cases that draw nothing: the `api` and `schema` providers under `data`, and an absent `navigation`. On `navigation`, `page` and a block without `mode` open a record page through the record navigator the host publishes (the console publishes one on its custom pages, record pages and list views). The object is `data.object` when `data` is the object provider, so it wins when both are written, and the tree's `objectName` otherwise. Under a host that publishes none, or on a tree that names neither (inline rows with no `objectName`), they open nothing.
|
|
21
|
+
- `objectName` is no longer a required input. The record source is one of `data`, `staticData` and `objectName`. A tree on inline rows never reads the object name, and the validator used to raise `missing-required-prop` on a tree that draws.
|
|
22
|
+
- The `tree` input's description now names its four members and what each does.
|
|
23
|
+
- `ObjectTree` reads `navigation` without a cast, because the node type declares it.
|
|
24
|
+
|
|
25
|
+
What the tree draws and what a click opens are unchanged.
|
|
26
|
+
|
|
27
|
+
⚠️ **Dated note, 2026-10-02 — the `view:tree` tag is retired — objectui#10859.**
|
|
28
|
+
Later in this same release objectui#10859 batch 8 unregistered the bare `tree` alias (and with it
|
|
29
|
+
`view:tree`), so these inputs ship on one tag, `object-tree`. Author `object-tree`. The rest of this
|
|
30
|
+
entry is kept as the reading of this change.
|
|
31
|
+
- e3d117a: `ObjectGantt` and `ObjectTree` resolve a relationship target only from the two
|
|
32
|
+
spellings a contract carries, dropping the third one no contract declares
|
|
33
|
+
(objectui#6837, second slice).
|
|
34
|
+
|
|
35
|
+
- `ObjectGantt`'s quick-filter option fetch was
|
|
36
|
+
`fd?.reference_to ?? fd?.reference ?? fd?.referenceTo`; it is now
|
|
37
|
+
`fd?.reference_to ?? fd?.reference`.
|
|
38
|
+
- `ObjectTree`'s `detectParentField` was
|
|
39
|
+
`def?.reference || def?.reference_to || def?.referenceTo`; it is now
|
|
40
|
+
`def?.reference || def?.reference_to`.
|
|
41
|
+
|
|
42
|
+
**Accept-set move — a def carrying ONLY `referenceTo` stops resolving a target
|
|
43
|
+
at these two seams.** Concretely: the gantt quick filter for that field falls
|
|
44
|
+
back to the distinct values present in the loaded rows instead of fetching the
|
|
45
|
+
referenced object's full domain, and the tree stops auto-detecting that field as
|
|
46
|
+
its parent pointer, so records render as a flat forest unless `parentField` is
|
|
47
|
+
configured explicitly. Nothing else changes; the two surviving arms are
|
|
48
|
+
untouched.
|
|
49
|
+
|
|
50
|
+
Two things bound that move:
|
|
51
|
+
|
|
52
|
+
- Any def that entered through the ingestion choke point is unaffected.
|
|
53
|
+
`normalizeSchemaReferenceKeys` reads `reference_to ?? reference ??
|
|
54
|
+
referenceTo` and stamps both snake_case keys, so a `referenceTo`-only def
|
|
55
|
+
arriving via `MetadataProvider` or `ObjectStackAdapter.getObjectSchema`
|
|
56
|
+
already carries `reference_to` before either component sees it. Only a def
|
|
57
|
+
that bypassed that door entirely is affected — and that door is not total:
|
|
58
|
+
`getObjectSchema` is a required member of the published `DataSource`
|
|
59
|
+
interface, and both components call it on the generic `dataSource`.
|
|
60
|
+
- No contract declares the deleted spelling. `@objectstack/spec` 17.2.0's
|
|
61
|
+
`FieldSchema` refuses `referenceTo` by name with `unrecognized_keys`, carrying
|
|
62
|
+
its own "Did you mean `referenceTo` -> `reference`?" rename, and `referenceTo`
|
|
63
|
+
is additionally a tombstone in `RETIRED_FIELD_KEY_TOMBSTONES` (objectui#6041)
|
|
64
|
+
at all three strip sites, so the designer read door removes it before a draft
|
|
65
|
+
round-trips.
|
|
66
|
+
|
|
67
|
+
A repo-wide structure-walk producer census found **0** emitters of `referenceTo`
|
|
68
|
+
reaching either seam, measured in the cell these components read (a value inside
|
|
69
|
+
an object schema's `fields` container) against controls `reference` (92 hits / 36
|
|
70
|
+
files) and `reference_to` (52 / 36) hot in the same pass over the same cells;
|
|
71
|
+
the only two in-cell hits are negative fixtures of the retirement machinery,
|
|
72
|
+
asserting the read door strips the key. Neither `plugin-gantt` nor `plugin-tree`
|
|
73
|
+
emits `referenceTo` anywhere, while both packages' own fixtures are hot on the
|
|
74
|
+
surviving spellings.
|
|
75
|
+
|
|
76
|
+
Pinned by `ObjectGantt.referenceArms-6837.test.tsx` and
|
|
77
|
+
`ObjectTree.referenceArms-6837.test.tsx`, which keep the live arms green beside a
|
|
78
|
+
named refusal for the deleted key.
|
|
79
|
+
|
|
80
|
+
⚠️ **Dated note, 2026-09-30 — the choke point folds, it no longer stamps both keys — objectui#11070.** "`normalizeSchemaReferenceKeys` ... stamps both snake_case keys" above held when this change landed. Later in this same release objectui#11070 (round 4) made that pass fold a legacy spelling onto `reference` without stamping `reference_to`; a def that entered through it still carries `reference`, the one arm both components keep. `.changeset/11070-reference-to-round4.md` states what ships; the text above is kept as the reading of this change.
|
|
81
|
+
- 045d20b: Relationship-target readers resolve a lookup's target from `reference` alone,
|
|
82
|
+
dropping the `reference_to` fallback arm (objectui#6837, half 2).
|
|
83
|
+
|
|
84
|
+
Maintainer ruling, 2026-08-31, 原文照录: 「objectui不是前端的项目吗?后端的元数据只要
|
|
85
|
+
对,前端按协议执行就行了呀」. Protocol normalization belongs on the SERVER; the front
|
|
86
|
+
end just executes the protocol. objectstack#13847 landed the server half — a
|
|
87
|
+
`field-reference-to-alias` conversion rewrites stored `reference_to` to
|
|
88
|
+
`reference` on the serve path and in `os migrate meta`.
|
|
89
|
+
|
|
90
|
+
`reference` is the only target spelling `@objectstack/spec`'s `FieldSchema`
|
|
91
|
+
declares. Measured on the installed 17.2.0: it refuses `reference_to`,
|
|
92
|
+
`referenceTo` and `target` with `unrecognized_keys`, each carrying its own
|
|
93
|
+
"Did you mean -> `reference`?" rename, while a nonsense key gets the same
|
|
94
|
+
refusal with NO rename hint and `reference` parses clean.
|
|
95
|
+
|
|
96
|
+
## ⚠️ BREAKING for a hand-written schema that spells `reference_to` — read this
|
|
97
|
+
|
|
98
|
+
**This is a behaviour change for BYO consumers, and it is being stated rather
|
|
99
|
+
than shipped silently.** ObjectUI is usable without an ObjectStack backend
|
|
100
|
+
(`examples/byo-backend-console`), and a hand-written TypeScript schema passes
|
|
101
|
+
through no zod door, so nothing rejects the legacy spelling at authoring time.
|
|
102
|
+
|
|
103
|
+
**The break surface is narrower than "all BYO consumers", and this is the
|
|
104
|
+
measurement rather than a blanket claim.** Two ingestion choke points stamp both
|
|
105
|
+
snake_case keys from whichever spelling arrived — `MetadataProvider`'s type
|
|
106
|
+
cache for metadata type `object`, and `ObjectStackAdapter.getObjectSchema`. Any
|
|
107
|
+
def that passed either one already carries `reference` and is **completely
|
|
108
|
+
unaffected**. What is affected is exactly:
|
|
109
|
+
|
|
110
|
+
- **A `DataSource` implementation other than `ObjectStackAdapter`.**
|
|
111
|
+
`getObjectSchema` is a required member of the published `DataSource`
|
|
112
|
+
interface, and the readers call it on the generic `dataSource` (through
|
|
113
|
+
`useSettledSchema` and directly), so a host adapter's object schema reaches
|
|
114
|
+
them raw. Every in-repo example of one is on this path:
|
|
115
|
+
`ApiDataSource`, `ValueDataSource`, `packages/types/examples/rest-data-source.ts`,
|
|
116
|
+
`examples/byo-backend-console/src/mockDataSource.ts`,
|
|
117
|
+
`packages/runner/src/lib/mockDataSource.ts`,
|
|
118
|
+
`apps/site/app/components/galleryDataSource.ts`,
|
|
119
|
+
`apps/console/src/sdui-workbench-preview.tsx`,
|
|
120
|
+
`packages/plugin-grid/demo/bulk-actions.tsx`.
|
|
121
|
+
|
|
122
|
+
**Measured on this tree, none of those eight emits a relationship target at all** —
|
|
123
|
+
`reference_to` and `reference` are both zero in each, and
|
|
124
|
+
`examples/byo-backend-console` carries no lookup or master_detail field
|
|
125
|
+
anywhere (its only `reference` hits are a vite triple-slash directive and a
|
|
126
|
+
tsconfig `references` array). The single in-repo producer that WAS on this
|
|
127
|
+
surface, `packages/plugin-gantt/demo/main.tsx`, is fixed here at the producer.
|
|
128
|
+
|
|
129
|
+
⇒ **If you author object metadata by hand and spell a lookup's target
|
|
130
|
+
`reference_to`, rename that key to `reference`.** Symptom if you do not: the
|
|
131
|
+
target silently fails to resolve, and the affected surface degrades rather than
|
|
132
|
+
erroring — a related list is not derived, a gantt quick filter falls back to the
|
|
133
|
+
distinct values in the loaded rows instead of the referenced object's full
|
|
134
|
+
domain, a tree stops auto-detecting its parent pointer, a lookup cell shows a
|
|
135
|
+
raw id, a chart's group-by labels stay unresolved.
|
|
136
|
+
|
|
137
|
+
The ingestion choke point now emits a **dev-mode warning** when a def arrives
|
|
138
|
+
carrying only `reference_to` or `referenceTo` and no `reference`. It names the
|
|
139
|
+
object, the field and the offending key, and points at this ruling. Stamping is
|
|
140
|
+
deliberately unchanged, so nothing that worked stops working. It is memoised
|
|
141
|
+
once per **(object name, field name, spelling, target value)** — every segment
|
|
142
|
+
of that key is pinned, in both directions, in
|
|
143
|
+
`reference-keys.legacyWarning-6837.test.ts`.
|
|
144
|
+
|
|
145
|
+
⛔ **This warning does NOT cover the break described above, and it is worth being
|
|
146
|
+
exact about that rather than letting it read as mitigation.** It lives in
|
|
147
|
+
`normalizeFieldReferenceKeys`, reachable only through
|
|
148
|
+
`normalizeSchemaReferenceKeys`, which has exactly two production call sites —
|
|
149
|
+
`MetadataProvider` (metadata type `object`) and
|
|
150
|
+
`ObjectStackAdapter.getObjectSchema`. Both of those also STAMP the def, so the
|
|
151
|
+
warning fires precisely where the def still resolves and nothing is broken. A
|
|
152
|
+
hand-written schema served through any OTHER `DataSource` — the break surface —
|
|
153
|
+
reaches a reader raw: it never passes through this code and produces **no
|
|
154
|
+
warning at all**. On that path the failure is exactly as silent as before.
|
|
155
|
+
A reader-side or shared-resolver diagnostic, which would cover it, remains open
|
|
156
|
+
on objectui#6837.
|
|
157
|
+
|
|
158
|
+
⚠️ **Dated note, 2026-09-29 — the call-site count above has since moved —
|
|
159
|
+
objectui#7650.** "exactly two production call sites" above held when this change landed
|
|
160
|
+
(`045d20ba8`). Later in this same release objectui#7650 (PR objectui#8868) added a call
|
|
161
|
+
on `MetadataProvider`'s by-name object-schema serve path. Re-measured for objectui#10979
|
|
162
|
+
on `main` at `2eaf5be27`, `normalizeSchemaReferenceKeys` had three production call sites:
|
|
163
|
+
two in `MetadataProvider`, on its list path and on its by-name path, and one in
|
|
164
|
+
`ObjectStackAdapter.getObjectSchema`.
|
|
165
|
+
`.changeset/7650-metadata-item-reference-canonicalisation.md` (PR objectui#8868) states
|
|
166
|
+
what ships; the text above is kept as the reading of this change.
|
|
167
|
+
|
|
168
|
+
## What did NOT change
|
|
169
|
+
|
|
170
|
+
**Every key these readers EMIT is byte-identical**, and that was verified
|
|
171
|
+
mechanically over the whole diff rather than asserted. Eleven of the sixteen
|
|
172
|
+
sites write a target onto a bag whose own contract spells it `reference_to` (or
|
|
173
|
+
camelCase `referenceTo`): the six whose read and write share a line —
|
|
174
|
+
`RecordDetailDrawer`, `RelatedList`, `buildDefaultPageSchema`, `ListView`,
|
|
175
|
+
`FilterConditionField`, `resolveActionParams` — plus five more that read on one
|
|
176
|
+
line and emit on another, and so are just as much emitters: `RecordDetailView`,
|
|
177
|
+
`RecordMetaFooter`, `ObjectGallery`, `fieldEnrichment` (all `reference_to`) and
|
|
178
|
+
`UserFilters` (`referenceTo`). Only the right-hand read narrowed anywhere; the
|
|
179
|
+
emitted key is what its target contract declares, and renaming it would be a
|
|
180
|
+
separate change.
|
|
181
|
+
|
|
182
|
+
**Three readers were deliberately left alone.** `LookupCellRenderer`
|
|
183
|
+
(`fields/src/index.tsx`), `LookupField` and `UserField` read `FieldMetadata` —
|
|
184
|
+
ObjectUI's OWN contract, whose `LookupFieldMetadata` declares `reference_to` and
|
|
185
|
+
never declares `reference`. They are fed by the emitters above and by published
|
|
186
|
+
example schemas (`examples/schema-catalog/src/schemas/fields-lookup/*.json`), so
|
|
187
|
+
narrowing them would break in-repo producers, and `plugin-grid`'s
|
|
188
|
+
`relationalMetaCopySet.derivation.test.ts` re-derives its read set from exactly
|
|
189
|
+
those three sources — where `reference_to` is recorded with verdict
|
|
190
|
+
`adapter-stamped`. `DetailViewFieldSchema` is likewise untouched.
|
|
191
|
+
|
|
192
|
+
⚠️ **Dated note, 2026-09-30 — the stamp, the three readers and the emitted key have since moved — objectui#11070.** Later in this same release objectui#11070 (round 4) retired `reference_to` inside ObjectUI as well. `normalizeFieldReferenceKeys` now FOLDS a legacy `reference_to` / `referenceTo` onto `reference` and no longer stamps `reference_to`, so "Stamping is deliberately unchanged" and "stamp both snake_case keys" above no longer describe what ships. `LookupCellRenderer`, `LookupField` and `UserField` read `reference` only; `LookupFieldMetadata`, `MasterDetailFieldMetadata` and `DetailViewField` (with `DetailViewFieldSchema`) declare `reference`; and the emitters listed under "What did NOT change" write `reference`. A hand-written schema served through a `DataSource` other than `ObjectStackAdapter` that spells only `reference_to` therefore also loses the lookup picker's target and the read cell's name. `.changeset/11070-reference-to-round4.md` states what ships; the text above is kept as the reading of this change.
|
|
193
|
+
- 7c3df8f: A non-grid view's fetch now carries a platform row ceiling, and crossing it is
|
|
194
|
+
never silent (objectui#7210, maintainer ruling a′, 2026-09-02).
|
|
195
|
+
|
|
196
|
+
Before this, `ObjectGantt`, `ObjectCalendar`, `ObjectMap` and `ObjectTree` each
|
|
197
|
+
issued a `find` with **no `$top` at all**, so the request returned the entire
|
|
198
|
+
filtered result set. At the 186 rows the card was filed from that is invisible;
|
|
199
|
+
on an object with 100k scheduled rows it is the whole table into the browser,
|
|
200
|
+
and nothing an author could write — `pagination.pageSize` included — could
|
|
201
|
+
bound a request that never carried a cap to begin with.
|
|
202
|
+
|
|
203
|
+
**What changed.** Those four fetches now ask for `NON_GRID_ROW_CEILING_TOP`
|
|
204
|
+
rows, draw at most `NON_GRID_ROW_CEILING` of them, and when the result set was
|
|
205
|
+
larger they render a footnote naming both numbers, verbatim as it renders:
|
|
206
|
+
*"Showing the first 2000 of 41234 records. Narrow the filter."* Below the
|
|
207
|
+
ceiling nothing changes: the full set draws and no footnote appears.
|
|
208
|
+
|
|
209
|
+
The four view packages take a **minor**, not a patch: a result set above the
|
|
210
|
+
ceiling is no longer drawn in full, which is a behaviour break whatever the
|
|
211
|
+
fixed group does to the released version number.
|
|
212
|
+
|
|
213
|
+
**The ceiling is a platform constant, not an authorable key** — `2000`, exported
|
|
214
|
+
from `@object-ui/react` as `NON_GRID_ROW_CEILING`. An authored `limit` or
|
|
215
|
+
`dataSource: { limit }` still does not reach these queries, by the same ruling;
|
|
216
|
+
three alternatives were rejected with it (a documentation note only — still the
|
|
217
|
+
whole table; truncating at `pageSize` — silent, and a complete schedule capped
|
|
218
|
+
at one page; an authorable `maxRows` — a new permanent key every author sets).
|
|
219
|
+
|
|
220
|
+
**Why 2,000.** One constant for all four, so the binding view sets it. Measured
|
|
221
|
+
in this repo's jsdom lane: gantt, calendar and map hold their DOM flat as rows
|
|
222
|
+
grow (virtualised task list; four events per day cell; auto-clustering above
|
|
223
|
+
100 markers), while `ObjectTree` flattens every expanded node into the document
|
|
224
|
+
at a linear **5.2 DOM elements per record** with no virtualisation. 2,000 rows
|
|
225
|
+
is where the worst of the four lands at ~10,400 elements — an order of
|
|
226
|
+
magnitude above Lighthouse's "excessive DOM size" warning, and still ~10x the
|
|
227
|
+
real application result set this card came from.
|
|
228
|
+
|
|
229
|
+
New exports on `@object-ui/react`: `NON_GRID_ROW_CEILING`,
|
|
230
|
+
`NON_GRID_ROW_CEILING_TOP`, `applyNonGridRowCeiling`, `NonGridRowCeilingNote`
|
|
231
|
+
and the type `NonGridCeilingResult`. Two new `common.*` i18n keys carry the
|
|
232
|
+
footnote copy in all ten packs.
|
|
233
|
+
- b041b9c: `@object-ui/core` publishes `resolveRecordSourceObjectName`, the ONE reader for "which
|
|
234
|
+
object is this block bound to".
|
|
235
|
+
|
|
236
|
+
Six view plugins each spelled that resolution locally — `ObjectCalendar` twice,
|
|
237
|
+
`ObjectGantt`, `ObjectTree` twice, `ObjectMap`, `ObjectGrid` — and had drifted: three
|
|
238
|
+
wrote `?? schema.objectName`, one `|| ''`, one `: undefined`, one an `'object' in
|
|
239
|
+
dataConfig` test. They now delegate to one function that states the published
|
|
240
|
+
record-source ladder `77cb489b4` declared (`data`, then `staticData`, then `objectName`) once.
|
|
241
|
+
|
|
242
|
+
**No behaviour changes.** Each site's pre-collapse expression is transcribed verbatim
|
|
243
|
+
into `record-source.behaviourNeutrality-7627.test.ts` and asserted equal to its
|
|
244
|
+
post-collapse spelling across the whole contract-valid input matrix — both bindings
|
|
245
|
+
present, data only, `objectName` only, empty `objectName`, empty `data.object`, the
|
|
246
|
+
`api` / `value` / `staticData` / array-shorthand providers, and nothing bound.
|
|
247
|
+
|
|
248
|
+
**Two questions stay two questions.** `normalizeListViewSchema`'s gap-fill (#7477,
|
|
249
|
+
ruling B, landed as `00d2fa682`) is untouched and is NOT re-pointed at the new reader: it answers
|
|
250
|
+
how `objectName` gets POPULATED when absent, where an already-present `objectName` wins.
|
|
251
|
+
The new reader answers which object a block RESOLVES, where the `data` block wins — the
|
|
252
|
+
order declared on both published faces in `@object-ui/types` and pinned by
|
|
253
|
+
`objectql-record-source-refinement-6939.test.ts`. Merging them would silently override
|
|
254
|
+
one standing ruling or the other.
|
|
255
|
+
|
|
256
|
+
**`ObjectGantt`'s `persistLayoutKey` is deliberately excluded** and keeps its inverted
|
|
257
|
+
order, with an in-place comment saying why: its receiver is a localStorage key
|
|
258
|
+
(`gantt-layout:KEY:filters`), not a record source, so re-pointing it would orphan every
|
|
259
|
+
saved layout and filter-chip set of a view carrying both bindings. Two more sites the
|
|
260
|
+
finding listed are not object-name readers at all and were struck: `ObjectGantt`'s
|
|
261
|
+
refresh-handler predicate (`object` OR `api`) and `plugin-dashboard`'s `isObjectProvider`
|
|
262
|
+
type-guard over a widget's `data`.
|
|
263
|
+
|
|
264
|
+
`useSettledSchema`'s doc comment stops prescribing the hand-written ladder at all four
|
|
265
|
+
lines that taught it, so the copies cannot re-seed from the hook that replaced them.
|
|
266
|
+
- 846cec0: **Breaking behaviour change — `object-tree` now honours only the `data` spelling its published row declares.**
|
|
267
|
+
|
|
268
|
+
Decision batch #83, maintainer verbatim 「8348 以协议为准」: a view block honours the `data` spelling its block's published row declares, and no other. `object-tree` was the one ladder block that ruling could not reach, because no published face declared a `data` row for it, so it honoured ANY truthy `data`. Ruling batch #136 item 3 (Q1-C) had the protocol gain the row, and `ComponentPropsMap['object-tree']` in the installed `@objectstack/spec` declares `data` as the `ViewData` union and `staticData` as an array. The ruling's 「协议没有的能力删」 clause did not fire — the row does declare `data` — so the tree keeps the object form and loses only the bare-array spelling.
|
|
269
|
+
|
|
270
|
+
- `data: { provider: 'value', items: [...] }`, `{ provider: 'object', object }` and `{ provider: 'api', … }` — **unchanged**, still the tree's first record source.
|
|
271
|
+
- `staticData: [...]` — **unchanged**; the same row declares it, and it is still the second rung.
|
|
272
|
+
- ⚠️ `data: [...]` (a bare array) — **no longer a record source.** The ladder falls through to `staticData`, then `objectName`: such a tree queries its object instead, or draws `No records` when it names neither. In a development build `SchemaRenderer` says so once, naming the key and the spelling that works; in production it is quiet. This is the same outcome `object-map` and `object-gantt` already give for the same spelling. Stored documents authored that way stop drawing those rows — accepted by the ruling, with no transition window. Move inline rows to `staticData` or to `data: { provider: 'value', items }`.
|
|
273
|
+
- The `data` **prop** a host hands down (`ListView`'s tree) is untouched.
|
|
274
|
+
|
|
275
|
+
Two carriers had to close for this to be observable. `@object-ui/core`'s `recordSourceDataArmForType` now answers `'view-data'` for all four spellings the tree registers under (`object-tree`, `plugin-tree:object-tree`, `tree`, `view:tree`), so `SchemaRenderer` no longer spreads an authored `data` on a tree node as a React prop (objectui#9571). And `ObjectTree`'s own fetch effect no longer reads `schema.data` beside the host prop — that second reader bypassed the shared ladder, so an arm change alone would have removed nothing end to end.
|
|
276
|
+
|
|
277
|
+
⚠️ **Dated note, 2026-10-02 — two of the four spellings are retired — objectui#10859.**
|
|
278
|
+
Later in this same release objectui#10859 batch 8 unregistered the bare `tree` alias, and with it
|
|
279
|
+
`view:tree`; `recordSourceDataArmForType` answers `'view-data'` for `object-tree` and
|
|
280
|
+
`plugin-tree:object-tree` only. The rest of this entry is kept as the reading of this change.
|
|
281
|
+
- 91facae: **Breaking behaviour change — a view block now honours only the `data` spelling its published row declares.**
|
|
282
|
+
|
|
283
|
+
Maintainer ruling, decision batch #83 (2026-09-08), verbatim 「8348 以协议为准」: the contract decides. What `os validate` and the save gate refuse under `data`, the renderer refuses too. The shared record-source ladder (`resolveRecordSourceConfig` in `@object-ui/core`) now takes the arm the calling block's row declares, and rung 1 applies only on that arm.
|
|
284
|
+
|
|
285
|
+
⚠️ **`object-calendar` documents authored against the tolerated spelling stop rendering those rows.** The ladder falls past `data` to `staticData`, then to `objectName` — so such a calendar queries its object instead, or draws nothing when it names neither. This is accepted, with no transition window and no staged deprecation (the standing 2026-08-27 posture).
|
|
286
|
+
|
|
287
|
+
**Per block — what the published row says, and what actually moves:**
|
|
288
|
+
|
|
289
|
+
- **`object-calendar`** — row: `ComponentPropsMap['object-calendar'].data` is `z.array(z.unknown())` ("Pre-fetched records — skips the internal fetch"). A record-source **config object** under `data` — `{ provider: 'value', items }`, `{ provider: 'object', object }`, `{ provider: 'api', … }` — is no longer honoured, and this is a real end-to-end change: that object had exactly one carrier into the block, so an authored calendar written that way now queries its object (or draws nothing) instead of drawing the authored rows. There is no longer an api-provider branch to reach here. An **array** under `data` is unchanged, as are `staticData` and `objectName`.
|
|
290
|
+
- **`object-grid`** — row: the `ViewData` union, whose own description says "the bare-array shortcut is refused". `getDataConfig`'s `Array.isArray(schema.data)` head is removed, so the array is no longer a record source at the ladder. ⛔ Measured: this is **not** an end-to-end change for a node rendered through `SchemaRenderer`. An authored `data` array also arrives on the **props channel** (`SchemaRenderer` spreads node keys as props; `ObjectGrid`'s `passedData` lifts an array at higher priority), so such a grid still drew its rows when this landed. The removal took the second read, not the last one; objectui#9571 closed the props carrier afterwards.
|
|
291
|
+
- **`object-map`** — no `ComponentPropsMap` row existed when this landed; the governing row was this repo's own `ObjectMapSchema.data`, `ViewDataSchema.optional()` (the protocol row has since been published, and is the `ViewData` union too). Its array-shorthand head is removed on the same terms, with the same measured caveat at the time: through `SchemaRenderer` the props channel still drew an authored array, until objectui#9571. `data: { provider: 'value', items }` and `staticData` are unchanged.
|
|
292
|
+
- **`object-gantt`** — no `ComponentPropsMap` row when this landed; the governing row was `ObjectGanttSchema.data`, `ViewDataSchema.optional()` (the protocol row has since been published, and is the `ViewData` union too). A bare array under `data` is no longer a record source. Nothing observable moves: this block never lifted one, the array carried no `provider` and matched no fetch branch, and its renderer forwards no host props.
|
|
293
|
+
- **`object-tree`** — **unchanged by this change.** When it landed, no published face declared a `data` row for this block: not `ComponentPropsMap`, not `ObjectTreeSchema` (which declares `objectName` required and no `data`), not its registration `inputs`. Neither arm of the ruling reached it, so its rung 1 kept its previous behaviour and the block was reported rather than guessed at. Once the protocol published `ComponentPropsMap['object-tree']`, the tree moved to the `ViewData` arm too — see the separate `object-tree` entry for objectui#8348.
|
|
294
|
+
|
|
295
|
+
The `data` **prop** — the pre-fetched rows a host such as `ObjectView` or `ListView` passes down — is a different carrier and is untouched on every block. That it is also reachable from an authored node key, because `SchemaRenderer` spreads node keys as props, is what limits the grid and map halves above; it is reported on objectui#8348 rather than changed here.
|
|
296
|
+
- 009f92d: `ObjectTreeProps.schema` is the published `object-tree` node instead of `any`,
|
|
297
|
+
and `getTreeConfig`'s parameter with it (objectui#8655).
|
|
298
|
+
|
|
299
|
+
The type WAS DERIVED rather than written out: `Extract< ObjectQLComponentSchema, { type:
|
|
300
|
+
'object-tree' } >`, the spelling that union's own docblock teaches. So every key
|
|
301
|
+
name and key type still has exactly one declaration, `ObjectTreeSchema` in
|
|
302
|
+
`@object-ui/types`, and a key added or retyped there arrives here without an
|
|
303
|
+
edit. `Extract` rather than a named import because, when this landed, the TS barrel did
|
|
304
|
+
not export `ObjectTreeSchema` — the zod barrel did, and its eleven sibling arms
|
|
305
|
+
were all on the TS one. Repairing that omission was a published-surface addition
|
|
306
|
+
on another package, so it was reported rather than smuggled in here, and
|
|
307
|
+
objectui#9550 took it: the name is on that barrel in THIS SAME RELEASE and this
|
|
308
|
+
package now imports it — see that entry. ⚠️ So the derivation described above is the
|
|
309
|
+
state this card left behind, ⛔ not the state being released; the shipped code reads
|
|
310
|
+
as a named import. The claim that survives both spellings is the one that mattered:
|
|
311
|
+
one declaration, `ObjectTreeSchema`, and no copy of it here.
|
|
312
|
+
|
|
313
|
+
Accept-set change on the published props type, stated plainly:
|
|
314
|
+
|
|
315
|
+
- NARROWS. `any` accepted everything; the node accepts what `ObjectTreeSchema`
|
|
316
|
+
declares plus anything `BaseSchema`'s `[key: string]: any` admits. Breaking
|
|
317
|
+
for a TypeScript consumer that passed a value the node schema refuses at a
|
|
318
|
+
DECLARED key — `labelField` and `fields` are the two that can bite, since the
|
|
319
|
+
renderer tolerates host column OBJECTS there while the declaration says
|
|
320
|
+
`string` / `string[]`. This package's own test carried exactly that shape and
|
|
321
|
+
now says so at the mount rather than compiling silently.
|
|
322
|
+
- No runtime behaviour changes. One `as any` is removed at a read site and one
|
|
323
|
+
is deliberately kept; both are casts, neither is a value.
|
|
324
|
+
|
|
325
|
+
Why the type had to come first: the two reads this card was filed on were
|
|
326
|
+
reported UNANSWERABLE, not undeclared. Through `any`, `checker.getPropertyOfType`
|
|
327
|
+
returns `undefined` for a key the node certainly declares exactly as it does for
|
|
328
|
+
a nonsense token, so no verdict was available at all. Typed, the checker answers,
|
|
329
|
+
and the two answers point in opposite directions — `data` is DECLARED (on
|
|
330
|
+
`BaseSchema`), so its cast is gone; `navigation` is genuinely undeclared and its
|
|
331
|
+
cast stays, marking the read rather than hiding it.
|
|
332
|
+
|
|
333
|
+
What the re-measurement then surfaced, reported rather than tidied: six more
|
|
334
|
+
reads became answerable, five declared and one — `filter` — not. Its verdict is
|
|
335
|
+
declare-by-mirror-alignment and it is ⛔ NOT executed here, because the two files
|
|
336
|
+
that would carry it are held by an in-flight branch; the ledger row in
|
|
337
|
+
`ObjectTree.schemaTyped-8655.test.ts` reddens the day it lands. `tree` is
|
|
338
|
+
declared by the protocol on the VIEW and on zero element faces, so declaring it
|
|
339
|
+
on the node would fork rather than mirror the contract, and retiring the read
|
|
340
|
+
needs a producer census a text search cannot make. `navigation` belongs to a
|
|
341
|
+
blocked card and is ledgered, ⛔ not ruled.
|
|
342
|
+
|
|
343
|
+
Nothing in `@object-ui/types` is declared, widened or narrowed by this change.
|
|
344
|
+
|
|
345
|
+
**Note, 2026-10-01 (objectui#11168 slice 3, shipping in this same release).**
|
|
346
|
+
The `navigation` and `tree` readings above changed after this entry was written.
|
|
347
|
+
`@objectstack/spec` 17.5.0 gave `object-tree` an element row, and that row
|
|
348
|
+
declares both keys, so both verdicts here were re-run on that contract.
|
|
349
|
+
- `navigation` is DECLARED on `ObjectTreeSchema` as the spec's
|
|
350
|
+
`NavigationConfig`, and the cast this entry says "stays" is gone.
|
|
351
|
+
- `tree` is DECLARED as the spec's `TreeConfig`, by reference. Mirroring the
|
|
352
|
+
element row is not the fork described above.
|
|
353
|
+
- `ObjectTreeSchema` also declares `data` as `ViewData` (not `BaseSchema`'s
|
|
354
|
+
untyped `data`) and `staticData`, and `objectName` is optional.
|
|
355
|
+
|
|
356
|
+
So the sentences above that say these keys are undeclared describe the tree at
|
|
357
|
+
objectui#8655, not the code in this release. See that slice's changesets for
|
|
358
|
+
`@object-ui/types` and `@object-ui/plugin-tree`.
|
|
359
|
+
- 2f6b2bf: Derive `TreeViewConfig` from `@objectstack/spec` and drop `titleField`, the key the
|
|
360
|
+
protocol refuses on `ListView.tree` (objectui#8841).
|
|
361
|
+
|
|
362
|
+
**What was wrong.** `@object-ui/types` published `TreeViewConfig` as a hand-written
|
|
363
|
+
interface — a copy of the protocol's `ListView.tree` block under a second name — and the
|
|
364
|
+
copy declared a fifth key, `titleField`. `@objectstack/spec@17.4.0` refuses that key
|
|
365
|
+
there by name: `TreeConfigSchema` is a `strictObject` since spec objectstack#15469 closed the
|
|
366
|
+
`.passthrough()` window 17.3.0 left open. So this package's published face accepted what
|
|
367
|
+
the contract rejects, and an author who followed `@object-ui/types` was refused at
|
|
368
|
+
publish with `Unrecognized key(s) on this tree configuration: 'titleField'`. The copy was
|
|
369
|
+
invisible to `scripts/check-spec-symbol-derivation.mjs`, which matches spec symbols BY
|
|
370
|
+
NAME — a hand copy renamed away from the spec's symbol has nothing for its rule 1 to
|
|
371
|
+
match (objectui#4592's recorded blind spot).
|
|
372
|
+
|
|
373
|
+
**The grades, and why.**
|
|
374
|
+
|
|
375
|
+
- `@object-ui/types` — **minor**. `TreeViewConfig` is now
|
|
376
|
+
`NonNullable<ListView['tree']>` from `@objectstack/spec/ui`, and `titleField` is
|
|
377
|
+
removed from a **published** exported type. That is breaking for a producer that
|
|
378
|
+
annotates a `tree` block carrying the key; per this repo's version-alignment policy
|
|
379
|
+
(AGENTS.md — objectui's major tracks `@objectstack`'s) objectui's own breaking changes
|
|
380
|
+
ship as `minor` with the breaking semantics stated here. The precedent is the same
|
|
381
|
+
shape: `Remove the retired striped / bordered / virtualScroll list-view surface`
|
|
382
|
+
(`@object-ui/types` 17.6.0, minor) propagated a spec-side retirement into this package
|
|
383
|
+
the same way.
|
|
384
|
+
- `@object-ui/plugin-tree` — **minor**. `getTreeConfig`'s `labelField` chain loses its
|
|
385
|
+
third rung, `?? schema.titleField`. That rung read the flattened **node**, never the
|
|
386
|
+
block, and `titleField` is declared on neither face — not on `ObjectTreeSchema` (the TS
|
|
387
|
+
interface or its zod mirror) and not on the protocol's `ListView.tree`. It is a runtime
|
|
388
|
+
behaviour change, graded like one. The README's claim that this block is "the single
|
|
389
|
+
declaration of that shape" is corrected in the same stroke: the protocol owns it, and
|
|
390
|
+
this package publishes it derived.
|
|
391
|
+
- `@object-ui/plugin-view` — **patch**. `ObjectViewProps.views[n].tree` still resolves to
|
|
392
|
+
`TreeViewConfig`; what it admits narrows with the type. Type-only, no runtime change.
|
|
393
|
+
- `@object-ui/app-shell` — **patch**. The console's `tree` composition keeps both rungs;
|
|
394
|
+
only the second one's annotation changes (see below). No runtime change.
|
|
395
|
+
|
|
396
|
+
**The tolerant reads are kept, and deliberately left undeclared.** Three
|
|
397
|
+
`labelField || titleField` dual-reads survive — `plugin-view`'s and `plugin-list`'s
|
|
398
|
+
`'tree'` branches and the console's own composition in `app-shell` — so a view record
|
|
399
|
+
that already stores `tree.titleField` keeps resolving exactly as before, and
|
|
400
|
+
objectui#6557's pin on that rung stays green. They read through `any` now; the console's
|
|
401
|
+
canonical rung stays annotated `TreeViewConfig` while its legacy rung is not, because
|
|
402
|
+
casting it to a type that no longer carries the key cannot compile and re-declaring the
|
|
403
|
+
key locally would fossilise a renderer-side alias into a second contract — the AGENTS.md
|
|
404
|
+
#0.1 defect this change undoes. Retiring those three reads is a follow-up.
|
|
405
|
+
|
|
406
|
+
**Migration.** A host that writes `tree.titleField` should write `tree.labelField`, which
|
|
407
|
+
is the protocol's spelling and already wins wherever both are present. Nothing that
|
|
408
|
+
renders today stops rendering; what changes is that the key is now reported at compile
|
|
409
|
+
time by the same face that will refuse it at publish, instead of only at publish.
|
|
410
|
+
- 9c08dc6: Honour `filter` and the platform row ceiling on a tree's inline
|
|
411
|
+
(`provider: 'value'`) data (objectui#9136) — the fourth surface of the
|
|
412
|
+
objectui#8769 repair, after objectui#9061 ported it to `ObjectCalendar` and
|
|
413
|
+
`ObjectMap`.
|
|
414
|
+
|
|
415
|
+
**The defect was fail-open.** `ObjectTree`'s record effect set the authored rows
|
|
416
|
+
and returned on the inline provider without reaching the query in its `object`
|
|
417
|
+
arm, which is the one site in the file that lowers `schema.filter` to `$filter`
|
|
418
|
+
and the objectui#7210 ceiling to `$top`. So an inline tree that declared a
|
|
419
|
+
`filter` drew **every** authored row, with no diagnostic. The key that was
|
|
420
|
+
dropped is the key that NARROWS: the view answered a wider question than the
|
|
421
|
+
author asked. Nothing was exposed that was not already in the authored schema —
|
|
422
|
+
this is a correctness defect, not a data-access one.
|
|
423
|
+
|
|
424
|
+
**What changed.** The inline provider resolves a `ValueDataSource` over its own
|
|
425
|
+
rows and issues the same query the `object` arm issues (`$filter`, `$top`), then
|
|
426
|
+
goes through the same `applyNonGridRowCeiling`. Two keys, not the siblings'
|
|
427
|
+
three: `ObjectTree` reads `sort` on no provider, so nothing about ordering moves.
|
|
428
|
+
No dependency array moves, and the `object` provider is untouched.
|
|
429
|
+
|
|
430
|
+
**Behaviour you may notice.** This is a behaviour change on inline trees, and
|
|
431
|
+
it is declared `minor`, as objectui#9061 declared the same change on the
|
|
432
|
+
calendar and map:
|
|
433
|
+
|
|
434
|
+
- An authored `filter` now narrows inline rows, on both inline spellings —
|
|
435
|
+
`data: { provider: 'value', items }` and `staticData`.
|
|
436
|
+
- The row ceiling now applies to inline rows: past `NON_GRID_ROW_CEILING`
|
|
437
|
+
(`@object-ui/react`) rows the tree draws that many and shows the footnote
|
|
438
|
+
naming both numbers, as it already did for fetched rows. The tree is the view
|
|
439
|
+
that ceiling's value was measured on. It is applied to the **filtered** set,
|
|
440
|
+
so a large inline array that a `filter` cuts below the ceiling draws every
|
|
441
|
+
matching row and stays quiet.
|
|
442
|
+
- Rows a host passes down through the `data` React prop, or as a bare array
|
|
443
|
+
under `schema.data`, are unchanged: that passthrough sits above the inline
|
|
444
|
+
branch and is still never filtered or capped here.
|
|
445
|
+
- Inline rows now reach the tree as the adapter's own deep copy
|
|
446
|
+
(`structuredClone`, objectui#9175) rather than as the authored array's object
|
|
447
|
+
identities. A row handed to `onRowClick` is that copy, so code comparing it
|
|
448
|
+
against the authored array with `===` needs `id` equality instead. A record
|
|
449
|
+
graph carrying a back-reference still renders; a function-valued key in an
|
|
450
|
+
inline row now fails loudly with the tree's error panel instead of rendering.
|
|
451
|
+
- 7098eed: One record-overlay shell: all five list-type renderers honour all four overlay
|
|
452
|
+
`navigation.mode` values (objectui#9299, director seat decision batch #128 item
|
|
453
|
+
1, 2026-09-13).
|
|
454
|
+
|
|
455
|
+
`ObjectGantt`, `ObjectKanban` and `ObjectCalendar` rendered one drawer for every
|
|
456
|
+
authored mode — `modal`, `split` and `popover` silently WERE the drawer, with no
|
|
457
|
+
diagnostic. `RecordDetailDrawer`'s payload is extracted into the new
|
|
458
|
+
`RecordDetailPanel` (shell-free by construction) and mounted through the shared
|
|
459
|
+
`NavigationOverlay`, which is what `ObjectGrid` and `ObjectTree` already used.
|
|
460
|
+
|
|
461
|
+
User-visible on published surfaces:
|
|
462
|
+
|
|
463
|
+
- **`modal` / `split` / `popover` now do what they say** on the gantt, the
|
|
464
|
+
kanban and the calendar.
|
|
465
|
+
- **`split` renders.** Each renderer passes its own view as `mainContent`, so
|
|
466
|
+
the board / calendar / chart / tree / grid sits beside the record panel.
|
|
467
|
+
Authored `split` used to render NOTHING on `ObjectTree` — and, measured while
|
|
468
|
+
fixing this, on `ObjectGrid` too.
|
|
469
|
+
- **`popover` is anchored to the element the user clicked** — row, node, bar,
|
|
470
|
+
card, event — instead of degrading to a centred dialog. It was honoured on no
|
|
471
|
+
surface before.
|
|
472
|
+
- **Drawer chrome converges** on the shared shell's header (breadcrumb title,
|
|
473
|
+
close, optional expand) for the three renderers that brought their own.
|
|
474
|
+
- **Drawer widths carry over, they are not reset.** The two drag-resize
|
|
475
|
+
implementations become one: a width persisted under the retired
|
|
476
|
+
`objectui.drawerWidth.OBJECT` is read once, written forward to
|
|
477
|
+
`ov:drawer-width:OBJECT` and removed. One key per object across every view
|
|
478
|
+
type. The default width is unchanged at every viewport (objectui#6584); an
|
|
479
|
+
authored width below `min(60vw, 880px)` now widens to it, which is the shell's
|
|
480
|
+
long-standing policy on grid and tree.
|
|
481
|
+
- **Richer record body on grid and tree** — typed widgets, declared labels,
|
|
482
|
+
honoured `hidden` — wherever the object declares its fields. With nothing
|
|
483
|
+
declared those two renderers keep their own value-inference reading, which is
|
|
484
|
+
what preserves the locale-aware date fallback (objectui#4541), the localized
|
|
485
|
+
empty placeholder (objectui#8491) and the `format` hint (objectui#8920); the
|
|
486
|
+
overlay shell is the shared one on that path too.
|
|
487
|
+
|
|
488
|
+
New published API: `RecordDetailPanel`, `buildRecordDetailFields`,
|
|
489
|
+
`RECORD_OVERLAY_DEFAULT_WIDTH` (`@object-ui/plugin-detail`);
|
|
490
|
+
`useOverlayAnchor`, `recordOverlayWidthStorageKey`,
|
|
491
|
+
`legacyRecordDrawerWidthKey` and the `popoverAnchorRef` / `legacyStorageKey`
|
|
492
|
+
props on `NavigationOverlay` (`@object-ui/components`). `RecordDetailDrawer`
|
|
493
|
+
keeps its props and is now a thin wrapper over the shared shell. ⛔ No spec
|
|
494
|
+
change.
|
|
495
|
+
- 502eb58: The row/card click props on the view components now declare the modifier
|
|
496
|
+
payload they have always been invoked with (objectui#9357).
|
|
497
|
+
|
|
498
|
+
`useNavigationOverlay`'s `handleClick` invokes the handler it is given with two
|
|
499
|
+
arguments — the record, and an optional modifier payload (`metaKey` / `ctrlKey`
|
|
500
|
+
/ `button`) a host needs to implement Cmd/Ctrl/middle-click. objectui#9360 made
|
|
501
|
+
the hook's own option say so. These components pass a host-supplied prop
|
|
502
|
+
straight into that option, so the value a host writes against them is invoked
|
|
503
|
+
with two arguments too — and every one of these props declared only the record.
|
|
504
|
+
The payload was therefore invisible on the one line a host reads, exactly as it
|
|
505
|
+
had been on the hook.
|
|
506
|
+
|
|
507
|
+
Thirteen declarations across nine packages now name both parameters:
|
|
508
|
+
|
|
509
|
+
- `ObjectGridComponentProps.onRowClick`
|
|
510
|
+
- `ObjectKanbanComponentProps.onRowClick` (its sibling `onCardClick`, the other
|
|
511
|
+
arm of the same fallback, already declared both)
|
|
512
|
+
- `KanbanRendererProps.schema.onCardClick`
|
|
513
|
+
- `ObjectCalendar`, `ObjectGantt`, `ObjectMap`, `ObjectTree`: `onRowClick`
|
|
514
|
+
- `ObjectTimeline`: `onRowClick` and `onItemClick`, the two arms of one fallback
|
|
515
|
+
- `ListView.onRowClick`
|
|
516
|
+
- `ObjectGallery`: `onRowClick` and `onCardClick`, likewise two arms of one
|
|
517
|
+
- `RelatedList.onRowClick`
|
|
518
|
+
|
|
519
|
+
**Source-compatible, and with no refused class.** A one-parameter handler is
|
|
520
|
+
still assignable to the widened signature, and a handler written against the
|
|
521
|
+
widened signature was already assignable to the narrow one — its minimum
|
|
522
|
+
argument count is still one. The second parameter is spelled `any` rather than
|
|
523
|
+
`HandleClickModifiers`, which is the difference that matters for callers: the
|
|
524
|
+
hook's own option names that interface and therefore refuses a handler whose
|
|
525
|
+
second parameter is annotated narrower (objectui#9360 documents that class and
|
|
526
|
+
the one-line remedy). These faces refuse nothing. A host that discovered the
|
|
527
|
+
payload from the implementation and annotated it `React.MouseEvent` — which is
|
|
528
|
+
what actually arrives — keeps compiling. `any` is also the spelling
|
|
529
|
+
`ObjectKanbanSchema.onCardClick` already carries for this same payload
|
|
530
|
+
(objectui#9341) and the one `BaseSchema`'s own `onClick` / `onChange` /
|
|
531
|
+
`onSubmit` use, and it is forced on the published twins in `@object-ui/types`,
|
|
532
|
+
which may not name a type that lives in a package depending on them.
|
|
533
|
+
|
|
534
|
+
**Runtime behaviour is unchanged.** Nothing is newly called and nothing newly
|
|
535
|
+
passes an argument; only the declarations move.
|
|
536
|
+
|
|
537
|
+
Three declarations that share the name and the shape are deliberately NOT
|
|
538
|
+
widened, because the value flowing through them is not invoked with the
|
|
539
|
+
payload: `VirtualGrid.onRowClick`, whose second parameter is a row index;
|
|
540
|
+
`ManageViewsDialog.onRowClick`, which receives a view id; and the `data-table`
|
|
541
|
+
family (`DataTableSchema.onRowClick`, `ObjectDataTableSchema.onRowClick`),
|
|
542
|
+
whose renderer invokes with one argument. Widening those would have declared a
|
|
543
|
+
payload that never arrives.
|
|
544
|
+
- d16d0e9: `ObjectTreeSchema.filter` is declared on both faces, in the shape objectui#9309
|
|
545
|
+
settled for `ObjectGallerySchema.filter`: `QueryParams['$filter']` by indexed
|
|
546
|
+
access on the TS interface in `objectql.ts`, and the same two-arm union (array
|
|
547
|
+
first) on the zod mirror in `zod/objectql.zod.ts` (objectui#9549).
|
|
548
|
+
|
|
549
|
+
The key was already delivered and read before it was declared. `ListView` puts
|
|
550
|
+
`filter` on the `baseProps` every child view receives, and `ObjectTree` sends
|
|
551
|
+
`$filter: schema.filter` on its own fetch. Until now the value survived only on
|
|
552
|
+
`BaseSchema`'s `[key: string]: any` and the mirror's `.passthrough()`.
|
|
553
|
+
|
|
554
|
+
Accept-set change on the published surface, stated plainly:
|
|
555
|
+
|
|
556
|
+
- NARROWS, both faces. `filter: 'stage=won'` and `filter: 42` are type errors
|
|
557
|
+
now, and the mirror refuses them at parse time instead of keeping them
|
|
558
|
+
unjudged. Breaking for any TypeScript consumer that assigned a non-object
|
|
559
|
+
value to this key on an `object-tree` node.
|
|
560
|
+
- Both object arms still compile and parse: the ObjectQL field-keyed record
|
|
561
|
+
(`{ age: { $gt: 18 } }`) and the spec's `FilterArray` sugar
|
|
562
|
+
(`[['status', '=', 'active']]`).
|
|
563
|
+
|
|
564
|
+
`@object-ui/plugin-tree`: the renderer no longer reads the tree block from
|
|
565
|
+
`filter.tree`. It used to resolve the block as `schema.tree`, falling back to a
|
|
566
|
+
`tree` member of `schema.filter`; that second dialect treated the query filter
|
|
567
|
+
as a holder of tree config. Measured before removal: no example, fixture, test
|
|
568
|
+
or doc authors a `tree` under `filter`, and the arm dates from the renderer's
|
|
569
|
+
first commit with no stated reason. Author the block as `tree`. A node that put
|
|
570
|
+
it under `filter` now gets the auto-detected parent field and the default label
|
|
571
|
+
column, and the `filter` object is still forwarded as `$filter`.
|
|
572
|
+
|
|
573
|
+
### Patch Changes
|
|
574
|
+
|
|
575
|
+
- f9c06ef: Every data node that sends its own authored `filter` into a query now resolves the spec's context tokens first (objectui#10666). With `filter: [['owner', '=', '{current_user_id}']]` these nodes used to send the literal token; they now send the signed-in user's id, and `{current_org_id}` resolves to the active organization:
|
|
576
|
+
|
|
577
|
+
- `object-calendar`, `object-map` and `object-tree`, on both the object query and the inline (`provider: 'value'`) query;
|
|
578
|
+
- `object-gantt`, `object-kanban` and `object-timeline`;
|
|
579
|
+
- `record:related_list` and `record:line_items`, where the node's own filter is combined with the parent-record condition;
|
|
580
|
+
- the `element:repeater`, `element:number` (both the `aggregate` filter and the `find` fallback) and `element:record_picker` page elements.
|
|
581
|
+
|
|
582
|
+
`list-view`, `object-grid` and `object-gallery` already did this, and are unchanged.
|
|
583
|
+
|
|
584
|
+
**New in `@object-ui/react`: `useResolvedFilter(filter, scope)`.** Pass it a node's authored filter and `useFilterScope()`. It resolves the filter through `@object-ui/core`'s shared `resolveFilterPlaceholders` and holds the result: re-rendering with an equal filter (even one rebuilt inline on every render) hands back the same value, so a fetch effect keyed on it does not run again, while a structurally different filter or a change of signed-in user or organization resolves again. A filter with no token to resolve is handed back as the value you passed in. The hold is the one `list-view` and `object-gallery` used privately; `plugin-list` now imports it from here, and no second copy remains in that package.
|
|
585
|
+
|
|
586
|
+
What changes for an app:
|
|
587
|
+
|
|
588
|
+
- A filter with no placeholders reaches the query as before, unchanged.
|
|
589
|
+
- Nodes that re-queried whenever the host rebuilt an equal filter inline (`object-calendar`, `object-gantt`, `object-kanban`, `object-map`, `object-tree`) no longer issue those redundant queries.
|
|
590
|
+
- Date macros such as `{today}` in these nodes' own filters are now resolved in the browser's local time, as they already are for `list-view`, `object-grid` and `object-view`. Before, they reached the server as literals, and the server resolved them in the tenant's time zone.
|
|
591
|
+
|
|
592
|
+
`@object-ui/types`: the `filter` docblocks on `ObjectMapSchema`, `ObjectTreeSchema`, `ObjectGanttSchema`, `ObjectCalendarSchema`, `ObjectKanbanSchema`, `ObjectChartSchema` and `ObjectGallerySchema` (and the matching zod descriptions) no longer say the filter is forwarded verbatim; they say its context tokens are resolved first. No type changes.
|
|
593
|
+
- 8c3d7fc: fix(plugin-tree): `object-tree` re-reads its rows on the data-invalidation bus
|
|
594
|
+
|
|
595
|
+
The record effect of `ObjectTree` now names the `useDataInvalidation` nonce for
|
|
596
|
+
the object its `object` provider queries — whether the node spells it
|
|
597
|
+
`objectName` or `data: { provider: 'object', object }` — so a write declared on
|
|
598
|
+
the bus (`notifyDataChanged`, as a page action over raw HTTP does) re-reads the
|
|
599
|
+
tree in place, keeping the user's expansion choices. Before, a tree that no
|
|
600
|
+
host handed rows to refreshed after such a write only when its host remounted
|
|
601
|
+
it, and `PageView` is about to stop doing that (objectui#10519).
|
|
602
|
+
|
|
603
|
+
Inline rows (a `data` array, the `value` provider) name no object and do not
|
|
604
|
+
subscribe. A tree whose host hands down rows (the `list-view` tree) subscribes
|
|
605
|
+
too: it runs its own full query ahead of those rows, so its freshness does not
|
|
606
|
+
rest on the host's rows moving.
|
|
607
|
+
- 4d0af04: fix(plugin-tree): `object-tree` keeps its rows on screen while it re-reads them
|
|
608
|
+
|
|
609
|
+
`ObjectTree` drew its "Loading…" placeholder whenever a read was in flight, so
|
|
610
|
+
every re-read — each data-invalidation event for its object among them — took
|
|
611
|
+
the table off the screen and put it back: the rows flashed, and a scrolled tree
|
|
612
|
+
lost its scroll offset.
|
|
613
|
+
|
|
614
|
+
The placeholder is now drawn only while the tree has no rows for the source it
|
|
615
|
+
is bound to: the first load, a switch to another object or data provider, and an
|
|
616
|
+
empty result being re-read. A re-read of the same source keeps the rows, the
|
|
617
|
+
scroll container and the user's expansion choices on screen, with the shared
|
|
618
|
+
`RefreshIndicator` bar across the top of the tree while the read is in flight
|
|
619
|
+
(named through the locale's `grid.refreshing`). The previous object's rows are
|
|
620
|
+
never drawn under a new object or provider.
|
|
621
|
+
- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
|
|
622
|
+
every relative specifier, and a type error in the declaration build now fails the build
|
|
623
|
+
instead of being printed and ignored (objectui#5439, objectui#5483).
|
|
624
|
+
|
|
625
|
+
**Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
|
|
626
|
+
is the fix working.** These packages re-export mostly through NAMED re-exports —
|
|
627
|
+
`export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
|
|
628
|
+
extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
|
|
629
|
+
`any`. Nothing errored; consumers simply got no types. With the extension emitted, the
|
|
630
|
+
symbol carries its real type, and any call site that was relying on the `any` now type
|
|
631
|
+
checks for the first time. This is the mode that produced the 21 residual `TS7006` on
|
|
632
|
+
`@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
|
|
633
|
+
unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
|
|
634
|
+
immediately as `TS2305: has no exported member`.
|
|
635
|
+
|
|
636
|
+
410 extensionless relative specifiers across 19 packages were emitted before this change;
|
|
637
|
+
the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
|
|
638
|
+
`@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
|
|
639
|
+
is wired so it stays that way.
|
|
640
|
+
|
|
641
|
+
The second half changes no emitted output today: 22/22 packages built green unmodified, so
|
|
642
|
+
making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
|
|
643
|
+
regression does — print and exit 0, versus fail the build.
|
|
644
|
+
- b00fcba: `ObjectTree` formats its cells the way the flat table does: a lookup column renders the
|
|
645
|
+
referenced record's display name and a select column renders its translated option label,
|
|
646
|
+
instead of a raw record id and the raw stored value (objectui#6014).
|
|
647
|
+
|
|
648
|
+
Reported against the built-in 业务单元 (`sys_business_unit`) page, whose 「组织架构」 tree tab
|
|
649
|
+
showed the manager column as a bare user id and the type column as `department`, while the
|
|
650
|
+
flat-table tab on the same page — over the same expanded records — showed the user's name
|
|
651
|
+
and 「部门」.
|
|
652
|
+
|
|
653
|
+
The card carried its own control, and it pointed at the fetch rather than the formatter. The
|
|
654
|
+
tree treated "the host passed inline `data`" as "I do not need the object schema" and skipped
|
|
655
|
+
`getObjectSchema`, but its record-fetch branch prefers a live object dataSource over any
|
|
656
|
+
inline data. On the one mount shape `ListView` actually uses — `objectName` + a dataSource +
|
|
657
|
+
its own pre-fetched `data` — the tree therefore issued its OWN query with
|
|
658
|
+
`buildExpandFields(undefined)` → `[]` → no `$expand` at all, and had no field definitions to
|
|
659
|
+
format cells from. Both reported symptoms fall out of that single gap, which is why the flat
|
|
660
|
+
tab was unaffected and why the tree's existing tests (inline data, no dataSource — a path
|
|
661
|
+
that never runs the tree's own fetch) could not see it.
|
|
662
|
+
|
|
663
|
+
Three changes, all inside `packages/plugin-tree`:
|
|
664
|
+
|
|
665
|
+
- The object schema is fetched whenever the dataSource can serve one, not only when no host
|
|
666
|
+
passed inline data. The guard inside the fetch already no-ops without a dataSource, so the
|
|
667
|
+
pure inline/static path is unaffected.
|
|
668
|
+
- Records are no longer fetched until that schema has settled — settled, not necessarily
|
|
669
|
+
successful, so a rejected or inapplicable schema fetch can never block the tree. This also
|
|
670
|
+
removes a wasted first query whose lookup columns came back as bare ids and were painted
|
|
671
|
+
for a moment before the real query landed.
|
|
672
|
+
- Cell values route through a field-aware formatter that delegates both decisions rather than
|
|
673
|
+
re-deciding them: option labels through the `translateOptions` seam `ObjectGrid` already
|
|
674
|
+
uses for the flat tab (so both tabs read one `fieldOptions.*` i18n key, with the same
|
|
675
|
+
exact-then-case-insensitive match and `humanizeLabel` fallback as `SelectCellRenderer`), and
|
|
676
|
+
expanded references through `getRecordDisplayName`, the unified display-name resolver
|
|
677
|
+
(ADR-0079), with the family judged by `isExpandableFieldType` — the same predicate that
|
|
678
|
+
decided what to put in `$expand`.
|
|
679
|
+
|
|
680
|
+
No new exports and no new package dependencies: both resolvers were already published from
|
|
681
|
+
`@object-ui/core`, and `translateOptions` was already reachable through the `useSafeFieldLabel`
|
|
682
|
+
hook this component calls for its column headers.
|
|
683
|
+
|
|
684
|
+
One visible consequence beyond the report: an expanded record that comes back with no name-ish
|
|
685
|
+
field now reads as ADR-0079's `Record #<id>` floor — the string every other surface shows for
|
|
686
|
+
it — rather than as the bare id.
|
|
687
|
+
- 9abc02a: `ObjectTree` no longer queries a switched-to object with the previous object's
|
|
688
|
+
`$expand` set (objectui#6481).
|
|
689
|
+
|
|
690
|
+
The schema-settled gate was two separate pieces of state — the definition
|
|
691
|
+
(`objectSchema`) and a bare `schemaSettled` boolean that was set `true` in a
|
|
692
|
+
`finally` and never reset. Two independent values cannot express "settled, but
|
|
693
|
+
for a DIFFERENT object", so when the host swapped the bound object both effects
|
|
694
|
+
re-ran while the latch still read `true` from the previous object's settle and
|
|
695
|
+
the definition still held the previous object's fields. The tree issued
|
|
696
|
+
|
|
697
|
+
find(newObject, { $filter: …, $expand: [ …previous object's relation fields… ] })
|
|
698
|
+
|
|
699
|
+
— rejected or silently ignored depending on the adapter, plus the transient it
|
|
700
|
+
painted — before a correct second query followed.
|
|
701
|
+
|
|
702
|
+
`ObjectTree` now adopts `useSettledSchema` from `@object-ui/react` (the shared
|
|
703
|
+
resolution hook ruled in objectui#6482), replacing BOTH pieces of state with the
|
|
704
|
+
hook's single `{ key, def } | null`. Readiness is derived during render by
|
|
705
|
+
comparing the settled key against the currently bound object, so the gate closes
|
|
706
|
+
in the same commit that changes the object rather than one commit later — the
|
|
707
|
+
stale-key window is not merely fixed but unrepresentable.
|
|
708
|
+
|
|
709
|
+
Behaviour that deliberately does NOT change: the gate stays inside the
|
|
710
|
+
object-provider branch of the record effect (the inline/static branches issue no
|
|
711
|
+
metadata read and must not wait on one), and every exit still settles — no
|
|
712
|
+
`getObjectSchema`, no object name, or a rejected read each settle with no
|
|
713
|
+
definition, so a tree whose adapter serves no schema still queries instead of
|
|
714
|
+
waiting forever.
|
|
715
|
+
- 37200ee: Re-key `ObjectTree`'s record-fetch effect onto the primitive fields it
|
|
716
|
+
actually reads off `dataConfig` (`provider` / `object` / `items`) instead of
|
|
717
|
+
the whole memoised `dataConfig` object (objectui#6700, closing out the
|
|
718
|
+
census #6592 opened — the schema-resolution half of this component was
|
|
719
|
+
already re-keyed onto `useSettledSchema`'s primitive `schemaKey` by #6696).
|
|
720
|
+
|
|
721
|
+
`useMemo` carries no semantic guarantee — React is permitted to discard a
|
|
722
|
+
memo cache and recompute even when its dependency array compares equal to
|
|
723
|
+
the previous render, and the local `getDataConfig(schema)` helper builds a
|
|
724
|
+
fresh `{ provider, object }` / `{ provider, items }` wrapper object on every
|
|
725
|
+
call. So the record-fetch effect, keyed on `dataConfig` itself, was correct
|
|
726
|
+
only for as long as that identity happened to survive a discard: a
|
|
727
|
+
recompute alone (no author or caller action) was enough to re-run the
|
|
728
|
+
effect and issue an extra `dataSource.find` call. Keying the effect on the
|
|
729
|
+
primitives instead makes a cache discard a no-op, restoring `useMemo` to a
|
|
730
|
+
pure optimisation — mirroring the fix already shipped for `ObjectMap` /
|
|
731
|
+
`ObjectCalendar` / `ObjectGantt`.
|
|
732
|
+
|
|
733
|
+
No behaviour change for a schema whose `useMemo` caches survive normally;
|
|
734
|
+
the effect is unaffected by React discarding one.
|
|
735
|
+
- d327b9c: FLS-gate the `$expand` projection at the seven remaining `buildExpandFields`
|
|
736
|
+
call sites (objectui#7429).
|
|
737
|
+
|
|
738
|
+
objectui#7215 / PR #7229 gated the two projection sites in its scope
|
|
739
|
+
(`ObjectGrid`, `ListView`). objectui#7230 / PR #7428 gated four more
|
|
740
|
+
(`ObjectCalendar`, `ObjectGantt`, `RecordDetailView`, `DetailView`). This
|
|
741
|
+
closes the seven that were left: `ObjectKanban`, `ObjectTree`, `ObjectView`
|
|
742
|
+
(the non-grid record-fetch effect), `ObjectMap`, `ObjectGallery`,
|
|
743
|
+
`ObjectTimeline`, and the metadata-admin `PagePreview`'s record-binding fetch.
|
|
744
|
+
|
|
745
|
+
**All seven pass no column list at all**, which makes every one of them the
|
|
746
|
+
sharp shape: `buildExpandFields` reads an absent column list as "no column
|
|
747
|
+
restriction" and falls back to **every declared relation on the object**,
|
|
748
|
+
denied ones included. So each of these components asked the server to resolve
|
|
749
|
+
the object's full relation set by default, not by configuration — the
|
|
750
|
+
ordinary shape of each surface, not a corner of it.
|
|
751
|
+
|
|
752
|
+
**`PagePreview` is the one site where the judged principal is not the page's
|
|
753
|
+
eventual audience.** It calls the browser's own `fetch` with
|
|
754
|
+
`credentials: 'include'` rather than `DataSource.find`, so it runs under
|
|
755
|
+
whichever session is loading the Studio preview. Gating on that same session's
|
|
756
|
+
`usePermissions()` is still the correct principal: it is exactly the request
|
|
757
|
+
the browser is about to make, on its own credentials, regardless of who later
|
|
758
|
+
opens the published page.
|
|
759
|
+
|
|
760
|
+
**Reproduced before it was fixed**, as a failing test per site (and, for the
|
|
761
|
+
two sites — `ObjectView`, `PagePreview` — where the gate was implemented
|
|
762
|
+
before its test was run red, a reverse-verification: the gate was reverted,
|
|
763
|
+
all four denial-and-set pins on each went red, and the two deferral/positive
|
|
764
|
+
control pins stayed green, before the gate was restored).
|
|
765
|
+
|
|
766
|
+
**Grading, measured rather than assumed** — the same reading objectui#6898,
|
|
767
|
+
#7215 and #7230 recorded: against ObjectStack's own server this is
|
|
768
|
+
defence-in-depth, not a live disclosure. `plugin-security`'s
|
|
769
|
+
`FieldMasker.maskRecord` deletes every unreadable key from each returned row
|
|
770
|
+
and objectql's expand path writes the resolved record back under that same
|
|
771
|
+
key, so one statement removes the expanded object and the bare id alike; the
|
|
772
|
+
expansion sub-read is itself gated (the referenced object's full CRUD + RLS +
|
|
773
|
+
FLS treatment, objectstack#7626). It is load-bearing for any backend that does
|
|
774
|
+
not strip, and the client-request side is real regardless.
|
|
775
|
+
|
|
776
|
+
**Nothing a permitted view did stops working.** The gate judges each site's
|
|
777
|
+
`buildExpandFields` OUTPUT, which contains only the object's declared
|
|
778
|
+
reference-bearing fields, so the "`checkField` answers false for an
|
|
779
|
+
undeclared key" trap cannot be reached. An unanswered permission policy
|
|
780
|
+
filters nothing. `buildExpandFields` itself is unchanged.
|
|
781
|
+
|
|
782
|
+
`@object-ui/permissions` is added to `dependencies` for `plugin-kanban`,
|
|
783
|
+
`plugin-tree`, `plugin-map`, `plugin-timeline`, and `plugin-view` — the fifth
|
|
784
|
+
one objectui#7429's own dependency count missed (it named four); `plugin-list`
|
|
785
|
+
and `app-shell` already had it.
|
|
786
|
+
- c6198c2: **Breaking for authored metadata:** `ComponentInput.label`, `ComponentInput.defaultValue` and
|
|
787
|
+
`ComponentInput.advanced` are RETIRED on both faces (objectui#7493 item ① and objectui#7781;
|
|
788
|
+
maintainer ruling A of 2026-09-06, immediate, no deprecation window; ADR-0049 enforce-or-remove).
|
|
789
|
+
They are the three keys the manifest serializer does not forward, and nothing read them on any
|
|
790
|
+
publication or consumption path.
|
|
791
|
+
|
|
792
|
+
No manifest ever published them, so no consumer could ever have read them. `sdui-parser`'s
|
|
793
|
+
serializer (`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`,
|
|
794
|
+
`type`, `of`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
|
|
795
|
+
never reached `sdui.manifest.json`, the generated JSX `.d.ts`, or a diagnostic; its boundary type
|
|
796
|
+
has no slot for them; the registry's data-source seam reads `name` only; and neither the designer
|
|
797
|
+
nor the app-shell inspectors consult registry `inputs` at all. A structural census over every
|
|
798
|
+
`inputs:` array in the repository (re-measured on this change's merge-base, `name` 951 and `type`
|
|
799
|
+
951 as the controls) counted the writes: `label` 908, `defaultValue` 245, `advanced` 9 — written on
|
|
800
|
+
nearly every registration, read by nothing.
|
|
801
|
+
|
|
802
|
+
FROM → TO, per key — all three **TOMBSTONED, not removed**, because the route was measured on
|
|
803
|
+
the built face before it was chosen: `ComponentInputSchema` is a non-strict `z.object`, and an
|
|
804
|
+
undeclared key parses GREEN and is silently STRIPPED, so a deletion would have swallowed 1,162
|
|
805
|
+
authored values in silence. The tombstone is what makes the refusal loud and by name.
|
|
806
|
+
|
|
807
|
+
- `label?: string` → `label?: never` on the interface, `retirementTombstone()` on the Zod mirror.
|
|
808
|
+
Migration: delete the key. An input is identified by its `name` on every path that reaches it;
|
|
809
|
+
nothing ever rendered a label for it.
|
|
810
|
+
- `defaultValue?: any` → `defaultValue?: never` / `retirementTombstone()`. Migration: delete the
|
|
811
|
+
key. The renderer's own fallback read IS the default; tell the author about it in `description`,
|
|
812
|
+
which IS published. (Tightening the type to `unknown` was ruled out: it closes no error class,
|
|
813
|
+
since nothing reads the value.)
|
|
814
|
+
- `advanced?: boolean` → `advanced?: never` / `retirementTombstone()`. Migration: delete the key.
|
|
815
|
+
No designer surface ever hid an "advanced" input; there is nothing to write instead.
|
|
816
|
+
|
|
817
|
+
The retirement kit: `?: never` on `ComponentInput` (`packages/types/src/base.ts`), so authoring one
|
|
818
|
+
is a `tsc` error at the registration site; `retirementTombstone()` on `ComponentInputSchema`
|
|
819
|
+
(`packages/types/src/zod/base.zod.ts`), so an authored value is REFUSED at parse time with
|
|
820
|
+
`code: 'invalid_type'`, the key named in the issue `path`, and the migration note as the message
|
|
821
|
+
(one string, both channels). Pinned in
|
|
822
|
+
`packages/types/src/__tests__/component-input-retired-keys-7493.test.ts`, which also holds a
|
|
823
|
+
tree-scoped absence census over every `inputs:` array under `packages/**` and `apps/**`.
|
|
824
|
+
|
|
825
|
+
Accept-set change, stated plainly for reviewers: a document that sets any of the three keys on a
|
|
826
|
+
`ComponentInput` used to parse GREEN (the value was then dropped by the serializer) and now parses
|
|
827
|
+
RED. Every in-repo authoring site — 1,199 keys across 110 registration files, the three standalone
|
|
828
|
+
`ComponentInput[]` arrays and the two named input arrays `tsc` found included — is deleted in the same change, as the ruling's split rule
|
|
829
|
+
requires; the `WidgetRegistry` seam no longer copies the widget-manifest values onto the synthesized
|
|
830
|
+
`ComponentInput` (they fed nothing), and the data-source declaration `ELEMENT_DATA_SOURCE_INPUT`
|
|
831
|
+
drops its `label`. The patch entries on the other packages record exactly that: their registrations
|
|
832
|
+
stop authoring inert keys, with no runtime or published-manifest change.
|
|
833
|
+
|
|
834
|
+
The nine test files that read `defaultValue` off a registration were re-pinned against the
|
|
835
|
+
renderer's ACTUAL default (its own fallback read, or the `defaultProps` it ships) instead of the
|
|
836
|
+
declaration that went away; two assertions that only restated the shadow default were dropped with
|
|
837
|
+
the reason on the line.
|
|
838
|
+
|
|
839
|
+
The in-repo zero is what was measured. Whether anything OUTSIDE this repository writes these keys
|
|
840
|
+
is not measurable from here (the objectui#5674 limit); converting such a write from a silent drop
|
|
841
|
+
into a named refusal is exactly what the tombstones buy. `WidgetInput`'s own `label` /
|
|
842
|
+
`defaultValue` / `advanced` (the widget-manifest face) stay declared and writable — nothing has
|
|
843
|
+
ruled on that face; that it now has no reader either is recorded as objectui#7911.
|
|
844
|
+
- ce2aaef: One shared record-source ladder, five plugins delegate.
|
|
845
|
+
|
|
846
|
+
`@object-ui/core` publishes `resolveRecordSourceConfig(schema)` — the ONE implementation
|
|
847
|
+
of the ruled three-rung record source ladder: `data` first, then `staticData` wrapped as
|
|
848
|
+
`{ provider: 'value', items }`, then `objectName` folded to `{ provider: 'object' }`, and
|
|
849
|
+
`null` when nothing is bound. It is the PRODUCER whose output the reader
|
|
850
|
+
`resolveRecordSourceObjectName` (`b041b9c0c`) consumes, and it now sits beside it in the same module.
|
|
851
|
+
|
|
852
|
+
That ladder is published contract on both faces — `packages/types/src/objectql.ts` and its
|
|
853
|
+
zod mirror both ship `.describe()` strings naming `getDataConfig`'s order (`77cb489b4`,
|
|
854
|
+
maintainer ruling 2026-09-02), pinned by `objectql-record-source-refinement-6939.test.ts` —
|
|
855
|
+
and it was hand-copied into five plugin components with no gate holding them together. A
|
|
856
|
+
change to the ruled order had five edit sites and nothing that noticed a missed one; that
|
|
857
|
+
is the AGENTS.md #0.1 drift class.
|
|
858
|
+
|
|
859
|
+
**No behaviour changes.** `ObjectCalendar`, `ObjectGantt` and `ObjectTree` now call the
|
|
860
|
+
shared reader directly. `ObjectGrid` and `ObjectMap` keep their own bare-array `data`
|
|
861
|
+
shorthand as a documented head above the shared call and are otherwise unchanged.
|
|
862
|
+
`record-source-config.behaviourNeutrality-7632.test.ts` transcribes all five pre-collapse
|
|
863
|
+
bodies verbatim and asserts the post-collapse spelling agrees with each across the whole
|
|
864
|
+
input matrix, so a later edit to the shared reader that moves any site turns red.
|
|
865
|
+
|
|
866
|
+
**Two divergences were measured rather than assumed, and both are preserved.**
|
|
867
|
+
|
|
868
|
+
`ObjectCalendar`'s `'data' in schema && schema.data` guards existed because its parameter was
|
|
869
|
+
at that time the union `ObjectGridSchema | CalendarSchema`, whose `CalendarSchema` arm declared
|
|
870
|
+
neither key. (objectui#8651 has since re-pointed that parameter at the published
|
|
871
|
+
`ObjectCalendarSchema`, so the union is gone; the CONCLUSION below — that the guard had no
|
|
872
|
+
runtime effect and removing it is behaviour-neutral — is unaffected.)
|
|
873
|
+
That is a TypeScript narrowing device with no runtime effect — an absent property reads
|
|
874
|
+
`undefined`, falsy either way — so the guard could never change which rung is taken. The
|
|
875
|
+
shared reader's optional-property parameter accepts the union directly, and the
|
|
876
|
+
equivalence is pinned on a fixture that really lacks both keys rather than argued.
|
|
877
|
+
|
|
878
|
+
`ObjectGrid` and `ObjectMap` normalize a bare-array `data` to `{ provider: 'value', items }`;
|
|
879
|
+
`ObjectCalendar`, `ObjectGantt` and `ObjectTree` do not, and return the array verbatim. That
|
|
880
|
+
is a real divergence on off-contract input — `ViewData` is a discriminated union over object
|
|
881
|
+
variants, so an array under `data` cannot be published. It is NOT unified here: the shared
|
|
882
|
+
rung stays contract-strict and the two sites keep the head locally, the same way `b041b9c0c`
|
|
883
|
+
left the off-contract `{ provider: 'object' }` tails at their sites. Both sides of the fork are
|
|
884
|
+
pinned, so neither folding the head in nor deleting it as redundant can happen silently.
|
|
885
|
+
|
|
886
|
+
`ObjectTree`'s copy took `schema: any`; it now goes through the shared reader's typed
|
|
887
|
+
parameter. Types are erased at runtime, so nothing it resolves moves.
|
|
888
|
+
- 2ce2612: A record-page URL now names the object the clicked rows actually came from, in
|
|
889
|
+
`ObjectTree` and `ObjectCalendar`.
|
|
890
|
+
|
|
891
|
+
`useNavigationOverlay` builds `/{objectName}/record/{id}` out of whatever it is handed,
|
|
892
|
+
and both components handed it the bare top-level `schema.objectName` while resolving
|
|
893
|
+
their own rows through the ruled record-source ladder (`data`, then
|
|
894
|
+
`staticData`, then `objectName`). `77cb489b4` published `objectName` as that ladder's
|
|
895
|
+
THIRD RUNG and not as a parallel "page object" concept, so a block has exactly one
|
|
896
|
+
record source — and a row fetched through `data.object` whose click built
|
|
897
|
+
`/{schema.objectName}/record/{id}` named a record that the URL's own object does not
|
|
898
|
+
contain.
|
|
899
|
+
|
|
900
|
+
Two shapes change, both toward the object the rows came from:
|
|
901
|
+
|
|
902
|
+
- a block carrying **both** bindings navigated to the top-level key and now navigates to
|
|
903
|
+
`data.object`;
|
|
904
|
+
- a **data-only** block had no name to build a URL from at all, so the hook took its
|
|
905
|
+
`/{id}` leg — an unrouted path that paints a blank page — and now builds the routed
|
|
906
|
+
record URL.
|
|
907
|
+
|
|
908
|
+
`ObjectCalendar` is where the divergence was plainest: on one click it resolved the
|
|
909
|
+
detail drawer through the ladder and the navigation URL through the top-level key. The
|
|
910
|
+
URL now reuses the very `schemaObjectName` that already keys the calendar's record query
|
|
911
|
+
and its `$expand` derivation, so query, drawer and URL agree by construction.
|
|
912
|
+
|
|
913
|
+
**Nothing else moves.** Both converted sites keep a site-local `?? schema.objectName`
|
|
914
|
+
tail for the off-contract `data: { provider: 'object' }` that carries no `object`
|
|
915
|
+
(`ViewDataSchema` declares it required) — the same tail `ObjectTree`'s `headerObjectName`
|
|
916
|
+
already carries, and the same conservatism `b041b9c0c` applied when it published the
|
|
917
|
+
shared reader. `useNavigationOverlay`'s own signature is unchanged: it still takes an
|
|
918
|
+
`objectName`, and only what callers hand it has changed.
|
|
919
|
+
|
|
920
|
+
The hook's `@example` stops prescribing `objectName: schema.objectName`. That prose is
|
|
921
|
+
why there were copies to convert at all — component authors copied the divergence out of
|
|
922
|
+
the documentation, correctly, as written — so it now points at
|
|
923
|
+
`resolveRecordSourceObjectName` and says explicitly that a caller with no data config
|
|
924
|
+
has nothing above rung three and should keep passing `schema.objectName`.
|
|
925
|
+
|
|
926
|
+
`ObjectKanban` is deliberately **not** converted: it has no data config, no
|
|
927
|
+
`getDataConfig`, and its `data` is a raw row array rather than a `ViewData` binding, so
|
|
928
|
+
`schema.objectName` already IS its record source and its board, drawer and URL already
|
|
929
|
+
agree.
|
|
930
|
+
- f556a89: `ObjectTree`'s parent-pointer auto-detection accepts a `tree` field only when it is
|
|
931
|
+
this object's own (objectui#7839, objectstack#14892 follow-up).
|
|
932
|
+
|
|
933
|
+
A hierarchy is parent/child **within one object**, so `@objectstack/spec` refuses a
|
|
934
|
+
`tree` field whose `reference` names any other object (`refuseForeignTreeReference`);
|
|
935
|
+
`reference` stays optional on a `tree`, where it is a redundant self-annotation.
|
|
936
|
+
`detectParentField` returned the first `type: 'tree'` field whatever its `reference`
|
|
937
|
+
said, so a foreign-shaped one was silently picked as the parent pointer and the forest
|
|
938
|
+
was grouped on a pointer into a table it does not point at. It now mirrors the spec's
|
|
939
|
+
own kernel predicate `hasDetectableParentField` term for term — accept when `reference`
|
|
940
|
+
is absent, or when it equals the bound `objectName` — and the `objectName` guard comes
|
|
941
|
+
with it: an object whose name we do not know cannot be self-referenced.
|
|
942
|
+
|
|
943
|
+
Skipping rather than returning also removes a masking bug the old early-return hid: a
|
|
944
|
+
foreign `tree` declared before a self-referencing `lookup` used to win by position and
|
|
945
|
+
the lookup never got its turn. The `lookup` / `master_detail` arm is otherwise
|
|
946
|
+
unchanged.
|
|
947
|
+
|
|
948
|
+
Reachability is narrow and stated rather than oversold: the refused shape does not
|
|
949
|
+
survive `ObjectSchema.parse` on a spec carrying that rule, so it is unreachable from
|
|
950
|
+
parsed metadata and reachable from a hand-built one — `getObjectSchema` is a required
|
|
951
|
+
member of the published `DataSource` interface, so a third-party implementation reaches
|
|
952
|
+
this reader raw. Note also that the renderer tightens **ahead** of the spec copy this
|
|
953
|
+
repo installs: `@objectstack/spec@17.2.0` still accepts the foreign shape at parse
|
|
954
|
+
(measured), so until that pin moves this function is the only door.
|
|
955
|
+
- 3e98e13: Export the host `tree` view config as `TreeViewConfig` (objectui#8253, director
|
|
956
|
+
decision batch #78, 2026-09-07, maintainer 「同意」 on option (a)).
|
|
957
|
+
|
|
958
|
+
**What was wrong.** `tree` is a host-composition-only view type — ruled deliberate on
|
|
959
|
+
objectui#5321, it is a member of neither `ObjectViewSchema.defaultViewType` nor
|
|
960
|
+
`NamedListView.type`, so the branch runs only when a host passes a `views` prop. On
|
|
961
|
+
that path a per-view `tree` block is read at four sites, and its only description
|
|
962
|
+
anywhere was a module-local, non-exported `interface TreeConfig` inside
|
|
963
|
+
`plugin-tree/src/ObjectTree.tsx`. The live host is the console: it stores view records
|
|
964
|
+
and passes them as `views`, and its create-view dialog offers `tree`. So a real
|
|
965
|
+
consumer wrote this block with no type to write it against, and a misspelled
|
|
966
|
+
`parentFeild` was admitted by the views entry's `[key: string]: any`, stored, read by
|
|
967
|
+
nobody and reported by nothing. Declared ≠ enforced on a surface a non-author
|
|
968
|
+
re-writes.
|
|
969
|
+
|
|
970
|
+
**The grades, and why.**
|
|
971
|
+
|
|
972
|
+
- `@object-ui/types` — **minor**: one new name, `TreeViewConfig`, becomes reachable
|
|
973
|
+
from the package entry. Nothing existing is renamed, retyped or removed, and no
|
|
974
|
+
value's validation changes anywhere in this package.
|
|
975
|
+
- `@object-ui/plugin-view` — **minor**: `ObjectViewProps.views[n].tree` is now
|
|
976
|
+
declared `TreeViewConfig` where it previously resolved to `any` through the entry's
|
|
977
|
+
index signature. On a face that already admitted every spelling a declaration
|
|
978
|
+
**cannot widen — it can only narrow**, and this one does: a host composing the entry
|
|
979
|
+
as an object literal now gets `parentFeild` reported as an excess property instead
|
|
980
|
+
of silently dropped. The index signature itself is untouched, so every other
|
|
981
|
+
undeclared key a host puts on the entry still type-checks exactly as before.
|
|
982
|
+
- `@object-ui/plugin-tree` — **patch**: the module-local interface becomes an import
|
|
983
|
+
of the exported one and the resolver's own type is `Pick`ed off it. No runtime
|
|
984
|
+
behaviour changes, and no key is added to or removed from what the renderer reads.
|
|
985
|
+
|
|
986
|
+
**`titleField` was declared, not deleted — and that was a measurement.** The ruling put
|
|
987
|
+
this key to a test: declare it if the console writes it, else remove the read. The
|
|
988
|
+
console's create-view dialog does **not** offer it (its `tree` slot collects
|
|
989
|
+
`parentField` alone), but the console's own host composition reads it by name, so do
|
|
990
|
+
the `ListView` and `ObjectView` tree branches, and that rung is pinned as live behaviour
|
|
991
|
+
by objectui#6557 ("the tree's second view-declared rung … still answers"). Deleting that
|
|
992
|
+
read would have reversed a recorded ruling and reddened that pin, so this change declared
|
|
993
|
+
the key at all four read sites instead. `labelField` remains canonical and wins wherever
|
|
994
|
+
both are present.
|
|
995
|
+
|
|
996
|
+
⚠️ **Superseded — the declaration has since been removed.** objectui#8841 (PR
|
|
997
|
+
objectui#9052) settled it against the protocol rather than against the reads:
|
|
998
|
+
`@objectstack/spec@17.4.0`'s `TreeConfigSchema` is a `strictObject` and refuses
|
|
999
|
+
`titleField` on `ListView.tree` by name, so declaring it here published a key an author
|
|
1000
|
+
following `@object-ui/types` was refused for at publish. `TreeViewConfig` is now derived
|
|
1001
|
+
from that protocol block and no longer carries the key, and `plugin-tree`'s
|
|
1002
|
+
`?? schema.titleField` rung — which read the flattened NODE, not this block — went with
|
|
1003
|
+
it. ⛔ What did NOT go is the view-declared read objectui#6557 pins: the
|
|
1004
|
+
`labelField || titleField` dual-reads in `plugin-view`, `plugin-list` and the console
|
|
1005
|
+
survive as undeclared tolerance, so stored view records keep resolving and that pin is
|
|
1006
|
+
still green. Read this entry for why the key was declared and objectui#8841's for why the
|
|
1007
|
+
declaration could not stand; the migration is to write `tree.labelField`.
|
|
1008
|
+
|
|
1009
|
+
**Migration.** None required. Hosts that already compose a `tree` block keep working;
|
|
1010
|
+
hosts that annotate one against `TreeViewConfig` start getting a compile error for a
|
|
1011
|
+
misspelled key instead of a view that silently ignores it.
|
|
1012
|
+
|
|
1013
|
+
⛔ This does not make `tree` an authorable view type. objectui#5321 is untouched: the
|
|
1014
|
+
block is host config, written by a host and never by a document author, and the
|
|
1015
|
+
authored node remains the flat `ObjectTreeSchema`.
|
|
1016
|
+
|
|
1017
|
+
**Note, 2026-10-01 (objectui#11168 slice 3, shipping in this same release).**
|
|
1018
|
+
The last sentence above calls the authored node "the flat `ObjectTreeSchema`".
|
|
1019
|
+
`@objectstack/spec` 17.5.0 gave `object-tree` an element row whose `tree` block
|
|
1020
|
+
carries `parentField`, `labelField`, `fields` and `defaultExpandedDepth`, and
|
|
1021
|
+
`ObjectTreeSchema` now declares that block by reference, so an authored tree
|
|
1022
|
+
writes those keys under `tree` rather than flat on the node. The flat spellings
|
|
1023
|
+
`ObjectTreeSchema` still carries are the form a host composes. What this entry
|
|
1024
|
+
says about the host `tree` view config, `TreeViewConfig` and objectui#5321 is
|
|
1025
|
+
unchanged.
|
|
1026
|
+
- 5e96b45: `ObjectTree` derives expansion during render instead of mirroring it into state
|
|
1027
|
+
(objectui#8666).
|
|
1028
|
+
|
|
1029
|
+
**The rendering artifact this removes.** Expansion lived in a
|
|
1030
|
+
`useState<Set<string>>(new Set())` that a passive `useEffect` keyed on
|
|
1031
|
+
`[roots, defaultExpandedDepth]` re-seeded from the forest, with rows computed as
|
|
1032
|
+
`flattenVisible(roots, expanded)`. So the commit that first painted the table
|
|
1033
|
+
still carried the previous, empty mirror: the root drew, its children did not,
|
|
1034
|
+
and a second commit drew the seeded-open forest. Probed in the DOM the sequence
|
|
1035
|
+
was `loading` then a one-row table then a two-row table; it is now `loading` then
|
|
1036
|
+
the two-row table. Every mount with a non-zero `defaultExpandedDepth` showed a
|
|
1037
|
+
collapsed forest for one frame, and that frame is also why a test could observe a
|
|
1038
|
+
half-drawn tree at all.
|
|
1039
|
+
|
|
1040
|
+
**The behaviour change that comes with it, and it is the load-bearing half.**
|
|
1041
|
+
Component state now holds only the answers the *user* gave by clicking a chevron
|
|
1042
|
+
— a sparse map of node id to open/closed — and the seed is computed from the
|
|
1043
|
+
forest during render. They compose by one rule: a new forest may re-seed, but a
|
|
1044
|
+
node the user deliberately opened or closed, and which is still in the forest,
|
|
1045
|
+
keeps the user's answer; every other node, a genuinely new one included, takes
|
|
1046
|
+
the seed.
|
|
1047
|
+
|
|
1048
|
+
That is a fix in the same direction as the frame, not a side effect of it.
|
|
1049
|
+
Before this change a re-seed *overwrote* the user's expansion, so any change to
|
|
1050
|
+
the identity of the record set — a refetch, a filter, a host re-render that
|
|
1051
|
+
reallocated the rows — silently reopened every subtree the user had collapsed
|
|
1052
|
+
and reclosed every one they had opened below `defaultExpandedDepth`. Authored
|
|
1053
|
+
metadata is unaffected: `defaultExpandedDepth` means exactly what it meant, and
|
|
1054
|
+
no schema key changes.
|
|
1055
|
+
- bbe57fd: Import `ObjectTreeSchema` instead of re-deriving it (objectui#9550)
|
|
1056
|
+
|
|
1057
|
+
`ObjectTree` typed its node by narrowing the published union on the `object-tree`
|
|
1058
|
+
tag and binding that to a module-local alias. That spelling was correct and it was
|
|
1059
|
+
forced: the name it wanted was declared in `@object-ui/types` and re-exported by
|
|
1060
|
+
the `./zod` barrel, but the root barrel did not carry it, so there was nothing to
|
|
1061
|
+
import. objectui#9550 put the name on that barrel, and this package now imports it.
|
|
1062
|
+
|
|
1063
|
+
Nothing about the type changes — the imported name and the narrowing resolve to the
|
|
1064
|
+
same declaration, which `ObjectTree.schemaTyped-8655.test.ts` asserts invariantly and
|
|
1065
|
+
independently through `ObjectTreeProps['schema']`. What changes is that the renderer
|
|
1066
|
+
no longer carries a derived restatement of a published type. A type nobody can import
|
|
1067
|
+
mints one of those per consumer, and each one is correct on the day it is written —
|
|
1068
|
+
that is the second-authority shape objectui#6349 is burning down, and this was one of
|
|
1069
|
+
its instances rather than a tidy-up.
|
|
1070
|
+
|
|
1071
|
+
The docblock's justification paragraph went with it: it stated, as its measured reason
|
|
1072
|
+
for choosing the narrowing, that the barrel omits the name so it "cannot be imported
|
|
1073
|
+
today". That sentence is false as of objectui#9550 and nothing re-derived it. The
|
|
1074
|
+
objectui#8651 warning beside it is KEPT and re-pointed at the import: a module-local
|
|
1075
|
+
type wearing a published type's name is the two-layers-one-word trap, and it is more
|
|
1076
|
+
load-bearing now that the published name is importable, not less.
|
|
1077
|
+
- fb336df: Move `lucide-react` from `^1.31.0` to `^1.43.0` in every package that declares it, and
|
|
1078
|
+
repair what the jump breaks, so icons resolved from a STRING keep drawing a glyph.
|
|
1079
|
+
|
|
1080
|
+
Measured once against the installed 1.43.0 artifact when this change was made; nothing in
|
|
1081
|
+
the repository re-derives these readings. Across the jump lucide removes no runtime export,
|
|
1082
|
+
no public type name and no `lucide-react/dynamic.mjs` name, and every name this repository
|
|
1083
|
+
imports from `lucide-react` resolves. Exactly one key leaves the runtime `icons` record:
|
|
1084
|
+
`Trash2`, retired in favour of `trash`.
|
|
1085
|
+
|
|
1086
|
+
What a user sees change:
|
|
1087
|
+
|
|
1088
|
+
- Icons the lazy icon seam draws (`resolveIcon`, objectui#9251) get their path data again.
|
|
1089
|
+
lucide 1.43.0 icon modules export their path data inside `__iconData` and no longer
|
|
1090
|
+
export `__iconNode`; the seam now reads both. Reading only `__iconNode` against 1.43.0
|
|
1091
|
+
leaves every such glyph an empty box, with nothing thrown or logged.
|
|
1092
|
+
- `DetailView`'s delete action and three schema-catalog examples spell their icon
|
|
1093
|
+
`trash`, not `trash-2`, so they keep resolving. The glyph is unchanged: 1.43.0's `trash`
|
|
1094
|
+
path data is byte-identical to the `trash-2` path data of 1.31.0 and 1.35.0. Anything
|
|
1095
|
+
that already authored `trash` now draws that same artwork, because lucide moved it under
|
|
1096
|
+
the `trash` name; a few other glyphs were also redrawn upstream.
|
|
1097
|
+
- Icons imported as COMPONENTS carry lucide 1.43.0's own classes: one class per declared
|
|
1098
|
+
alias (a spinner renders `class="lucide lucide-loader-circle lucide-loader-2 ..."`), and
|
|
1099
|
+
no longer the class lucide used to derive from the PascalCase key where that differs
|
|
1100
|
+
(`ArrowDown01` no longer carries `lucide-arrow-down01`). The canonical
|
|
1101
|
+
`lucide-<icon name>` class is still there, so a `.lucide-loader-circle` selector still
|
|
1102
|
+
matches.
|
|
1103
|
+
- Icons resolved from a STRING through the seam keep the classes they had: `lucide`, the
|
|
1104
|
+
canonical `lucide-<icon name>` class and the key-derived class. They do not carry
|
|
1105
|
+
lucide's per-alias classes. That is a maintainer ruling (objectui#8941, option C): the
|
|
1106
|
+
alias list lives only inside each lazily loaded icon module, and it was not moved into
|
|
1107
|
+
the eager name list. A selector that targets an alias class matches a component-imported
|
|
1108
|
+
icon and not a string-resolved one. This also dates the example in the objectui#9251
|
|
1109
|
+
entry: `trash-2` no longer resolves as a string, so no seam-drawn glyph carries
|
|
1110
|
+
`lucide-trash2 lucide-trash-2`; a digit-bearing name that still resolves, such as
|
|
1111
|
+
`arrow-down-0-1`, carries `lucide-arrow-down01 lucide-arrow-down-0-1`.
|
|
1112
|
+
- Updated dependencies [cd2cb41]
|
|
1113
|
+
- Updated dependencies [7b10bef]
|
|
1114
|
+
- Updated dependencies [97abedc]
|
|
1115
|
+
- Updated dependencies [b46c58f]
|
|
1116
|
+
- Updated dependencies [a507334]
|
|
1117
|
+
- Updated dependencies [ad694ac]
|
|
1118
|
+
- Updated dependencies [6f96fca]
|
|
1119
|
+
- Updated dependencies [afb2284]
|
|
1120
|
+
- Updated dependencies [3ac2de8]
|
|
1121
|
+
- Updated dependencies [0aacecc]
|
|
1122
|
+
- Updated dependencies [28b0658]
|
|
1123
|
+
- Updated dependencies [63f4f92]
|
|
1124
|
+
- Updated dependencies [777fca2]
|
|
1125
|
+
- Updated dependencies [c131d9e]
|
|
1126
|
+
- Updated dependencies [5f00ff4]
|
|
1127
|
+
- Updated dependencies [c9e073a]
|
|
1128
|
+
- Updated dependencies [7b395d8]
|
|
1129
|
+
- Updated dependencies [0879812]
|
|
1130
|
+
- Updated dependencies [588380d]
|
|
1131
|
+
- Updated dependencies [8cedb0d]
|
|
1132
|
+
- Updated dependencies [162621b]
|
|
1133
|
+
- Updated dependencies [b06c3de]
|
|
1134
|
+
- Updated dependencies [0d379f5]
|
|
1135
|
+
- Updated dependencies [4c6f549]
|
|
1136
|
+
- Updated dependencies [6cc910b]
|
|
1137
|
+
- Updated dependencies [061f5e8]
|
|
1138
|
+
- Updated dependencies [879ecac]
|
|
1139
|
+
- Updated dependencies [c2dabf0]
|
|
1140
|
+
- Updated dependencies [2dd4d3f]
|
|
1141
|
+
- Updated dependencies [e686f4d]
|
|
1142
|
+
- Updated dependencies [4ab4f1b]
|
|
1143
|
+
- Updated dependencies [fa5fbd9]
|
|
1144
|
+
- Updated dependencies [5f44cc6]
|
|
1145
|
+
- Updated dependencies [b57107d]
|
|
1146
|
+
- Updated dependencies [e3ea4f9]
|
|
1147
|
+
- Updated dependencies [fd6f5da]
|
|
1148
|
+
- Updated dependencies [bb5d4ee]
|
|
1149
|
+
- Updated dependencies [dc666f7]
|
|
1150
|
+
- Updated dependencies [3335767]
|
|
1151
|
+
- Updated dependencies [8b1f066]
|
|
1152
|
+
- Updated dependencies [af243c1]
|
|
1153
|
+
- Updated dependencies [cff4b77]
|
|
1154
|
+
- Updated dependencies [961ceaa]
|
|
1155
|
+
- Updated dependencies [f3f4e4c]
|
|
1156
|
+
- Updated dependencies [a05c350]
|
|
1157
|
+
- Updated dependencies [1dbb993]
|
|
1158
|
+
- Updated dependencies [2b5f509]
|
|
1159
|
+
- Updated dependencies [808f339]
|
|
1160
|
+
- Updated dependencies [6cf5999]
|
|
1161
|
+
- Updated dependencies [274e14a]
|
|
1162
|
+
- Updated dependencies [8c10f4f]
|
|
1163
|
+
- Updated dependencies [90dac98]
|
|
1164
|
+
- Updated dependencies [6096f20]
|
|
1165
|
+
- Updated dependencies [544aca2]
|
|
1166
|
+
- Updated dependencies [ea02938]
|
|
1167
|
+
- Updated dependencies [a14fb23]
|
|
1168
|
+
- Updated dependencies [ae98f1d]
|
|
1169
|
+
- Updated dependencies [f98eddf]
|
|
1170
|
+
- Updated dependencies [ce6bd99]
|
|
1171
|
+
- Updated dependencies [a5b08c9]
|
|
1172
|
+
- Updated dependencies [86982ac]
|
|
1173
|
+
- Updated dependencies [cdefa2a]
|
|
1174
|
+
- Updated dependencies [cc4366d]
|
|
1175
|
+
- Updated dependencies [0961d5e]
|
|
1176
|
+
- Updated dependencies [6276478]
|
|
1177
|
+
- Updated dependencies [5e67837]
|
|
1178
|
+
- Updated dependencies [ff14e29]
|
|
1179
|
+
- Updated dependencies [9b28151]
|
|
1180
|
+
- Updated dependencies [64563a9]
|
|
1181
|
+
- Updated dependencies [1a5003f]
|
|
1182
|
+
- Updated dependencies [09ab32b]
|
|
1183
|
+
- Updated dependencies [8acc51b]
|
|
1184
|
+
- Updated dependencies [ea9d17f]
|
|
1185
|
+
- Updated dependencies [45362a3]
|
|
1186
|
+
- Updated dependencies [2a943bf]
|
|
1187
|
+
- Updated dependencies [d999617]
|
|
1188
|
+
- Updated dependencies [93a689d]
|
|
1189
|
+
- Updated dependencies [4357a27]
|
|
1190
|
+
- Updated dependencies [e5f4343]
|
|
1191
|
+
- Updated dependencies [3261e64]
|
|
1192
|
+
- Updated dependencies [f5178a2]
|
|
1193
|
+
- Updated dependencies [2ad3671]
|
|
1194
|
+
- Updated dependencies [8740e86]
|
|
1195
|
+
- Updated dependencies [d22b37b]
|
|
1196
|
+
- Updated dependencies [9cbe4db]
|
|
1197
|
+
- Updated dependencies [1daf477]
|
|
1198
|
+
- Updated dependencies [3d614ea]
|
|
1199
|
+
- Updated dependencies [6c2f3c5]
|
|
1200
|
+
- Updated dependencies [fb13e85]
|
|
1201
|
+
- Updated dependencies [c2d8659]
|
|
1202
|
+
- Updated dependencies [e0f8202]
|
|
1203
|
+
- Updated dependencies [ac2d6f1]
|
|
1204
|
+
- Updated dependencies [9fbbb17]
|
|
1205
|
+
- Updated dependencies [c3a26cc]
|
|
1206
|
+
- Updated dependencies [a66e58e]
|
|
1207
|
+
- Updated dependencies [d89492c]
|
|
1208
|
+
- Updated dependencies [9a5f998]
|
|
1209
|
+
- Updated dependencies [9327397]
|
|
1210
|
+
- Updated dependencies [17cc3a3]
|
|
1211
|
+
- Updated dependencies [02e6d36]
|
|
1212
|
+
- Updated dependencies [4758b33]
|
|
1213
|
+
- Updated dependencies [4758b33]
|
|
1214
|
+
- Updated dependencies [8848ce4]
|
|
1215
|
+
- Updated dependencies [f905090]
|
|
1216
|
+
- Updated dependencies [9c78ebe]
|
|
1217
|
+
- Updated dependencies [9c78ebe]
|
|
1218
|
+
- Updated dependencies [12809a5]
|
|
1219
|
+
- Updated dependencies [9c78ebe]
|
|
1220
|
+
- Updated dependencies [12809a5]
|
|
1221
|
+
- Updated dependencies [7afc81d]
|
|
1222
|
+
- Updated dependencies [f9c06ef]
|
|
1223
|
+
- Updated dependencies [93a5585]
|
|
1224
|
+
- Updated dependencies [5ad3b88]
|
|
1225
|
+
- Updated dependencies [21eb61a]
|
|
1226
|
+
- Updated dependencies [f9d772b]
|
|
1227
|
+
- Updated dependencies [97b6c21]
|
|
1228
|
+
- Updated dependencies [26ca2ad]
|
|
1229
|
+
- Updated dependencies [41ae65b]
|
|
1230
|
+
- Updated dependencies [184cfe1]
|
|
1231
|
+
- Updated dependencies [baac95a]
|
|
1232
|
+
- Updated dependencies [13220af]
|
|
1233
|
+
- Updated dependencies [29b45f6]
|
|
1234
|
+
- Updated dependencies [39b8d51]
|
|
1235
|
+
- Updated dependencies [17b323e]
|
|
1236
|
+
- Updated dependencies [b956e69]
|
|
1237
|
+
- Updated dependencies [33e58d8]
|
|
1238
|
+
- Updated dependencies [256b4c9]
|
|
1239
|
+
- Updated dependencies [c5ec15c]
|
|
1240
|
+
- Updated dependencies [fec3b1a]
|
|
1241
|
+
- Updated dependencies [b8e0941]
|
|
1242
|
+
- Updated dependencies [0c50f18]
|
|
1243
|
+
- Updated dependencies [285e36b]
|
|
1244
|
+
- Updated dependencies [1dae95a]
|
|
1245
|
+
- Updated dependencies [e32dae1]
|
|
1246
|
+
- Updated dependencies [30b11ad]
|
|
1247
|
+
- Updated dependencies [4aebea0]
|
|
1248
|
+
- Updated dependencies [f976774]
|
|
1249
|
+
- Updated dependencies [3d6badf]
|
|
1250
|
+
- Updated dependencies [25cb364]
|
|
1251
|
+
- Updated dependencies [a60539b]
|
|
1252
|
+
- Updated dependencies [de1b879]
|
|
1253
|
+
- Updated dependencies [c6678b1]
|
|
1254
|
+
- Updated dependencies [0638322]
|
|
1255
|
+
- Updated dependencies [e3782d2]
|
|
1256
|
+
- Updated dependencies [db0beb2]
|
|
1257
|
+
- Updated dependencies [997ce38]
|
|
1258
|
+
- Updated dependencies [ae0b9d3]
|
|
1259
|
+
- Updated dependencies [ad1785c]
|
|
1260
|
+
- Updated dependencies [3b469c8]
|
|
1261
|
+
- Updated dependencies [990a2d6]
|
|
1262
|
+
- Updated dependencies [37140f4]
|
|
1263
|
+
- Updated dependencies [1c84036]
|
|
1264
|
+
- Updated dependencies [1c84036]
|
|
1265
|
+
- Updated dependencies [6650259]
|
|
1266
|
+
- Updated dependencies [4f8b7f8]
|
|
1267
|
+
- Updated dependencies [9e6619f]
|
|
1268
|
+
- Updated dependencies [f6ae5e2]
|
|
1269
|
+
- Updated dependencies [eb97ce6]
|
|
1270
|
+
- Updated dependencies [7343376]
|
|
1271
|
+
- Updated dependencies [b2683a2]
|
|
1272
|
+
- Updated dependencies [dded788]
|
|
1273
|
+
- Updated dependencies [b45d463]
|
|
1274
|
+
- Updated dependencies [54a7830]
|
|
1275
|
+
- Updated dependencies [f3135a4]
|
|
1276
|
+
- Updated dependencies [b5696d3]
|
|
1277
|
+
- Updated dependencies [3f9d926]
|
|
1278
|
+
- Updated dependencies [e978ed5]
|
|
1279
|
+
- Updated dependencies [6a7f24e]
|
|
1280
|
+
- Updated dependencies [b3c96d6]
|
|
1281
|
+
- Updated dependencies [8d0ca91]
|
|
1282
|
+
- Updated dependencies [c30c8dd]
|
|
1283
|
+
- Updated dependencies [244d516]
|
|
1284
|
+
- Updated dependencies [deca847]
|
|
1285
|
+
- Updated dependencies [ac15833]
|
|
1286
|
+
- Updated dependencies [ac15833]
|
|
1287
|
+
- Updated dependencies [e2dffc9]
|
|
1288
|
+
- Updated dependencies [328abeb]
|
|
1289
|
+
- Updated dependencies [dd0d78f]
|
|
1290
|
+
- Updated dependencies [24d3e65]
|
|
1291
|
+
- Updated dependencies [95a7c8d]
|
|
1292
|
+
- Updated dependencies [e227156]
|
|
1293
|
+
- Updated dependencies [cc4e476]
|
|
1294
|
+
- Updated dependencies [92970c4]
|
|
1295
|
+
- Updated dependencies [d570eaa]
|
|
1296
|
+
- Updated dependencies [4b742f4]
|
|
1297
|
+
- Updated dependencies [42687ba]
|
|
1298
|
+
- Updated dependencies [6cd8f66]
|
|
1299
|
+
- Updated dependencies [24a0f14]
|
|
1300
|
+
- Updated dependencies [797a30f]
|
|
1301
|
+
- Updated dependencies [27ae632]
|
|
1302
|
+
- Updated dependencies [b4075c0]
|
|
1303
|
+
- Updated dependencies [9b85600]
|
|
1304
|
+
- Updated dependencies [e327c89]
|
|
1305
|
+
- Updated dependencies [2eaf5be]
|
|
1306
|
+
- Updated dependencies [bf7ab35]
|
|
1307
|
+
- Updated dependencies [99878d8]
|
|
1308
|
+
- Updated dependencies [3c13675]
|
|
1309
|
+
- Updated dependencies [63ab761]
|
|
1310
|
+
- Updated dependencies [0eb9f36]
|
|
1311
|
+
- Updated dependencies [ae582b7]
|
|
1312
|
+
- Updated dependencies [62d6f56]
|
|
1313
|
+
- Updated dependencies [51c2949]
|
|
1314
|
+
- Updated dependencies [a4b017e]
|
|
1315
|
+
- Updated dependencies [8732846]
|
|
1316
|
+
- Updated dependencies [559a2e2]
|
|
1317
|
+
- Updated dependencies [db11afd]
|
|
1318
|
+
- Updated dependencies [154075a]
|
|
1319
|
+
- Updated dependencies [582edef]
|
|
1320
|
+
- Updated dependencies [19f484f]
|
|
1321
|
+
- Updated dependencies [0a78a20]
|
|
1322
|
+
- Updated dependencies [615346d]
|
|
1323
|
+
- Updated dependencies [75dcc81]
|
|
1324
|
+
- Updated dependencies [55a12a8]
|
|
1325
|
+
- Updated dependencies [edfcf5a]
|
|
1326
|
+
- Updated dependencies [0a3e540]
|
|
1327
|
+
- Updated dependencies [c021b35]
|
|
1328
|
+
- Updated dependencies [f61dab1]
|
|
1329
|
+
- Updated dependencies [b0a05dd]
|
|
1330
|
+
- Updated dependencies [dd5ff19]
|
|
1331
|
+
- Updated dependencies [54997ff]
|
|
1332
|
+
- Updated dependencies [81f8498]
|
|
1333
|
+
- Updated dependencies [a782fa7]
|
|
1334
|
+
- Updated dependencies [1d6a23d]
|
|
1335
|
+
- Updated dependencies [0645133]
|
|
1336
|
+
- Updated dependencies [76e9df0]
|
|
1337
|
+
- Updated dependencies [0ecaa7d]
|
|
1338
|
+
- Updated dependencies [b24f93a]
|
|
1339
|
+
- Updated dependencies [6158e4c]
|
|
1340
|
+
- Updated dependencies [cff8641]
|
|
1341
|
+
- Updated dependencies [3f61eef]
|
|
1342
|
+
- Updated dependencies [c27b575]
|
|
1343
|
+
- Updated dependencies [84b275c]
|
|
1344
|
+
- Updated dependencies [0e6e76b]
|
|
1345
|
+
- Updated dependencies [bf43afa]
|
|
1346
|
+
- Updated dependencies [385ebc5]
|
|
1347
|
+
- Updated dependencies [858eafb]
|
|
1348
|
+
- Updated dependencies [a8c5509]
|
|
1349
|
+
- Updated dependencies [c2a8d23]
|
|
1350
|
+
- Updated dependencies [f4ed238]
|
|
1351
|
+
- Updated dependencies [0ffc423]
|
|
1352
|
+
- Updated dependencies [3cc4fe5]
|
|
1353
|
+
- Updated dependencies [cd5b19a]
|
|
1354
|
+
- Updated dependencies [cd5b19a]
|
|
1355
|
+
- Updated dependencies [17dc167]
|
|
1356
|
+
- Updated dependencies [20d23be]
|
|
1357
|
+
- Updated dependencies [20d23be]
|
|
1358
|
+
- Updated dependencies [2e3da72]
|
|
1359
|
+
- Updated dependencies [1263e40]
|
|
1360
|
+
- Updated dependencies [e6bc087]
|
|
1361
|
+
- Updated dependencies [9419df1]
|
|
1362
|
+
- Updated dependencies [8bab157]
|
|
1363
|
+
- Updated dependencies [a7557a7]
|
|
1364
|
+
- Updated dependencies [7d074ba]
|
|
1365
|
+
- Updated dependencies [6158e4c]
|
|
1366
|
+
- Updated dependencies [6158e4c]
|
|
1367
|
+
- Updated dependencies [52aad5c]
|
|
1368
|
+
- Updated dependencies [18d1a0a]
|
|
1369
|
+
- Updated dependencies [e420df3]
|
|
1370
|
+
- Updated dependencies [7fed09d]
|
|
1371
|
+
- Updated dependencies [58da8ae]
|
|
1372
|
+
- Updated dependencies [a8b9889]
|
|
1373
|
+
- Updated dependencies [138ad45]
|
|
1374
|
+
- Updated dependencies [138ad45]
|
|
1375
|
+
- Updated dependencies [5262f7d]
|
|
1376
|
+
- Updated dependencies [6aa029b]
|
|
1377
|
+
- Updated dependencies [2124d04]
|
|
1378
|
+
- Updated dependencies [be52115]
|
|
1379
|
+
- Updated dependencies [770cc5b]
|
|
1380
|
+
- Updated dependencies [1a88ce2]
|
|
1381
|
+
- Updated dependencies [a1a44d6]
|
|
1382
|
+
- Updated dependencies [e0a9c67]
|
|
1383
|
+
- Updated dependencies [5638529]
|
|
1384
|
+
- Updated dependencies [5638529]
|
|
1385
|
+
- Updated dependencies [d0fba91]
|
|
1386
|
+
- Updated dependencies [c476be0]
|
|
1387
|
+
- Updated dependencies [c82ff39]
|
|
1388
|
+
- Updated dependencies [6c3da53]
|
|
1389
|
+
- Updated dependencies [31987bd]
|
|
1390
|
+
- Updated dependencies [3c3ce15]
|
|
1391
|
+
- Updated dependencies [063119f]
|
|
1392
|
+
- Updated dependencies [e100589]
|
|
1393
|
+
- Updated dependencies [304f611]
|
|
1394
|
+
- Updated dependencies [e46ee77]
|
|
1395
|
+
- Updated dependencies [f9c8c4e]
|
|
1396
|
+
- Updated dependencies [6e9c8d2]
|
|
1397
|
+
- Updated dependencies [9547063]
|
|
1398
|
+
- Updated dependencies [3f6efd6]
|
|
1399
|
+
- Updated dependencies [55d18c6]
|
|
1400
|
+
- Updated dependencies [c4ab6d0]
|
|
1401
|
+
- Updated dependencies [0e9058b]
|
|
1402
|
+
- Updated dependencies [c4ab6d0]
|
|
1403
|
+
- Updated dependencies [5988b6b]
|
|
1404
|
+
- Updated dependencies [6158e4c]
|
|
1405
|
+
- Updated dependencies [00ccdf7]
|
|
1406
|
+
- Updated dependencies [9d9ed54]
|
|
1407
|
+
- Updated dependencies [4a1adb7]
|
|
1408
|
+
- Updated dependencies [4a1adb7]
|
|
1409
|
+
- Updated dependencies [4a1adb7]
|
|
1410
|
+
- Updated dependencies [50c73fe]
|
|
1411
|
+
- Updated dependencies [ca3de72]
|
|
1412
|
+
- Updated dependencies [83e3f83]
|
|
1413
|
+
- Updated dependencies [401611b]
|
|
1414
|
+
- Updated dependencies [2c0ddf2]
|
|
1415
|
+
- Updated dependencies [4abc0aa]
|
|
1416
|
+
- Updated dependencies [f560ded]
|
|
1417
|
+
- Updated dependencies [f560ded]
|
|
1418
|
+
- Updated dependencies [2b188fa]
|
|
1419
|
+
- Updated dependencies [b654d4e]
|
|
1420
|
+
- Updated dependencies [f68e0a0]
|
|
1421
|
+
- Updated dependencies [aea682a]
|
|
1422
|
+
- Updated dependencies [fcdc8ec]
|
|
1423
|
+
- Updated dependencies [2d576e4]
|
|
1424
|
+
- Updated dependencies [8366acc]
|
|
1425
|
+
- Updated dependencies [95e58a3]
|
|
1426
|
+
- Updated dependencies [9d7419b]
|
|
1427
|
+
- Updated dependencies [fc7db05]
|
|
1428
|
+
- Updated dependencies [fc7db05]
|
|
1429
|
+
- Updated dependencies [9ed8d0f]
|
|
1430
|
+
- Updated dependencies [c73cdb5]
|
|
1431
|
+
- Updated dependencies [6f5719e]
|
|
1432
|
+
- Updated dependencies [b34cc14]
|
|
1433
|
+
- Updated dependencies [ab18797]
|
|
1434
|
+
- Updated dependencies [d0097af]
|
|
1435
|
+
- Updated dependencies [432882b]
|
|
1436
|
+
- Updated dependencies [64dae8e]
|
|
1437
|
+
- Updated dependencies [b06e374]
|
|
1438
|
+
- Updated dependencies [06a8af5]
|
|
1439
|
+
- Updated dependencies [6a91586]
|
|
1440
|
+
- Updated dependencies [a04d7c6]
|
|
1441
|
+
- Updated dependencies [5ccc500]
|
|
1442
|
+
- Updated dependencies [f3c2bb0]
|
|
1443
|
+
- Updated dependencies [978507b]
|
|
1444
|
+
- Updated dependencies [778138e]
|
|
1445
|
+
- Updated dependencies [9801765]
|
|
1446
|
+
- Updated dependencies [9cebfca]
|
|
1447
|
+
- Updated dependencies [460575f]
|
|
1448
|
+
- Updated dependencies [d796c8d]
|
|
1449
|
+
- Updated dependencies [594704f]
|
|
1450
|
+
- Updated dependencies [d3995fe]
|
|
1451
|
+
- Updated dependencies [1b1d772]
|
|
1452
|
+
- Updated dependencies [d88e20f]
|
|
1453
|
+
- Updated dependencies [f66072d]
|
|
1454
|
+
- Updated dependencies [2d7304d]
|
|
1455
|
+
- Updated dependencies [636b236]
|
|
1456
|
+
- Updated dependencies [4172589]
|
|
1457
|
+
- Updated dependencies [d6d8fb9]
|
|
1458
|
+
- Updated dependencies [64d624d]
|
|
1459
|
+
- Updated dependencies [053fdc8]
|
|
1460
|
+
- Updated dependencies [41b7ce3]
|
|
1461
|
+
- Updated dependencies [ae476b8]
|
|
1462
|
+
- Updated dependencies [39f4309]
|
|
1463
|
+
- Updated dependencies [95bad12]
|
|
1464
|
+
- Updated dependencies [d2fb6ef]
|
|
1465
|
+
- Updated dependencies [7cd3987]
|
|
1466
|
+
- Updated dependencies [ee3b878]
|
|
1467
|
+
- Updated dependencies [e304a4e]
|
|
1468
|
+
- Updated dependencies [fda49e5]
|
|
1469
|
+
- Updated dependencies [490d9a9]
|
|
1470
|
+
- Updated dependencies [1117414]
|
|
1471
|
+
- Updated dependencies [6d63cd0]
|
|
1472
|
+
- Updated dependencies [fc62bb4]
|
|
1473
|
+
- Updated dependencies [41df893]
|
|
1474
|
+
- Updated dependencies [0cba1b7]
|
|
1475
|
+
- Updated dependencies [7c96c94]
|
|
1476
|
+
- Updated dependencies [4da5109]
|
|
1477
|
+
- Updated dependencies [00f3eb5]
|
|
1478
|
+
- Updated dependencies [1ec291c]
|
|
1479
|
+
- Updated dependencies [453dbaa]
|
|
1480
|
+
- Updated dependencies [95f8704]
|
|
1481
|
+
- Updated dependencies [f8cdbf2]
|
|
1482
|
+
- Updated dependencies [69a2163]
|
|
1483
|
+
- Updated dependencies [24e027e]
|
|
1484
|
+
- Updated dependencies [2c3cd1b]
|
|
1485
|
+
- Updated dependencies [e176053]
|
|
1486
|
+
- Updated dependencies [e30ed15]
|
|
1487
|
+
- Updated dependencies [90665e0]
|
|
1488
|
+
- Updated dependencies [8d3a529]
|
|
1489
|
+
- Updated dependencies [5ac2e2c]
|
|
1490
|
+
- Updated dependencies [194fae1]
|
|
1491
|
+
- Updated dependencies [63d54dd]
|
|
1492
|
+
- Updated dependencies [7e19d03]
|
|
1493
|
+
- Updated dependencies [b08b7eb]
|
|
1494
|
+
- Updated dependencies [1e946c9]
|
|
1495
|
+
- Updated dependencies [546ddf7]
|
|
1496
|
+
- Updated dependencies [864154e]
|
|
1497
|
+
- Updated dependencies [b023625]
|
|
1498
|
+
- Updated dependencies [75bd83d]
|
|
1499
|
+
- Updated dependencies [44d075b]
|
|
1500
|
+
- Updated dependencies [40c479a]
|
|
1501
|
+
- Updated dependencies [b4393e5]
|
|
1502
|
+
- Updated dependencies [971d387]
|
|
1503
|
+
- Updated dependencies [ee851c3]
|
|
1504
|
+
- Updated dependencies [6414dfd]
|
|
1505
|
+
- Updated dependencies [a8d5c71]
|
|
1506
|
+
- Updated dependencies [905b21f]
|
|
1507
|
+
- Updated dependencies [88e9109]
|
|
1508
|
+
- Updated dependencies [2c45966]
|
|
1509
|
+
- Updated dependencies [db3a600]
|
|
1510
|
+
- Updated dependencies [3a3db76]
|
|
1511
|
+
- Updated dependencies [0d723a3]
|
|
1512
|
+
- Updated dependencies [0c95d3d]
|
|
1513
|
+
- Updated dependencies [3e4fa2c]
|
|
1514
|
+
- Updated dependencies [b5b928a]
|
|
1515
|
+
- Updated dependencies [6fd2cf7]
|
|
1516
|
+
- Updated dependencies [5fa06c4]
|
|
1517
|
+
- Updated dependencies [52a43de]
|
|
1518
|
+
- Updated dependencies [195052f]
|
|
1519
|
+
- Updated dependencies [e4559d1]
|
|
1520
|
+
- Updated dependencies [2c71482]
|
|
1521
|
+
- Updated dependencies [129bcc5]
|
|
1522
|
+
- Updated dependencies [d3005f7]
|
|
1523
|
+
- Updated dependencies [1e7fe0a]
|
|
1524
|
+
- Updated dependencies [a26b9e4]
|
|
1525
|
+
- Updated dependencies [5ef9c4f]
|
|
1526
|
+
- Updated dependencies [46f0bb4]
|
|
1527
|
+
- Updated dependencies [06b82b8]
|
|
1528
|
+
- Updated dependencies [8ec11e1]
|
|
1529
|
+
- Updated dependencies [6f81384]
|
|
1530
|
+
- Updated dependencies [22ba927]
|
|
1531
|
+
- Updated dependencies [f8c70f4]
|
|
1532
|
+
- Updated dependencies [5d3a2d1]
|
|
1533
|
+
- Updated dependencies [8f1d995]
|
|
1534
|
+
- Updated dependencies [b362c1b]
|
|
1535
|
+
- Updated dependencies [f9c34df]
|
|
1536
|
+
- Updated dependencies [dddb942]
|
|
1537
|
+
- Updated dependencies [00c665e]
|
|
1538
|
+
- Updated dependencies [29754cf]
|
|
1539
|
+
- Updated dependencies [d7de534]
|
|
1540
|
+
- Updated dependencies [3c2b6f7]
|
|
1541
|
+
- Updated dependencies [6e88630]
|
|
1542
|
+
- Updated dependencies [b84dc18]
|
|
1543
|
+
- Updated dependencies [ac8abb0]
|
|
1544
|
+
- Updated dependencies [9d86e1d]
|
|
1545
|
+
- Updated dependencies [3a5817f]
|
|
1546
|
+
- Updated dependencies [99a3c2d]
|
|
1547
|
+
- Updated dependencies [5961030]
|
|
1548
|
+
- Updated dependencies [f24de8b]
|
|
1549
|
+
- Updated dependencies [c8ea8af]
|
|
1550
|
+
- Updated dependencies [9602dc8]
|
|
1551
|
+
- Updated dependencies [3777538]
|
|
1552
|
+
- Updated dependencies [3190414]
|
|
1553
|
+
- Updated dependencies [4e480f5]
|
|
1554
|
+
- Updated dependencies [38a123c]
|
|
1555
|
+
- Updated dependencies [299102e]
|
|
1556
|
+
- Updated dependencies [30c73cd]
|
|
1557
|
+
- Updated dependencies [830ed58]
|
|
1558
|
+
- Updated dependencies [d7acad6]
|
|
1559
|
+
- Updated dependencies [45a9aeb]
|
|
1560
|
+
- Updated dependencies [713db46]
|
|
1561
|
+
- Updated dependencies [c71e14d]
|
|
1562
|
+
- Updated dependencies [bf3a03c]
|
|
1563
|
+
- Updated dependencies [cb55718]
|
|
1564
|
+
- Updated dependencies [748494b]
|
|
1565
|
+
- Updated dependencies [5967be0]
|
|
1566
|
+
- Updated dependencies [831be72]
|
|
1567
|
+
- Updated dependencies [29cb85b]
|
|
1568
|
+
- Updated dependencies [3e028c8]
|
|
1569
|
+
- Updated dependencies [d0889e2]
|
|
1570
|
+
- Updated dependencies [ce503e5]
|
|
1571
|
+
- Updated dependencies [f20dcf0]
|
|
1572
|
+
- Updated dependencies [12402a9]
|
|
1573
|
+
- Updated dependencies [aff3d7a]
|
|
1574
|
+
- Updated dependencies [4ca30d0]
|
|
1575
|
+
- Updated dependencies [7a5da14]
|
|
1576
|
+
- Updated dependencies [fff9645]
|
|
1577
|
+
- Updated dependencies [9c3b7ce]
|
|
1578
|
+
- Updated dependencies [2c1c967]
|
|
1579
|
+
- Updated dependencies [9486ac6]
|
|
1580
|
+
- Updated dependencies [9486ac6]
|
|
1581
|
+
- Updated dependencies [4d5f9b4]
|
|
1582
|
+
- Updated dependencies [d6ceb8d]
|
|
1583
|
+
- Updated dependencies [dc4365c]
|
|
1584
|
+
- Updated dependencies [e321d52]
|
|
1585
|
+
- Updated dependencies [969ba84]
|
|
1586
|
+
- Updated dependencies [4c68077]
|
|
1587
|
+
- Updated dependencies [7977ff9]
|
|
1588
|
+
- Updated dependencies [3beef6d]
|
|
1589
|
+
- Updated dependencies [06b8c42]
|
|
1590
|
+
- Updated dependencies [46b9bc9]
|
|
1591
|
+
- Updated dependencies [45ac2cb]
|
|
1592
|
+
- Updated dependencies [b97790a]
|
|
1593
|
+
- Updated dependencies [dbd5194]
|
|
1594
|
+
- Updated dependencies [7c9b044]
|
|
1595
|
+
- Updated dependencies [d47de51]
|
|
1596
|
+
- Updated dependencies [3fe6463]
|
|
1597
|
+
- Updated dependencies [b392674]
|
|
1598
|
+
- Updated dependencies [4f3a1e2]
|
|
1599
|
+
- Updated dependencies [31ab372]
|
|
1600
|
+
- Updated dependencies [846889b]
|
|
1601
|
+
- Updated dependencies [2acd8e1]
|
|
1602
|
+
- Updated dependencies [26896c6]
|
|
1603
|
+
- Updated dependencies [a439e16]
|
|
1604
|
+
- Updated dependencies [67fc3b0]
|
|
1605
|
+
- Updated dependencies [33a3b3c]
|
|
1606
|
+
- Updated dependencies [b87f15b]
|
|
1607
|
+
- Updated dependencies [9409eb9]
|
|
1608
|
+
- Updated dependencies [045d20b]
|
|
1609
|
+
- Updated dependencies [a2d2515]
|
|
1610
|
+
- Updated dependencies [c18d099]
|
|
1611
|
+
- Updated dependencies [adb2a86]
|
|
1612
|
+
- Updated dependencies [03380aa]
|
|
1613
|
+
- Updated dependencies [4562ea5]
|
|
1614
|
+
- Updated dependencies [3619792]
|
|
1615
|
+
- Updated dependencies [3561bd2]
|
|
1616
|
+
- Updated dependencies [bf97b98]
|
|
1617
|
+
- Updated dependencies [320374d]
|
|
1618
|
+
- Updated dependencies [b0d308d]
|
|
1619
|
+
- Updated dependencies [40f34b4]
|
|
1620
|
+
- Updated dependencies [bd0376d]
|
|
1621
|
+
- Updated dependencies [8063bcb]
|
|
1622
|
+
- Updated dependencies [b74a859]
|
|
1623
|
+
- Updated dependencies [d4493fd]
|
|
1624
|
+
- Updated dependencies [240b80f]
|
|
1625
|
+
- Updated dependencies [77cb489]
|
|
1626
|
+
- Updated dependencies [bfaa158]
|
|
1627
|
+
- Updated dependencies [777e5c6]
|
|
1628
|
+
- Updated dependencies [0c386dd]
|
|
1629
|
+
- Updated dependencies [9e37d9b]
|
|
1630
|
+
- Updated dependencies [5ad86dd]
|
|
1631
|
+
- Updated dependencies [16a725f]
|
|
1632
|
+
- Updated dependencies [c4326fe]
|
|
1633
|
+
- Updated dependencies [4dfdcc3]
|
|
1634
|
+
- Updated dependencies [6a449fc]
|
|
1635
|
+
- Updated dependencies [446d93d]
|
|
1636
|
+
- Updated dependencies [ecd9cb2]
|
|
1637
|
+
- Updated dependencies [98d4108]
|
|
1638
|
+
- Updated dependencies [0e3b3be]
|
|
1639
|
+
- Updated dependencies [a29ae2d]
|
|
1640
|
+
- Updated dependencies [220c18d]
|
|
1641
|
+
- Updated dependencies [eeb6c2f]
|
|
1642
|
+
- Updated dependencies [00d3f09]
|
|
1643
|
+
- Updated dependencies [4388f71]
|
|
1644
|
+
- Updated dependencies [0b1ac58]
|
|
1645
|
+
- Updated dependencies [c93b4d5]
|
|
1646
|
+
- Updated dependencies [c1fe272]
|
|
1647
|
+
- Updated dependencies [3cab570]
|
|
1648
|
+
- Updated dependencies [8ad218d]
|
|
1649
|
+
- Updated dependencies [3e41187]
|
|
1650
|
+
- Updated dependencies [5f78953]
|
|
1651
|
+
- Updated dependencies [639114c]
|
|
1652
|
+
- Updated dependencies [639114c]
|
|
1653
|
+
- Updated dependencies [1490691]
|
|
1654
|
+
- Updated dependencies [1f31d3a]
|
|
1655
|
+
- Updated dependencies [d1842ab]
|
|
1656
|
+
- Updated dependencies [854cba3]
|
|
1657
|
+
- Updated dependencies [78ca238]
|
|
1658
|
+
- Updated dependencies [d8ec8d6]
|
|
1659
|
+
- Updated dependencies [351eb31]
|
|
1660
|
+
- Updated dependencies [866cd1d]
|
|
1661
|
+
- Updated dependencies [20c04b2]
|
|
1662
|
+
- Updated dependencies [01c9023]
|
|
1663
|
+
- Updated dependencies [48c19bd]
|
|
1664
|
+
- Updated dependencies [a6d8b8d]
|
|
1665
|
+
- Updated dependencies [4b5bb95]
|
|
1666
|
+
- Updated dependencies [b652514]
|
|
1667
|
+
- Updated dependencies [adbda1b]
|
|
1668
|
+
- Updated dependencies [adbda1b]
|
|
1669
|
+
- Updated dependencies [8952395]
|
|
1670
|
+
- Updated dependencies [e2b3826]
|
|
1671
|
+
- Updated dependencies [a338037]
|
|
1672
|
+
- Updated dependencies [0348bc9]
|
|
1673
|
+
- Updated dependencies [e8c553b]
|
|
1674
|
+
- Updated dependencies [2e32ed4]
|
|
1675
|
+
- Updated dependencies [3ed3eec]
|
|
1676
|
+
- Updated dependencies [7c3df8f]
|
|
1677
|
+
- Updated dependencies [a4514e8]
|
|
1678
|
+
- Updated dependencies [6411def]
|
|
1679
|
+
- Updated dependencies [db3896c]
|
|
1680
|
+
- Updated dependencies [b9f5ff1]
|
|
1681
|
+
- Updated dependencies [e75f4c9]
|
|
1682
|
+
- Updated dependencies [19f1639]
|
|
1683
|
+
- Updated dependencies [4704aa4]
|
|
1684
|
+
- Updated dependencies [47547d0]
|
|
1685
|
+
- Updated dependencies [1bee5d0]
|
|
1686
|
+
- Updated dependencies [63a8828]
|
|
1687
|
+
- Updated dependencies [b61d7d8]
|
|
1688
|
+
- Updated dependencies [858cd72]
|
|
1689
|
+
- Updated dependencies [cfc9b6d]
|
|
1690
|
+
- Updated dependencies [dc0a60b]
|
|
1691
|
+
- Updated dependencies [554f2b6]
|
|
1692
|
+
- Updated dependencies [72f55c9]
|
|
1693
|
+
- Updated dependencies [26e06d7]
|
|
1694
|
+
- Updated dependencies [669d71b]
|
|
1695
|
+
- Updated dependencies [ed27d7c]
|
|
1696
|
+
- Updated dependencies [52c8cf7]
|
|
1697
|
+
- Updated dependencies [2ceb43a]
|
|
1698
|
+
- Updated dependencies [7cdd2b9]
|
|
1699
|
+
- Updated dependencies [52c8cf7]
|
|
1700
|
+
- Updated dependencies [3399704]
|
|
1701
|
+
- Updated dependencies [02fe257]
|
|
1702
|
+
- Updated dependencies [71a4a53]
|
|
1703
|
+
- Updated dependencies [7bf244b]
|
|
1704
|
+
- Updated dependencies [f0bb9fa]
|
|
1705
|
+
- Updated dependencies [81a2eb1]
|
|
1706
|
+
- Updated dependencies [caa0cd3]
|
|
1707
|
+
- Updated dependencies [caa0cd3]
|
|
1708
|
+
- Updated dependencies [20cb8db]
|
|
1709
|
+
- Updated dependencies [25c7d58]
|
|
1710
|
+
- Updated dependencies [00d2fa6]
|
|
1711
|
+
- Updated dependencies [77b2a18]
|
|
1712
|
+
- Updated dependencies [c6198c2]
|
|
1713
|
+
- Updated dependencies [721d1e0]
|
|
1714
|
+
- Updated dependencies [c2f0f48]
|
|
1715
|
+
- Updated dependencies [1237ae4]
|
|
1716
|
+
- Updated dependencies [2f61238]
|
|
1717
|
+
- Updated dependencies [51eb515]
|
|
1718
|
+
- Updated dependencies [c354ce5]
|
|
1719
|
+
- Updated dependencies [8fe8e5c]
|
|
1720
|
+
- Updated dependencies [feac439]
|
|
1721
|
+
- Updated dependencies [9ae871d]
|
|
1722
|
+
- Updated dependencies [efbd566]
|
|
1723
|
+
- Updated dependencies [2a5bf45]
|
|
1724
|
+
- Updated dependencies [9587fc9]
|
|
1725
|
+
- Updated dependencies [e62c44e]
|
|
1726
|
+
- Updated dependencies [daf9d57]
|
|
1727
|
+
- Updated dependencies [fe8f451]
|
|
1728
|
+
- Updated dependencies [23b9958]
|
|
1729
|
+
- Updated dependencies [c15d7ec]
|
|
1730
|
+
- Updated dependencies [5d0876c]
|
|
1731
|
+
- Updated dependencies [f7ace0a]
|
|
1732
|
+
- Updated dependencies [b041b9c]
|
|
1733
|
+
- Updated dependencies [ce2aaef]
|
|
1734
|
+
- Updated dependencies [544ecba]
|
|
1735
|
+
- Updated dependencies [2ce2612]
|
|
1736
|
+
- Updated dependencies [bc640ec]
|
|
1737
|
+
- Updated dependencies [1e215c4]
|
|
1738
|
+
- Updated dependencies [da6e191]
|
|
1739
|
+
- Updated dependencies [3e377c9]
|
|
1740
|
+
- Updated dependencies [a3eb5d0]
|
|
1741
|
+
- Updated dependencies [4ce14f1]
|
|
1742
|
+
- Updated dependencies [aef97e5]
|
|
1743
|
+
- Updated dependencies [2af1fa7]
|
|
1744
|
+
- Updated dependencies [c14d3a0]
|
|
1745
|
+
- Updated dependencies [a137d0c]
|
|
1746
|
+
- Updated dependencies [caf477f]
|
|
1747
|
+
- Updated dependencies [f6375da]
|
|
1748
|
+
- Updated dependencies [967e5d8]
|
|
1749
|
+
- Updated dependencies [c907a9c]
|
|
1750
|
+
- Updated dependencies [a4611b3]
|
|
1751
|
+
- Updated dependencies [20316ba]
|
|
1752
|
+
- Updated dependencies [d3499b3]
|
|
1753
|
+
- Updated dependencies [91f9276]
|
|
1754
|
+
- Updated dependencies [309c75e]
|
|
1755
|
+
- Updated dependencies [c9f9bae]
|
|
1756
|
+
- Updated dependencies [18897a4]
|
|
1757
|
+
- Updated dependencies [8b7ea39]
|
|
1758
|
+
- Updated dependencies [a915064]
|
|
1759
|
+
- Updated dependencies [dcbf0b2]
|
|
1760
|
+
- Updated dependencies [52cac38]
|
|
1761
|
+
- Updated dependencies [93fea2e]
|
|
1762
|
+
- Updated dependencies [1422a92]
|
|
1763
|
+
- Updated dependencies [d05fe17]
|
|
1764
|
+
- Updated dependencies [a480f79]
|
|
1765
|
+
- Updated dependencies [f08d1a8]
|
|
1766
|
+
- Updated dependencies [64a252d]
|
|
1767
|
+
- Updated dependencies [786bc91]
|
|
1768
|
+
- Updated dependencies [75fca96]
|
|
1769
|
+
- Updated dependencies [7ca6ddd]
|
|
1770
|
+
- Updated dependencies [f1cd290]
|
|
1771
|
+
- Updated dependencies [5a41ce7]
|
|
1772
|
+
- Updated dependencies [8d50bc2]
|
|
1773
|
+
- Updated dependencies [604476d]
|
|
1774
|
+
- Updated dependencies [d1bebb0]
|
|
1775
|
+
- Updated dependencies [95bf128]
|
|
1776
|
+
- Updated dependencies [335abea]
|
|
1777
|
+
- Updated dependencies [edea22a]
|
|
1778
|
+
- Updated dependencies [0f5cadf]
|
|
1779
|
+
- Updated dependencies [4f9f1ee]
|
|
1780
|
+
- Updated dependencies [66e8b2a]
|
|
1781
|
+
- Updated dependencies [aa083cd]
|
|
1782
|
+
- Updated dependencies [12b5992]
|
|
1783
|
+
- Updated dependencies [b93e245]
|
|
1784
|
+
- Updated dependencies [c842594]
|
|
1785
|
+
- Updated dependencies [290de37]
|
|
1786
|
+
- Updated dependencies [e1c27e4]
|
|
1787
|
+
- Updated dependencies [8c8da45]
|
|
1788
|
+
- Updated dependencies [8cd8eb5]
|
|
1789
|
+
- Updated dependencies [cf1d29e]
|
|
1790
|
+
- Updated dependencies [1bd79c8]
|
|
1791
|
+
- Updated dependencies [af9e957]
|
|
1792
|
+
- Updated dependencies [b1030c7]
|
|
1793
|
+
- Updated dependencies [c974edf]
|
|
1794
|
+
- Updated dependencies [592402e]
|
|
1795
|
+
- Updated dependencies [ad852b6]
|
|
1796
|
+
- Updated dependencies [6778809]
|
|
1797
|
+
- Updated dependencies [7fb22a1]
|
|
1798
|
+
- Updated dependencies [ad66d79]
|
|
1799
|
+
- Updated dependencies [0758bd8]
|
|
1800
|
+
- Updated dependencies [ee4d19f]
|
|
1801
|
+
- Updated dependencies [37149ec]
|
|
1802
|
+
- Updated dependencies [496d31d]
|
|
1803
|
+
- Updated dependencies [0ea7054]
|
|
1804
|
+
- Updated dependencies [9a853f2]
|
|
1805
|
+
- Updated dependencies [cb847fd]
|
|
1806
|
+
- Updated dependencies [ee70287]
|
|
1807
|
+
- Updated dependencies [3e98e13]
|
|
1808
|
+
- Updated dependencies [a695f50]
|
|
1809
|
+
- Updated dependencies [fc32921]
|
|
1810
|
+
- Updated dependencies [4eaa835]
|
|
1811
|
+
- Updated dependencies [8f9d87a]
|
|
1812
|
+
- Updated dependencies [b1777ae]
|
|
1813
|
+
- Updated dependencies [24845c4]
|
|
1814
|
+
- Updated dependencies [6f864cf]
|
|
1815
|
+
- Updated dependencies [24d1edd]
|
|
1816
|
+
- Updated dependencies [645087c]
|
|
1817
|
+
- Updated dependencies [33f4a19]
|
|
1818
|
+
- Updated dependencies [6e9a3d4]
|
|
1819
|
+
- Updated dependencies [4a292d2]
|
|
1820
|
+
- Updated dependencies [5323168]
|
|
1821
|
+
- Updated dependencies [841dd2b]
|
|
1822
|
+
- Updated dependencies [3014fc0]
|
|
1823
|
+
- Updated dependencies [dacb402]
|
|
1824
|
+
- Updated dependencies [846cec0]
|
|
1825
|
+
- Updated dependencies [91facae]
|
|
1826
|
+
- Updated dependencies [b38014e]
|
|
1827
|
+
- Updated dependencies [e2feb13]
|
|
1828
|
+
- Updated dependencies [474797d]
|
|
1829
|
+
- Updated dependencies [704e695]
|
|
1830
|
+
- Updated dependencies [9dcc545]
|
|
1831
|
+
- Updated dependencies [d7fecfb]
|
|
1832
|
+
- Updated dependencies [c13d39e]
|
|
1833
|
+
- Updated dependencies [a407bd6]
|
|
1834
|
+
- Updated dependencies [317dbce]
|
|
1835
|
+
- Updated dependencies [309728c]
|
|
1836
|
+
- Updated dependencies [e6ec217]
|
|
1837
|
+
- Updated dependencies [aa08d7e]
|
|
1838
|
+
- Updated dependencies [3a43a15]
|
|
1839
|
+
- Updated dependencies [868e825]
|
|
1840
|
+
- Updated dependencies [f76f436]
|
|
1841
|
+
- Updated dependencies [ce45a03]
|
|
1842
|
+
- Updated dependencies [7cf6f38]
|
|
1843
|
+
- Updated dependencies [fd9c50a]
|
|
1844
|
+
- Updated dependencies [421544b]
|
|
1845
|
+
- Updated dependencies [5cc8c28]
|
|
1846
|
+
- Updated dependencies [fb01022]
|
|
1847
|
+
- Updated dependencies [e9d9212]
|
|
1848
|
+
- Updated dependencies [ecfb693]
|
|
1849
|
+
- Updated dependencies [40a7c53]
|
|
1850
|
+
- Updated dependencies [abc1b18]
|
|
1851
|
+
- Updated dependencies [81a51db]
|
|
1852
|
+
- Updated dependencies [67749c7]
|
|
1853
|
+
- Updated dependencies [507b61b]
|
|
1854
|
+
- Updated dependencies [512c84b]
|
|
1855
|
+
- Updated dependencies [c300267]
|
|
1856
|
+
- Updated dependencies [fb3a101]
|
|
1857
|
+
- Updated dependencies [d4733f2]
|
|
1858
|
+
- Updated dependencies [7c9145f]
|
|
1859
|
+
- Updated dependencies [1570eac]
|
|
1860
|
+
- Updated dependencies [f391ede]
|
|
1861
|
+
- Updated dependencies [f5cfbbd]
|
|
1862
|
+
- Updated dependencies [f5cfbbd]
|
|
1863
|
+
- Updated dependencies [8b532cb]
|
|
1864
|
+
- Updated dependencies [64c3cdd]
|
|
1865
|
+
- Updated dependencies [4d65991]
|
|
1866
|
+
- Updated dependencies [c42554e]
|
|
1867
|
+
- Updated dependencies [555b4ec]
|
|
1868
|
+
- Updated dependencies [1ccfc23]
|
|
1869
|
+
- Updated dependencies [542718f]
|
|
1870
|
+
- Updated dependencies [7f27bc5]
|
|
1871
|
+
- Updated dependencies [0a174f3]
|
|
1872
|
+
- Updated dependencies [cc00c59]
|
|
1873
|
+
- Updated dependencies [676f677]
|
|
1874
|
+
- Updated dependencies [f95b140]
|
|
1875
|
+
- Updated dependencies [541ce4e]
|
|
1876
|
+
- Updated dependencies [6479086]
|
|
1877
|
+
- Updated dependencies [d79f525]
|
|
1878
|
+
- Updated dependencies [d1865d2]
|
|
1879
|
+
- Updated dependencies [ab77513]
|
|
1880
|
+
- Updated dependencies [55ba3ff]
|
|
1881
|
+
- Updated dependencies [0b138da]
|
|
1882
|
+
- Updated dependencies [f1190b0]
|
|
1883
|
+
- Updated dependencies [561abef]
|
|
1884
|
+
- Updated dependencies [ef52001]
|
|
1885
|
+
- Updated dependencies [6a4680b]
|
|
1886
|
+
- Updated dependencies [c3a4273]
|
|
1887
|
+
- Updated dependencies [abf710d]
|
|
1888
|
+
- Updated dependencies [093af32]
|
|
1889
|
+
- Updated dependencies [6df26f0]
|
|
1890
|
+
- Updated dependencies [1bd1be7]
|
|
1891
|
+
- Updated dependencies [d234fa9]
|
|
1892
|
+
- Updated dependencies [adf5812]
|
|
1893
|
+
- Updated dependencies [e36acd4]
|
|
1894
|
+
- Updated dependencies [5058336]
|
|
1895
|
+
- Updated dependencies [2f6b2bf]
|
|
1896
|
+
- Updated dependencies [2028b31]
|
|
1897
|
+
- Updated dependencies [16a1a51]
|
|
1898
|
+
- Updated dependencies [63601ab]
|
|
1899
|
+
- Updated dependencies [c372b29]
|
|
1900
|
+
- Updated dependencies [152f0a7]
|
|
1901
|
+
- Updated dependencies [8693b85]
|
|
1902
|
+
- Updated dependencies [e82dad1]
|
|
1903
|
+
- Updated dependencies [58b7b3d]
|
|
1904
|
+
- Updated dependencies [e77a003]
|
|
1905
|
+
- Updated dependencies [84defab]
|
|
1906
|
+
- Updated dependencies [681d3f1]
|
|
1907
|
+
- Updated dependencies [969d4f2]
|
|
1908
|
+
- Updated dependencies [88561fd]
|
|
1909
|
+
- Updated dependencies [f3bc481]
|
|
1910
|
+
- Updated dependencies [b79aac2]
|
|
1911
|
+
- Updated dependencies [93fc0e7]
|
|
1912
|
+
- Updated dependencies [0601af1]
|
|
1913
|
+
- Updated dependencies [a4b723f]
|
|
1914
|
+
- Updated dependencies [2b10ca0]
|
|
1915
|
+
- Updated dependencies [7db4a81]
|
|
1916
|
+
- Updated dependencies [19a0b0e]
|
|
1917
|
+
- Updated dependencies [526fc11]
|
|
1918
|
+
- Updated dependencies [f8e3e9a]
|
|
1919
|
+
- Updated dependencies [b9d47ec]
|
|
1920
|
+
- Updated dependencies [3b6bc69]
|
|
1921
|
+
- Updated dependencies [6214db6]
|
|
1922
|
+
- Updated dependencies [6732df4]
|
|
1923
|
+
- Updated dependencies [fe9e0d0]
|
|
1924
|
+
- Updated dependencies [63fb72c]
|
|
1925
|
+
- Updated dependencies [804831c]
|
|
1926
|
+
- Updated dependencies [9f5c017]
|
|
1927
|
+
- Updated dependencies [c271413]
|
|
1928
|
+
- Updated dependencies [279e48e]
|
|
1929
|
+
- Updated dependencies [4784bb3]
|
|
1930
|
+
- Updated dependencies [8700d6d]
|
|
1931
|
+
- Updated dependencies [8db2a0f]
|
|
1932
|
+
- Updated dependencies [689953a]
|
|
1933
|
+
- Updated dependencies [30443fb]
|
|
1934
|
+
- Updated dependencies [8d3dbb2]
|
|
1935
|
+
- Updated dependencies [efc1c9c]
|
|
1936
|
+
- Updated dependencies [7d6439c]
|
|
1937
|
+
- Updated dependencies [da45e6b]
|
|
1938
|
+
- Updated dependencies [7533465]
|
|
1939
|
+
- Updated dependencies [835f0f3]
|
|
1940
|
+
- Updated dependencies [6d5db7b]
|
|
1941
|
+
- Updated dependencies [a9d97be]
|
|
1942
|
+
- Updated dependencies [ed35b44]
|
|
1943
|
+
- Updated dependencies [e6040ef]
|
|
1944
|
+
- Updated dependencies [9ba7e9c]
|
|
1945
|
+
- Updated dependencies [729e851]
|
|
1946
|
+
- Updated dependencies [96919a4]
|
|
1947
|
+
- Updated dependencies [345e24a]
|
|
1948
|
+
- Updated dependencies [3bc1bb4]
|
|
1949
|
+
- Updated dependencies [20b507a]
|
|
1950
|
+
- Updated dependencies [2e471dc]
|
|
1951
|
+
- Updated dependencies [6748587]
|
|
1952
|
+
- Updated dependencies [be50942]
|
|
1953
|
+
- Updated dependencies [775e079]
|
|
1954
|
+
- Updated dependencies [7e8b3c0]
|
|
1955
|
+
- Updated dependencies [53374dc]
|
|
1956
|
+
- Updated dependencies [f6fb83f]
|
|
1957
|
+
- Updated dependencies [2049b03]
|
|
1958
|
+
- Updated dependencies [2bf34f7]
|
|
1959
|
+
- Updated dependencies [15b33ae]
|
|
1960
|
+
- Updated dependencies [7cbc724]
|
|
1961
|
+
- Updated dependencies [4a94c38]
|
|
1962
|
+
- Updated dependencies [7098eed]
|
|
1963
|
+
- Updated dependencies [3df7c5c]
|
|
1964
|
+
- Updated dependencies [fb91ac9]
|
|
1965
|
+
- Updated dependencies [fb91ac9]
|
|
1966
|
+
- Updated dependencies [641fb55]
|
|
1967
|
+
- Updated dependencies [8524372]
|
|
1968
|
+
- Updated dependencies [7cbefa5]
|
|
1969
|
+
- Updated dependencies [72d6587]
|
|
1970
|
+
- Updated dependencies [a272a4f]
|
|
1971
|
+
- Updated dependencies [55f39ee]
|
|
1972
|
+
- Updated dependencies [502eb58]
|
|
1973
|
+
- Updated dependencies [0ce32d5]
|
|
1974
|
+
- Updated dependencies [0970a0e]
|
|
1975
|
+
- Updated dependencies [e427e9c]
|
|
1976
|
+
- Updated dependencies [bbc9dc3]
|
|
1977
|
+
- Updated dependencies [02f1813]
|
|
1978
|
+
- Updated dependencies [1ef89c0]
|
|
1979
|
+
- Updated dependencies [ba0b61a]
|
|
1980
|
+
- Updated dependencies [ba0b61a]
|
|
1981
|
+
- Updated dependencies [ba0b61a]
|
|
1982
|
+
- Updated dependencies [ac716ff]
|
|
1983
|
+
- Updated dependencies [697aabc]
|
|
1984
|
+
- Updated dependencies [f0f3cd5]
|
|
1985
|
+
- Updated dependencies [ab856ed]
|
|
1986
|
+
- Updated dependencies [20f3e65]
|
|
1987
|
+
- Updated dependencies [bbba098]
|
|
1988
|
+
- Updated dependencies [87af769]
|
|
1989
|
+
- Updated dependencies [3be720e]
|
|
1990
|
+
- Updated dependencies [80a0ecd]
|
|
1991
|
+
- Updated dependencies [43c0d17]
|
|
1992
|
+
- Updated dependencies [c3df43a]
|
|
1993
|
+
- Updated dependencies [d16d0e9]
|
|
1994
|
+
- Updated dependencies [bbe57fd]
|
|
1995
|
+
- Updated dependencies [272a530]
|
|
1996
|
+
- Updated dependencies [462bafb]
|
|
1997
|
+
- Updated dependencies [1779e8d]
|
|
1998
|
+
- Updated dependencies [f7fcc2c]
|
|
1999
|
+
- Updated dependencies [f0f4d6c]
|
|
2000
|
+
- Updated dependencies [4128188]
|
|
2001
|
+
- Updated dependencies [b253c4e]
|
|
2002
|
+
- Updated dependencies [78a9c67]
|
|
2003
|
+
- Updated dependencies [4a7ef0d]
|
|
2004
|
+
- Updated dependencies [4598f6d]
|
|
2005
|
+
- Updated dependencies [dea17b4]
|
|
2006
|
+
- Updated dependencies [89bb77a]
|
|
2007
|
+
- Updated dependencies [06611e4]
|
|
2008
|
+
- Updated dependencies [44152c4]
|
|
2009
|
+
- Updated dependencies [3939545]
|
|
2010
|
+
- Updated dependencies [66abbde]
|
|
2011
|
+
- Updated dependencies [dc3893d]
|
|
2012
|
+
- Updated dependencies [1bbaa16]
|
|
2013
|
+
- Updated dependencies [6ee259a]
|
|
2014
|
+
- Updated dependencies [7649f43]
|
|
2015
|
+
- Updated dependencies [d0f52e4]
|
|
2016
|
+
- Updated dependencies [e708426]
|
|
2017
|
+
- Updated dependencies [33e1697]
|
|
2018
|
+
- Updated dependencies [3b6d53b]
|
|
2019
|
+
- Updated dependencies [a017617]
|
|
2020
|
+
- Updated dependencies [276d174]
|
|
2021
|
+
- Updated dependencies [2982ed9]
|
|
2022
|
+
- Updated dependencies [741864f]
|
|
2023
|
+
- Updated dependencies [a8198de]
|
|
2024
|
+
- Updated dependencies [0c789a4]
|
|
2025
|
+
- Updated dependencies [05a49f2]
|
|
2026
|
+
- Updated dependencies [b234a84]
|
|
2027
|
+
- Updated dependencies [a78cd37]
|
|
2028
|
+
- Updated dependencies [5ea623e]
|
|
2029
|
+
- Updated dependencies [dc49246]
|
|
2030
|
+
- Updated dependencies [5eabe86]
|
|
2031
|
+
- Updated dependencies [ca5d671]
|
|
2032
|
+
- Updated dependencies [32bf2d6]
|
|
2033
|
+
- Updated dependencies [ff0c384]
|
|
2034
|
+
- Updated dependencies [af4fb29]
|
|
2035
|
+
- Updated dependencies [c698a81]
|
|
2036
|
+
- Updated dependencies [ff5ef1c]
|
|
2037
|
+
- Updated dependencies [befd40c]
|
|
2038
|
+
- Updated dependencies [905913c]
|
|
2039
|
+
- Updated dependencies [9a97800]
|
|
2040
|
+
- Updated dependencies [6358a2d]
|
|
2041
|
+
- Updated dependencies [6bca0e4]
|
|
2042
|
+
- Updated dependencies [81c0bc4]
|
|
2043
|
+
- Updated dependencies [3c76801]
|
|
2044
|
+
- Updated dependencies [d06fba8]
|
|
2045
|
+
- Updated dependencies [60500cb]
|
|
2046
|
+
- Updated dependencies [2fcefb9]
|
|
2047
|
+
- Updated dependencies [77f846a]
|
|
2048
|
+
- Updated dependencies [bc5870c]
|
|
2049
|
+
- Updated dependencies [b55a346]
|
|
2050
|
+
- Updated dependencies [065bba7]
|
|
2051
|
+
- Updated dependencies [f760064]
|
|
2052
|
+
- Updated dependencies [dd19463]
|
|
2053
|
+
- Updated dependencies [6791717]
|
|
2054
|
+
- Updated dependencies [8ea3bee]
|
|
2055
|
+
- Updated dependencies [100547e]
|
|
2056
|
+
- Updated dependencies [3a58149]
|
|
2057
|
+
- Updated dependencies [6d1c155]
|
|
2058
|
+
- Updated dependencies [d7573b3]
|
|
2059
|
+
- Updated dependencies [bf3edfe]
|
|
2060
|
+
- Updated dependencies [2c8474c]
|
|
2061
|
+
- Updated dependencies [6ce89da]
|
|
2062
|
+
- Updated dependencies [0e05aac]
|
|
2063
|
+
- Updated dependencies [ae61ad4]
|
|
2064
|
+
- Updated dependencies [5aed9e4]
|
|
2065
|
+
- Updated dependencies [83c77dc]
|
|
2066
|
+
- Updated dependencies [3c9fca3]
|
|
2067
|
+
- Updated dependencies [18a8e7d]
|
|
2068
|
+
- Updated dependencies [e7957ab]
|
|
2069
|
+
- Updated dependencies [f7e34ca]
|
|
2070
|
+
- Updated dependencies [e719ebd]
|
|
2071
|
+
- Updated dependencies [516583b]
|
|
2072
|
+
- Updated dependencies [f9e4f91]
|
|
2073
|
+
- Updated dependencies [6ef48b1]
|
|
2074
|
+
- Updated dependencies [fa429cf]
|
|
2075
|
+
- Updated dependencies [ed8df3e]
|
|
2076
|
+
- Updated dependencies [fe76ece]
|
|
2077
|
+
- Updated dependencies [8b446f5]
|
|
2078
|
+
- Updated dependencies [8e74b27]
|
|
2079
|
+
- Updated dependencies [7102b20]
|
|
2080
|
+
- Updated dependencies [8ebd57f]
|
|
2081
|
+
- Updated dependencies [617707a]
|
|
2082
|
+
- Updated dependencies [c40f3b8]
|
|
2083
|
+
- Updated dependencies [58770f3]
|
|
2084
|
+
- Updated dependencies [aefe428]
|
|
2085
|
+
- Updated dependencies [485f096]
|
|
2086
|
+
- Updated dependencies [7357447]
|
|
2087
|
+
- Updated dependencies [199d31b]
|
|
2088
|
+
- Updated dependencies [b655a9d]
|
|
2089
|
+
- Updated dependencies [3e01cb5]
|
|
2090
|
+
- Updated dependencies [7138bc1]
|
|
2091
|
+
- Updated dependencies [cef27e2]
|
|
2092
|
+
- Updated dependencies [4e8622b]
|
|
2093
|
+
- Updated dependencies [dffd752]
|
|
2094
|
+
- Updated dependencies [06973aa]
|
|
2095
|
+
- Updated dependencies [50798f3]
|
|
2096
|
+
- Updated dependencies [6a576c9]
|
|
2097
|
+
- Updated dependencies [0b12a33]
|
|
2098
|
+
- Updated dependencies [105f3c5]
|
|
2099
|
+
- Updated dependencies [3ccd9e8]
|
|
2100
|
+
- Updated dependencies [689b979]
|
|
2101
|
+
- Updated dependencies [c70f865]
|
|
2102
|
+
- Updated dependencies [e546222]
|
|
2103
|
+
- Updated dependencies [fd13f52]
|
|
2104
|
+
- Updated dependencies [d7bd274]
|
|
2105
|
+
- Updated dependencies [98c3a74]
|
|
2106
|
+
- Updated dependencies [fffa30d]
|
|
2107
|
+
- Updated dependencies [ebce5a3]
|
|
2108
|
+
- Updated dependencies [fb336df]
|
|
2109
|
+
- Updated dependencies [6c1b105]
|
|
2110
|
+
- Updated dependencies [4dc80d0]
|
|
2111
|
+
- Updated dependencies [9d9040d]
|
|
2112
|
+
- Updated dependencies [20e317c]
|
|
2113
|
+
- Updated dependencies [0fce2ef]
|
|
2114
|
+
- Updated dependencies [42df928]
|
|
2115
|
+
- Updated dependencies [0e2ddd4]
|
|
2116
|
+
- Updated dependencies [b7479ab]
|
|
2117
|
+
- Updated dependencies [9850c6e]
|
|
2118
|
+
- Updated dependencies [de570cc]
|
|
2119
|
+
- Updated dependencies [b2ea297]
|
|
2120
|
+
- Updated dependencies [5b5a5c3]
|
|
2121
|
+
- Updated dependencies [14582b8]
|
|
2122
|
+
- Updated dependencies [51e144e]
|
|
2123
|
+
- Updated dependencies [19cbf10]
|
|
2124
|
+
- Updated dependencies [7e50e84]
|
|
2125
|
+
- Updated dependencies [ab92940]
|
|
2126
|
+
- Updated dependencies [a691c0b]
|
|
2127
|
+
- Updated dependencies [0b1326d]
|
|
2128
|
+
- Updated dependencies [1e66879]
|
|
2129
|
+
- Updated dependencies [c5200f0]
|
|
2130
|
+
- Updated dependencies [af3861f]
|
|
2131
|
+
- Updated dependencies [2a79e84]
|
|
2132
|
+
- Updated dependencies [2609812]
|
|
2133
|
+
- Updated dependencies [515f171]
|
|
2134
|
+
- Updated dependencies [1f4e029]
|
|
2135
|
+
- Updated dependencies [4f14ad7]
|
|
2136
|
+
- Updated dependencies [258d264]
|
|
2137
|
+
- Updated dependencies [cac64b3]
|
|
2138
|
+
- Updated dependencies [17fbbaf]
|
|
2139
|
+
- Updated dependencies [d8cf1cb]
|
|
2140
|
+
- Updated dependencies [0d1e702]
|
|
2141
|
+
- Updated dependencies [b03ba3a]
|
|
2142
|
+
- Updated dependencies [0068348]
|
|
2143
|
+
- Updated dependencies [641543f]
|
|
2144
|
+
- Updated dependencies [8a44390]
|
|
2145
|
+
- Updated dependencies [8033ad1]
|
|
2146
|
+
- Updated dependencies [fa140b8]
|
|
2147
|
+
- Updated dependencies [71cba28]
|
|
2148
|
+
- Updated dependencies [190fbd0]
|
|
2149
|
+
- Updated dependencies [c00bf28]
|
|
2150
|
+
- Updated dependencies [23705b7]
|
|
2151
|
+
- Updated dependencies [93127bd]
|
|
2152
|
+
- Updated dependencies [f2158ec]
|
|
2153
|
+
- Updated dependencies [759606e]
|
|
2154
|
+
- Updated dependencies [fd8dace]
|
|
2155
|
+
- Updated dependencies [72ffc34]
|
|
2156
|
+
- Updated dependencies [a51fa0c]
|
|
2157
|
+
- Updated dependencies [51f3d8d]
|
|
2158
|
+
- Updated dependencies [bf28341]
|
|
2159
|
+
- Updated dependencies [78cbdb5]
|
|
2160
|
+
- Updated dependencies [b7543a9]
|
|
2161
|
+
- Updated dependencies [6c6cee7]
|
|
2162
|
+
- Updated dependencies [42887e0]
|
|
2163
|
+
- Updated dependencies [83fe6e7]
|
|
2164
|
+
- Updated dependencies [d1ab06f]
|
|
2165
|
+
- Updated dependencies [38a9568]
|
|
2166
|
+
- Updated dependencies [f90b8fb]
|
|
2167
|
+
- Updated dependencies [91783c4]
|
|
2168
|
+
- Updated dependencies [982885d]
|
|
2169
|
+
- Updated dependencies [dba7d84]
|
|
2170
|
+
- Updated dependencies [ca39427]
|
|
2171
|
+
- Updated dependencies [bd09957]
|
|
2172
|
+
- Updated dependencies [5a07e67]
|
|
2173
|
+
- Updated dependencies [2d36552]
|
|
2174
|
+
- Updated dependencies [45d8288]
|
|
2175
|
+
- Updated dependencies [b2437a7]
|
|
2176
|
+
- Updated dependencies [f157423]
|
|
2177
|
+
- Updated dependencies [7a90afd]
|
|
2178
|
+
- Updated dependencies [eddc1dd]
|
|
2179
|
+
- Updated dependencies [490f482]
|
|
2180
|
+
- Updated dependencies [27308c5]
|
|
2181
|
+
- Updated dependencies [8689166]
|
|
2182
|
+
- Updated dependencies [c9327c9]
|
|
2183
|
+
- Updated dependencies [920165d]
|
|
2184
|
+
- Updated dependencies [9101be5]
|
|
2185
|
+
- Updated dependencies [f53a8d0]
|
|
2186
|
+
- Updated dependencies [30266cf]
|
|
2187
|
+
- Updated dependencies [968dc1e]
|
|
2188
|
+
- Updated dependencies [57f9b07]
|
|
2189
|
+
- Updated dependencies [3c73d99]
|
|
2190
|
+
- Updated dependencies [d91aed9]
|
|
2191
|
+
- Updated dependencies [ed71d9e]
|
|
2192
|
+
- Updated dependencies [7776fc2]
|
|
2193
|
+
- Updated dependencies [e76634c]
|
|
2194
|
+
- Updated dependencies [c86185e]
|
|
2195
|
+
- Updated dependencies [fb96ecb]
|
|
2196
|
+
- Updated dependencies [1170ed1]
|
|
2197
|
+
- Updated dependencies [92814db]
|
|
2198
|
+
- Updated dependencies [4d73b07]
|
|
2199
|
+
- @object-ui/plugin-detail@17.7.0
|
|
2200
|
+
- @object-ui/react@17.7.0
|
|
2201
|
+
- @object-ui/core@17.7.0
|
|
2202
|
+
- @object-ui/types@17.7.0
|
|
2203
|
+
- @object-ui/i18n@17.7.0
|
|
2204
|
+
- @object-ui/components@17.7.0
|
|
2205
|
+
- @object-ui/permissions@17.7.0
|
|
2206
|
+
|
|
3
2207
|
## 17.6.0
|
|
4
2208
|
|
|
5
2209
|
### Patch Changes
|