@object-ui/plugin-map 17.5.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 +2193 -0
- package/README.md +237 -241
- package/dist/ObjectMap.d.ts +33 -4
- package/dist/ObjectMap.d.ts.map +1 -1
- package/dist/camera.d.ts +102 -0
- package/dist/camera.d.ts.map +1 -0
- package/dist/index.d.ts +39 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +350 -259
- package/dist/index.umd.cjs +1 -1
- package/package.json +12 -12
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,2198 @@
|
|
|
1
1
|
# @object-ui/plugin-map
|
|
2
2
|
|
|
3
|
+
## 17.7.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 64563a9: **BREAKING (node type key):** `@object-ui/plugin-map` no longer registers the bare
|
|
8
|
+
`map` node type key, and its namespaced twin `view:map` goes with it. A node
|
|
9
|
+
authored `"type": "map"` no longer resolves a renderer. Write
|
|
10
|
+
`"type": "object-map"` — the one spelling the plugin serves (objectui#10393,
|
|
11
|
+
executing the objectui#8008 family ruling of 2026-09-09 that retired the bare
|
|
12
|
+
`gantt` and `kanban` keys).
|
|
13
|
+
|
|
14
|
+
**Why.** The registry mounted a `map` node while the published declaration refused
|
|
15
|
+
it: `ObjectMapSchema.type` is the literal `'object-map'` and `AnyComponentSchema`
|
|
16
|
+
has no `map` arm, so `safeValidateSchema` answered a `map` node with
|
|
17
|
+
`invalid_union` while the html tier accepted it. Two faces, opposite verdicts.
|
|
18
|
+
No schema face ever declared `map` as a component node type, so there is no arm
|
|
19
|
+
to turn into a named refusal: unregistering is the whole retirement, exactly as
|
|
20
|
+
it was for `gantt`. After it, the html tier (`validateTree` over the live
|
|
21
|
+
registry) reports a `map` node as `unknown-component`, matching the Zod face.
|
|
22
|
+
|
|
23
|
+
**⛔ No stored document moves.** The string `map` names two different things at
|
|
24
|
+
two different layers, and only one of them is retiring:
|
|
25
|
+
|
|
26
|
+
| layer | value | who writes it | retired? |
|
|
27
|
+
| --- | --- | --- | --- |
|
|
28
|
+
| stored `NamedListView.type` / `defaultViewType` | `"map"` | `CreateViewDialog`, persisted per tenant | **no — untouched** |
|
|
29
|
+
| node type key | `map`, `view:map` | hand-authored JSON | **yes** |
|
|
30
|
+
|
|
31
|
+
`ObjectView` and `ListView` map a stored `map` view onto the node type they
|
|
32
|
+
render, and both already emit `object-map`, so every map view created through
|
|
33
|
+
the console keeps rendering. Nothing in a tenant database changes, and ⛔ nothing
|
|
34
|
+
should be migrated there.
|
|
35
|
+
|
|
36
|
+
**What moved with it.**
|
|
37
|
+
|
|
38
|
+
- `@object-ui/console` drops its lazy `map` / `view:map` registration stub; the
|
|
39
|
+
lazy `object-map` stub is unchanged.
|
|
40
|
+
- `@object-ui/core`: `recordSourceDataArmForType` no longer lists the `map` and
|
|
41
|
+
`view:map` rows, since no block is registered under either key.
|
|
42
|
+
- `@object-ui/cli`: the generated known-type list that `objectui check` reads no
|
|
43
|
+
longer contains bare `map`, so the check now reports `map` as an unknown
|
|
44
|
+
schema type in a file it recognises. ⚠️ `view:map` stays on
|
|
45
|
+
that list, because the opt-in protocol placeholder (`registerPlaceholders()`
|
|
46
|
+
in `@object-ui/components`) registers it — in the console a `view:map` node
|
|
47
|
+
renders that placeholder panel, not a map, and `objectui check` does not report
|
|
48
|
+
it as an unknown schema type in a file it recognises. A bare
|
|
49
|
+
`{ "type": "view:map" }` with no structural key is listed in `check`'s advisory
|
|
50
|
+
did-not-validate list instead, because `view:map` is on the known-type list and
|
|
51
|
+
`AnyComponentSchema` has no arm for it; that line does not say the node renders
|
|
52
|
+
a placeholder. Search documents for `view:map` directly.
|
|
53
|
+
|
|
54
|
+
⚠️ **Dated note, 2026-09-25 — `objectui check` flags `map` only in a file it
|
|
55
|
+
recognises — objectui#10606.** This entry first said, unscoped, that the check now
|
|
56
|
+
flags bare `map`. `check` checks the `type` of each file it recognises, and a file
|
|
57
|
+
whose root carries an ObjectUI structural key (`children`, `className`, `body`, …)
|
|
58
|
+
is recognised by that key alone. A file with none of those keys is parsed against
|
|
59
|
+
the schema and recognised only if it validates; one that does not validate is
|
|
60
|
+
listed by name when its root `type` is on that known-type list, and is otherwise
|
|
61
|
+
counted as skipped. `map` is no longer on it, so `{ "type": "map" }` is
|
|
62
|
+
counted as skipped ("no ObjectUI recogniser admitted") and gets no unknown-type
|
|
63
|
+
line, while `{ "type": "map", "className": "h-64" }` gets one. `check` exits
|
|
64
|
+
non-zero on unreadable JSON only; the verdict is `objectui validate`'s: it refuses
|
|
65
|
+
`{ "type": "map" }` at `type` (`invalid_union`) and exits non-zero.
|
|
66
|
+
|
|
67
|
+
The `@object-ui/plugin-map` README now describes one registered type, and its
|
|
68
|
+
sentence claiming a bare array under `data` reaches the in-memory adapter is
|
|
69
|
+
corrected: a bare array under `data` is not a record source on the map
|
|
70
|
+
(objectui#8348), so inline rows belong under `staticData`. The same false claim
|
|
71
|
+
is corrected on the two docs pages that carried it, `plugins/plugin-map.mdx`
|
|
72
|
+
and `fields/location.mdx`.
|
|
73
|
+
|
|
74
|
+
**One pending entry in this same release is superseded in part.** The
|
|
75
|
+
objectui#10392 / #10394 entry (`10392-registration-record-source-inputs.md`)
|
|
76
|
+
says `object-map`, `map` and `object-gantt` gained `data` / `staticData`
|
|
77
|
+
inputs. It now reads as of its own change and carries a dated note naming this
|
|
78
|
+
card: `map` declares nothing after this retirement, while `object-map` and
|
|
79
|
+
`object-gantt` keep both inputs.
|
|
80
|
+
- 20d23be: `object-map` publishes the three keys its `@objectstack/spec` 17.5.0 row declares and its registration left out: `mapStyle`, `navigation` and `enableClustering` (objectui#11168 slice 3, objectui#11111 decision 3 = B). Each was measured on the real renderer first, and the renderer honours all three. The page validator used to report each one as an unknown prop.
|
|
81
|
+
|
|
82
|
+
- `mapStyle` replaces the demo tiles. Its description is the spec row's own, verbatim: it is read before `map.style`. The renderer now reads it that way too; the `mapStyle` precedence entry in this release states that change.
|
|
83
|
+
- `enableClustering: true` clusters nearby markers. Without the key, the map clusters only above 100 markers, and `false` turns clustering off at any count.
|
|
84
|
+
- On `navigation`, `drawer`, `modal` and `popover` open the marker's record. `new_window`, or `openNewTab: true`, opens the record page in a new tab. `page` and a block without `mode` open the record page of the map's `objectName` through the record navigator the host publishes (the console publishes one on its custom pages, record pages and list views). Under a host that publishes none, or on a map that names no `objectName`, they open nothing. On a map that no parent view navigates for, a click also opens nothing when the key is absent or the mode is `none` or `split`.
|
|
85
|
+
|
|
86
|
+
The `map` input's description now lists its members. Apart from the `mapStyle` precedence, rendering is unchanged.
|
|
87
|
+
- 7c3df8f: A non-grid view's fetch now carries a platform row ceiling, and crossing it is
|
|
88
|
+
never silent (objectui#7210, maintainer ruling a′, 2026-09-02).
|
|
89
|
+
|
|
90
|
+
Before this, `ObjectGantt`, `ObjectCalendar`, `ObjectMap` and `ObjectTree` each
|
|
91
|
+
issued a `find` with **no `$top` at all**, so the request returned the entire
|
|
92
|
+
filtered result set. At the 186 rows the card was filed from that is invisible;
|
|
93
|
+
on an object with 100k scheduled rows it is the whole table into the browser,
|
|
94
|
+
and nothing an author could write — `pagination.pageSize` included — could
|
|
95
|
+
bound a request that never carried a cap to begin with.
|
|
96
|
+
|
|
97
|
+
**What changed.** Those four fetches now ask for `NON_GRID_ROW_CEILING_TOP`
|
|
98
|
+
rows, draw at most `NON_GRID_ROW_CEILING` of them, and when the result set was
|
|
99
|
+
larger they render a footnote naming both numbers, verbatim as it renders:
|
|
100
|
+
*"Showing the first 2000 of 41234 records. Narrow the filter."* Below the
|
|
101
|
+
ceiling nothing changes: the full set draws and no footnote appears.
|
|
102
|
+
|
|
103
|
+
The four view packages take a **minor**, not a patch: a result set above the
|
|
104
|
+
ceiling is no longer drawn in full, which is a behaviour break whatever the
|
|
105
|
+
fixed group does to the released version number.
|
|
106
|
+
|
|
107
|
+
**The ceiling is a platform constant, not an authorable key** — `2000`, exported
|
|
108
|
+
from `@object-ui/react` as `NON_GRID_ROW_CEILING`. An authored `limit` or
|
|
109
|
+
`dataSource: { limit }` still does not reach these queries, by the same ruling;
|
|
110
|
+
three alternatives were rejected with it (a documentation note only — still the
|
|
111
|
+
whole table; truncating at `pageSize` — silent, and a complete schedule capped
|
|
112
|
+
at one page; an authorable `maxRows` — a new permanent key every author sets).
|
|
113
|
+
|
|
114
|
+
**Why 2,000.** One constant for all four, so the binding view sets it. Measured
|
|
115
|
+
in this repo's jsdom lane: gantt, calendar and map hold their DOM flat as rows
|
|
116
|
+
grow (virtualised task list; four events per day cell; auto-clustering above
|
|
117
|
+
100 markers), while `ObjectTree` flattens every expanded node into the document
|
|
118
|
+
at a linear **5.2 DOM elements per record** with no virtualisation. 2,000 rows
|
|
119
|
+
is where the worst of the four lands at ~10,400 elements — an order of
|
|
120
|
+
magnitude above Lighthouse's "excessive DOM size" warning, and still ~10x the
|
|
121
|
+
real application result set this card came from.
|
|
122
|
+
|
|
123
|
+
New exports on `@object-ui/react`: `NON_GRID_ROW_CEILING`,
|
|
124
|
+
`NON_GRID_ROW_CEILING_TOP`, `applyNonGridRowCeiling`, `NonGridRowCeilingNote`
|
|
125
|
+
and the type `NonGridCeilingResult`. Two new `common.*` i18n keys carry the
|
|
126
|
+
footnote copy in all ten packs.
|
|
127
|
+
- b041b9c: `@object-ui/core` publishes `resolveRecordSourceObjectName`, the ONE reader for "which
|
|
128
|
+
object is this block bound to".
|
|
129
|
+
|
|
130
|
+
Six view plugins each spelled that resolution locally — `ObjectCalendar` twice,
|
|
131
|
+
`ObjectGantt`, `ObjectTree` twice, `ObjectMap`, `ObjectGrid` — and had drifted: three
|
|
132
|
+
wrote `?? schema.objectName`, one `|| ''`, one `: undefined`, one an `'object' in
|
|
133
|
+
dataConfig` test. They now delegate to one function that states the published
|
|
134
|
+
record-source ladder `77cb489b4` declared (`data`, then `staticData`, then `objectName`) once.
|
|
135
|
+
|
|
136
|
+
**No behaviour changes.** Each site's pre-collapse expression is transcribed verbatim
|
|
137
|
+
into `record-source.behaviourNeutrality-7627.test.ts` and asserted equal to its
|
|
138
|
+
post-collapse spelling across the whole contract-valid input matrix — both bindings
|
|
139
|
+
present, data only, `objectName` only, empty `objectName`, empty `data.object`, the
|
|
140
|
+
`api` / `value` / `staticData` / array-shorthand providers, and nothing bound.
|
|
141
|
+
|
|
142
|
+
**Two questions stay two questions.** `normalizeListViewSchema`'s gap-fill (#7477,
|
|
143
|
+
ruling B, landed as `00d2fa682`) is untouched and is NOT re-pointed at the new reader: it answers
|
|
144
|
+
how `objectName` gets POPULATED when absent, where an already-present `objectName` wins.
|
|
145
|
+
The new reader answers which object a block RESOLVES, where the `data` block wins — the
|
|
146
|
+
order declared on both published faces in `@object-ui/types` and pinned by
|
|
147
|
+
`objectql-record-source-refinement-6939.test.ts`. Merging them would silently override
|
|
148
|
+
one standing ruling or the other.
|
|
149
|
+
|
|
150
|
+
**`ObjectGantt`'s `persistLayoutKey` is deliberately excluded** and keeps its inverted
|
|
151
|
+
order, with an in-place comment saying why: its receiver is a localStorage key
|
|
152
|
+
(`gantt-layout:KEY:filters`), not a record source, so re-pointing it would orphan every
|
|
153
|
+
saved layout and filter-chip set of a view carrying both bindings. Two more sites the
|
|
154
|
+
finding listed are not object-name readers at all and were struck: `ObjectGantt`'s
|
|
155
|
+
refresh-handler predicate (`object` OR `api`) and `plugin-dashboard`'s `isObjectProvider`
|
|
156
|
+
type-guard over a widget's `data`.
|
|
157
|
+
|
|
158
|
+
`useSettledSchema`'s doc comment stops prescribing the hand-written ladder at all four
|
|
159
|
+
lines that taught it, so the copies cannot re-seed from the hook that replaced them.
|
|
160
|
+
- cb725e7: An unbound map now REFUSES; coordinates are never guessed (objectui#8169, maintainer
|
|
161
|
+
ruling 2026-09-07, decision batch #67, option B).
|
|
162
|
+
|
|
163
|
+
**Behaviour change, deliberately, with no staged window.** A map with no coordinate
|
|
164
|
+
binding renders
|
|
165
|
+
|
|
166
|
+
> Map configuration required — declare `map.locationField` or `map.latitudeField` + `map.longitudeField`
|
|
167
|
+
|
|
168
|
+
in place of the map, instead of painting an empty one. The principle behind
|
|
169
|
+
the 2026-09-01 date-axis ruling (date axes are never invented) and objectui#5953 (a marker title is never
|
|
170
|
+
forged) now covers coordinates as well: bindings are never fabricated, and an unbound
|
|
171
|
+
surface refuses.
|
|
172
|
+
|
|
173
|
+
Three things moved together, because moving any one of them alone makes the tree worse:
|
|
174
|
+
|
|
175
|
+
- `@object-ui/plugin-map` — `getMapConfig` loses its default branch, the one that
|
|
176
|
+
returned the field names `latitude` / `longitude` / `location` / `description` when
|
|
177
|
+
the author declared nothing, and `ObjectMap` gains the refusal state above. The
|
|
178
|
+
refusal covers every branch, so a declared block that binds no coordinate field
|
|
179
|
+
(`map: { titleField: 'name' }`) and a half pair (`latitudeField` with no
|
|
180
|
+
`longitudeField`) refuse too — those used to render an empty map under the
|
|
181
|
+
excluded-records notice.
|
|
182
|
+
- `@object-ui/plugin-list` and `@object-ui/plugin-view` — the `locationField: … ||
|
|
183
|
+
'location'` floor each flattener added on the way into the map is deleted. The
|
|
184
|
+
flattened schema now carries exactly what the view declared.
|
|
185
|
+
|
|
186
|
+
⚠️ **Deleting the relay floors alone would have widened the guess, not closed it** —
|
|
187
|
+
measured on the card. The floor forced `getMapConfig`'s flat branch, which returns
|
|
188
|
+
`locationField` and no `latitudeField` / `longitudeField`, so dropping it on its own
|
|
189
|
+
would have handed undeclared views the component's three-name default branch instead of
|
|
190
|
+
one name, and records carrying real `latitude` / `longitude` columns would have *started*
|
|
191
|
+
plotting on views that declared nothing.
|
|
192
|
+
|
|
193
|
+
**Migration.** Declare the binding on any map view that relied on the old defaults:
|
|
194
|
+
`map: { locationField: 'your_field' }`, or `map: { latitudeField, longitudeField }`. A
|
|
195
|
+
record set carrying `latitude` / `longitude` (or `location`) columns no longer plots on a
|
|
196
|
+
view that declared no map block — it shows the refusal, which names what to write.
|
|
197
|
+
Interface pages are unaffected where the object actually has a location-typed field:
|
|
198
|
+
`defaultMapFromObject` derives `locationField` from the object's own field list, which is
|
|
199
|
+
a reading of declared metadata rather than a guess, and is unchanged.
|
|
200
|
+
- 0ea7054: Remove 37 runtime dependencies that no file in the declaring package consumes, and gate
|
|
201
|
+
the direction so the next one cannot land (objectui#8198).
|
|
202
|
+
|
|
203
|
+
`check:phantom-deps` judges imports that are not declared; nothing judged the reverse,
|
|
204
|
+
so a declaration could outlive its last consumer indefinitely. That is what happened to
|
|
205
|
+
`recharts` in `@object-ui/components` after objectui#7397 deleted its only importer — it
|
|
206
|
+
was removed by hand on objectui#7625, and nothing would have reported the next one. The
|
|
207
|
+
new `pnpm check:unused-deps` asks the reverse question over `dependencies` and
|
|
208
|
+
`optionalDependencies` of every released package.
|
|
209
|
+
|
|
210
|
+
**Potentially breaking, for consumers relying on hoisting.** Nothing these packages ship
|
|
211
|
+
changes: their Vite `external` predicates are path-based and never read `dependencies`,
|
|
212
|
+
so no built artifact moves. What changes is the install graph — a project that imports
|
|
213
|
+
one of the removed packages while depending only on the ObjectUI package that used to
|
|
214
|
+
drag it in will no longer resolve it. Declare it directly; that is the correct
|
|
215
|
+
dependency edge in either case. The removals, by package:
|
|
216
|
+
|
|
217
|
+
- `@object-ui/plugin-designer`: `@dnd-kit/core`, `@dnd-kit/sortable`, `@dnd-kit/utilities`, `@object-ui/fields`
|
|
218
|
+
- `@object-ui/plugin-chatbot`: `react-markdown`, `react-syntax-highlighter`, `remark-gfm` (and the orphaned `@types/react-syntax-highlighter`)
|
|
219
|
+
- `@object-ui/plugin-report`: `@object-ui/plugin-grid`, `clsx`, `react-i18next`, `tailwind-merge`
|
|
220
|
+
- `@object-ui/plugin-map`: `@objectstack/spec`, `lucide-react`, `zod`
|
|
221
|
+
- `@object-ui/runner`: `class-variance-authority`, `clsx`, `tailwind-merge`
|
|
222
|
+
- `@object-ui/core`: `lodash`, `zod`
|
|
223
|
+
- `@object-ui/layout`: `clsx`, `tailwind-merge`, and `react-dom` — which it pinned at an exact version in `dependencies` while also declaring it as a peer range, i.e. a library hard-depending on the renderer it asks its host to supply
|
|
224
|
+
- `@object-ui/plugin-dashboard`: `clsx`, `tailwind-merge`, and the same `react-dom` defect
|
|
225
|
+
- `@object-ui/plugin-ai`: `@object-ui/react`, `clsx`, `tailwind-merge`
|
|
226
|
+
- `@object-ui/fields`: `clsx`, `tailwind-merge`
|
|
227
|
+
- `@object-ui/console`: `@object-ui/react-runtime`, `sucrase`
|
|
228
|
+
- `@object-ui/auth`: `@object-ui/types`
|
|
229
|
+
- `@object-ui/plugin-calendar`: `@object-ui/fields`
|
|
230
|
+
- `@object-ui/plugin-editor`, `@object-ui/plugin-markdown`: `@object-ui/react`
|
|
231
|
+
- `@object-ui/react`: `react-hook-form`
|
|
232
|
+
|
|
233
|
+
Every one was verified by a whole-package grep before removal — the name appeared nowhere
|
|
234
|
+
under the package but its own manifest and CHANGELOG — and the whole workspace builds,
|
|
235
|
+
type-checks and tests green afterwards.
|
|
236
|
+
- 233a1b3: Declare the `filter` and `sort` inputs on the `object-map`, `object-gantt`,
|
|
237
|
+
`object-timeline` and `view:timeline` registrations (objectui#8220) — the html
|
|
238
|
+
tier stops reporting `unknown-prop` on two keys the spec declares and all three
|
|
239
|
+
renderers read.
|
|
240
|
+
|
|
241
|
+
objectui#7712's and objectui#8171's defect, three blocks over. `ObjectMap`,
|
|
242
|
+
`ObjectGantt` and `ObjectTimeline` each lower the authored keys onto their own
|
|
243
|
+
query — `$filter` (the authored `filter`, its context tokens resolved first) and
|
|
244
|
+
`$orderby: convertSortToQueryParams(schema.sort)` — but none of the four
|
|
245
|
+
registrations publishing those renderers listed either key in `inputs`, and
|
|
246
|
+
`sdui-parser`'s `validateTree` reports `unknown-prop` for every key no `inputs`
|
|
247
|
+
entry claims. An author writing the spelling that works was told it was unknown.
|
|
248
|
+
|
|
249
|
+
Unlike the kanban and calendar cases, these three blocks had no spec row when the
|
|
250
|
+
defect was filed, so declaring the keys then would have published an authoring
|
|
251
|
+
surface no contract backed. That order is now met on the installed package:
|
|
252
|
+
`@objectstack/spec` 17.5.0 maps `object-map`, `object-gantt` and `object-timeline`
|
|
253
|
+
in `ComponentPropsMap`, each row declaring `filter` as the `ViewFilterRule` array
|
|
254
|
+
and `sort` as the `SortItem` array. ADR-0049 enforce-or-remove therefore resolves
|
|
255
|
+
toward **declare**: both keys have live readers on both ends.
|
|
256
|
+
|
|
257
|
+
Both keys are declared `type: 'array'`. For `filter` that is the rule-array arm
|
|
258
|
+
`[{ field, operator, value }, ...]` and nothing else: the spec refuses the
|
|
259
|
+
MongoDB-style record form at all three doors, and with the key declared as an
|
|
260
|
+
array the html tier now refuses it too, as a `type-mismatch`, instead of passing
|
|
261
|
+
it as an unknown key. `sort` takes `[{ field, order }]`.
|
|
262
|
+
|
|
263
|
+
`view:timeline` declares the same pair as `object-timeline`: it is the same
|
|
264
|
+
renderer under a second tag, the `view:calendar` precedent. The map's and the
|
|
265
|
+
gantt's bare `view:` twins are already retired (objectui#10393, objectui#8008),
|
|
266
|
+
so four registrations carry the declaration, not six.
|
|
267
|
+
|
|
268
|
+
Pinned per plugin in `__tests__/queryKeysDeclared-8220.test.tsx`: the real
|
|
269
|
+
validator over a manifest built from the live registry, with an undeclared-key
|
|
270
|
+
control; the installed spec row's verdict on the same values; and a mount through
|
|
271
|
+
`SchemaRenderer` showing the rule array reach `$filter` and the sort items reach
|
|
272
|
+
`$orderby` on every tag.
|
|
273
|
+
|
|
274
|
+
Not changed here: the console's `registry-inputs-spec-parity` ledger. It does not
|
|
275
|
+
load these three plugins yet and books the blocks as unjudged, owed to
|
|
276
|
+
objectui#11168, so this change moves none of its rows.
|
|
277
|
+
|
|
278
|
+
**Note, 2026-10-02 (objectui#11168 slice 5, shipping in this same release).**
|
|
279
|
+
The last paragraph above says the console's `registry-inputs-spec-parity` gate
|
|
280
|
+
does not load these three plugins yet and books the blocks as unjudged. That no
|
|
281
|
+
longer holds for the release: objectui#11168 loaded all three in this same
|
|
282
|
+
release (`object-map` in slice 3, `object-gantt` in slice 4, `object-timeline`
|
|
283
|
+
in slice 5), so the gate judges each registration in both directions, and its
|
|
284
|
+
unjudged-block ledger books none of them. This change itself still moved none
|
|
285
|
+
of those rows.
|
|
286
|
+
- 91facae: **Breaking behaviour change — a view block now honours only the `data` spelling its published row declares.**
|
|
287
|
+
|
|
288
|
+
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.
|
|
289
|
+
|
|
290
|
+
⚠️ **`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).
|
|
291
|
+
|
|
292
|
+
**Per block — what the published row says, and what actually moves:**
|
|
293
|
+
|
|
294
|
+
- **`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`.
|
|
295
|
+
- **`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.
|
|
296
|
+
- **`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.
|
|
297
|
+
- **`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.
|
|
298
|
+
- **`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.
|
|
299
|
+
|
|
300
|
+
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.
|
|
301
|
+
- a984600: Honour `filter`, `sort` and the platform row ceiling on a calendar's and a map's
|
|
302
|
+
inline (`provider: 'value'`) data (objectui#9061) — the port of objectui#8769's
|
|
303
|
+
repair off `ObjectGantt`.
|
|
304
|
+
|
|
305
|
+
**The defect was fail-open.** Both renderers' fetch effect short-circuited the
|
|
306
|
+
inline provider: it set the authored rows and returned BEFORE the adapter query,
|
|
307
|
+
which is the one site in each file that lowers `schema.filter` to `$filter`,
|
|
308
|
+
`schema.sort` to `$orderby` and the objectui#7210 ceiling to `$top`. So an
|
|
309
|
+
inline calendar or map that declared a `filter` drew **every** authored row, with
|
|
310
|
+
no diagnostic. The key that was dropped is the key that NARROWS, which is why
|
|
311
|
+
this matters: the view answered a wider question than the author asked. Nothing
|
|
312
|
+
was exposed that was not already in the authored schema — this is a correctness
|
|
313
|
+
defect, not a data-access one.
|
|
314
|
+
|
|
315
|
+
**What changed.** Each renderer resolves a `ValueDataSource` for the inline
|
|
316
|
+
provider and issues the same query the `object` arm issues. The `api` arm is
|
|
317
|
+
untouched, and no dependency array moves. `ValueDataSource` already implements
|
|
318
|
+
`$filter` / `$orderby` / `$skip` / `$top` / `$select` over its own array, so no
|
|
319
|
+
filter combinator was written for this change.
|
|
320
|
+
|
|
321
|
+
**Behaviour you may notice.**
|
|
322
|
+
|
|
323
|
+
- An authored `filter` / `sort` now narrows and orders inline rows. Every
|
|
324
|
+
spelling reaches it: `data: { provider: 'value', items }` and `staticData` on
|
|
325
|
+
both renderers, plus the map's bare-array `data` shorthand.
|
|
326
|
+
- The row ceiling now applies to inline rows: past 2,000 drawn rows the view
|
|
327
|
+
draws 2,000 and shows the footnote naming both numbers, as it already did for
|
|
328
|
+
fetched rows. It is applied to the **filtered** set, so a large inline array
|
|
329
|
+
that a `filter` cuts below the ceiling draws every matching row and stays
|
|
330
|
+
quiet. Rows a host passes down through the `data` React prop are still never
|
|
331
|
+
capped — those are not ours to cap.
|
|
332
|
+
- Inline rows now reach the view as the adapter's own deep copy rather than as
|
|
333
|
+
the authored array's object identities. Code comparing a row handed to
|
|
334
|
+
`onEventClick` / `onMarkerClick` against the authored array with `===` needs
|
|
335
|
+
`id` equality instead.
|
|
336
|
+
- That copy is a JSON round-trip, so inline rows must be JSON-serializable.
|
|
337
|
+
A record graph carrying a back-reference, or a `BigInt` id, now renders an
|
|
338
|
+
error panel instead of the view. `ObjectGantt` has refused the same input
|
|
339
|
+
since before objectui#8769; `ObjectMap` did not, and pinned that it need not
|
|
340
|
+
(objectui#6018). ⚠️ That pin is left RED and untouched in this change — see
|
|
341
|
+
the pull request body.
|
|
342
|
+
- 502eb58: The row/card click props on the view components now declare the modifier
|
|
343
|
+
payload they have always been invoked with (objectui#9357).
|
|
344
|
+
|
|
345
|
+
`useNavigationOverlay`'s `handleClick` invokes the handler it is given with two
|
|
346
|
+
arguments — the record, and an optional modifier payload (`metaKey` / `ctrlKey`
|
|
347
|
+
/ `button`) a host needs to implement Cmd/Ctrl/middle-click. objectui#9360 made
|
|
348
|
+
the hook's own option say so. These components pass a host-supplied prop
|
|
349
|
+
straight into that option, so the value a host writes against them is invoked
|
|
350
|
+
with two arguments too — and every one of these props declared only the record.
|
|
351
|
+
The payload was therefore invisible on the one line a host reads, exactly as it
|
|
352
|
+
had been on the hook.
|
|
353
|
+
|
|
354
|
+
Thirteen declarations across nine packages now name both parameters:
|
|
355
|
+
|
|
356
|
+
- `ObjectGridComponentProps.onRowClick`
|
|
357
|
+
- `ObjectKanbanComponentProps.onRowClick` (its sibling `onCardClick`, the other
|
|
358
|
+
arm of the same fallback, already declared both)
|
|
359
|
+
- `KanbanRendererProps.schema.onCardClick`
|
|
360
|
+
- `ObjectCalendar`, `ObjectGantt`, `ObjectMap`, `ObjectTree`: `onRowClick`
|
|
361
|
+
- `ObjectTimeline`: `onRowClick` and `onItemClick`, the two arms of one fallback
|
|
362
|
+
- `ListView.onRowClick`
|
|
363
|
+
- `ObjectGallery`: `onRowClick` and `onCardClick`, likewise two arms of one
|
|
364
|
+
- `RelatedList.onRowClick`
|
|
365
|
+
|
|
366
|
+
**Source-compatible, and with no refused class.** A one-parameter handler is
|
|
367
|
+
still assignable to the widened signature, and a handler written against the
|
|
368
|
+
widened signature was already assignable to the narrow one — its minimum
|
|
369
|
+
argument count is still one. The second parameter is spelled `any` rather than
|
|
370
|
+
`HandleClickModifiers`, which is the difference that matters for callers: the
|
|
371
|
+
hook's own option names that interface and therefore refuses a handler whose
|
|
372
|
+
second parameter is annotated narrower (objectui#9360 documents that class and
|
|
373
|
+
the one-line remedy). These faces refuse nothing. A host that discovered the
|
|
374
|
+
payload from the implementation and annotated it `React.MouseEvent` — which is
|
|
375
|
+
what actually arrives — keeps compiling. `any` is also the spelling
|
|
376
|
+
`ObjectKanbanSchema.onCardClick` already carries for this same payload
|
|
377
|
+
(objectui#9341) and the one `BaseSchema`'s own `onClick` / `onChange` /
|
|
378
|
+
`onSubmit` use, and it is forced on the published twins in `@object-ui/types`,
|
|
379
|
+
which may not name a type that lives in a package depending on them.
|
|
380
|
+
|
|
381
|
+
**Runtime behaviour is unchanged.** Nothing is newly called and nothing newly
|
|
382
|
+
passes an argument; only the declarations move.
|
|
383
|
+
|
|
384
|
+
Three declarations that share the name and the shape are deliberately NOT
|
|
385
|
+
widened, because the value flowing through them is not invoked with the
|
|
386
|
+
payload: `VirtualGrid.onRowClick`, whose second parameter is a row index;
|
|
387
|
+
`ManageViewsDialog.onRowClick`, which receives a view id; and the `data-table`
|
|
388
|
+
family (`DataTableSchema.onRowClick`, `ObjectDataTableSchema.onRowClick`),
|
|
389
|
+
whose renderer invokes with one argument. Widening those would have declared a
|
|
390
|
+
payload that never arrives.
|
|
391
|
+
|
|
392
|
+
### Patch Changes
|
|
393
|
+
|
|
394
|
+
- 2252653: fix(plugin-map): the top-level-`style` warning now prescribes a spelling the runtime reads
|
|
395
|
+
|
|
396
|
+
`warnOnTopLevelStyleUrl` fires when a map node carries a string `style` — the base
|
|
397
|
+
schema's inline-CSS key, which is never read as a map style — and tells the author
|
|
398
|
+
where to write it instead. Its last sentence ended "spell it `map: { mapStyle }`
|
|
399
|
+
there". `ObjectMapConfigSchema` does not declare `mapStyle`, so neither view
|
|
400
|
+
flattener's whitelist carries it and `getMapConfig` never reads it: an author who
|
|
401
|
+
obeyed the correction wrote metadata that was discarded a second time, with no
|
|
402
|
+
second diagnostic. That text is read at the moment the author is ALREADY being
|
|
403
|
+
corrected, which is why prescribing refused metadata there was ruled out for a
|
|
404
|
+
sibling sink (objectui#9031).
|
|
405
|
+
|
|
406
|
+
The remedy now names the declared block — `map: { style: 'URL' }` — on the node
|
|
407
|
+
path and on the view path alike. That is also what moved underneath it: since
|
|
408
|
+
objectui#9950 both flatteners carry a declared `style` out of `options.map` under
|
|
409
|
+
its flat spelling `mapStyle`, so a view's declared block arrives and is read, and
|
|
410
|
+
neither producer of an `object-map` node emits a top-level `style` any more. The
|
|
411
|
+
sentence had gone on describing the pre-#9950 transport.
|
|
412
|
+
|
|
413
|
+
⛔ The remedy is no longer defended by a string assertion — that is how it rotted
|
|
414
|
+
in the first place, green the whole time because nothing executed it. Every key it
|
|
415
|
+
prescribes inside a `map` block is now parsed out of the warning the component
|
|
416
|
+
really emits and written into a real `map` block, measured end to end through the
|
|
417
|
+
declared block and through the real `ListView` flatten, so the sentence and the
|
|
418
|
+
runtime cannot drift apart without a test going red.
|
|
419
|
+
- 875ee61: fix(plugin-calendar, plugin-map, plugin-gantt): the registrations' `inputs` agree with the record-source rule
|
|
420
|
+
|
|
421
|
+
All three blocks read their records from one of `data`, `staticData` and
|
|
422
|
+
`objectName` (in that order), and their `@object-ui/types` zod schemas enforce
|
|
423
|
+
"one of the three" through `requireRecordSource`. The designer-facing `inputs`
|
|
424
|
+
on the registrations disagreed with that rule in two ways:
|
|
425
|
+
|
|
426
|
+
- `object-calendar` and `calendar` still declared `objectName` as required, so
|
|
427
|
+
the html tier's validator reported a `missing-required-prop` error on a
|
|
428
|
+
calendar authored on `staticData` or `data`, which the schema accepts and the
|
|
429
|
+
renderer draws. `objectName` is now declared without `required`, and its
|
|
430
|
+
description states the rule, as objectui#7470 did for map and gantt
|
|
431
|
+
(objectui#10392).
|
|
432
|
+
- `object-map`, `map` and `object-gantt` did not declare `data` or
|
|
433
|
+
`staticData`, so the validator reported a block authored on either as an
|
|
434
|
+
unknown prop. At this change both were declared on all three, on the schema's
|
|
435
|
+
own arms: `data` is a `{ provider, … }` data-source configuration (an object,
|
|
436
|
+
so a bare array there draws a type diagnostic, matching the schema), and
|
|
437
|
+
`staticData` is an array of records. Each description says what the renderer
|
|
438
|
+
does with the key, including that the map does not implement the `api`
|
|
439
|
+
provider (objectui#10394).
|
|
440
|
+
|
|
441
|
+
⚠️ **Dated note, 2026-09-25 — the bare `map` registration has since been
|
|
442
|
+
retired — objectui#10393.** Later in this same release `@object-ui/plugin-map`
|
|
443
|
+
stopped registering the bare `map` key (and its namespaced twin `view:map`),
|
|
444
|
+
so `map` declares nothing: a node authored `"type": "map"` resolves no
|
|
445
|
+
renderer, and the html tier reports it as `unknown-component`. The
|
|
446
|
+
`object-map` and `object-gantt` registrations keep both inputs exactly as
|
|
447
|
+
described above. The rest of this entry is kept as the reading of this
|
|
448
|
+
change; the objectui#10393 entry states what ships.
|
|
449
|
+
|
|
450
|
+
The renderers' read order and the zod schemas are unchanged. The
|
|
451
|
+
`@object-ui/plugin-gantt` README sentence that listed the registration's inputs
|
|
452
|
+
is updated.
|
|
453
|
+
|
|
454
|
+
**Correction, 2026-10-01 (objectui#11117).** "One of the three" now has an exception on all
|
|
455
|
+
three blocks: a block that declares none of them is accepted when its `dataSource.object` names
|
|
456
|
+
the object, because the registration's `ElementDataSourceGate` lands that name on `objectName`.
|
|
457
|
+
The `objectName` input description now says so.
|
|
458
|
+
- c5d715f: A map marker's description no longer crashes the popup when `descriptionField` names a lookup.
|
|
459
|
+
|
|
460
|
+
`ObjectMap` copied the raw `descriptionField` value onto each marker. The popup and
|
|
461
|
+
the mobile record sheet put that value in JSX, and the search box called
|
|
462
|
+
`.toLowerCase()` on it. A lookup is a field like any other, and `ObjectMap`'s own
|
|
463
|
+
object fetch expands every declared relation, so a lookup-typed description arrived
|
|
464
|
+
as `{ id, name }`. React then threw `Objects are not valid as a React child` on the
|
|
465
|
+
first marker click. A number or a boolean description made the search box throw as
|
|
466
|
+
soon as anyone typed.
|
|
467
|
+
|
|
468
|
+
The marker transform now derives the description once, as a display string, through
|
|
469
|
+
`@object-ui/core`'s `recordDisplayValueAt`. That is the resolver the marker title
|
|
470
|
+
already uses for an authored `titleField`. The popup, the mobile record sheet and
|
|
471
|
+
the search all read that one string:
|
|
472
|
+
|
|
473
|
+
- an expanded lookup shows its display name;
|
|
474
|
+
- a bare id shows as itself, as before;
|
|
475
|
+
- a number or a boolean shows as its string, so `false` now appears where the old
|
|
476
|
+
truthiness gate dropped it;
|
|
477
|
+
- an empty or whitespace-only value, or an expanded record with no display name,
|
|
478
|
+
shows no description line.
|
|
479
|
+
|
|
480
|
+
No schema or spec key changes. `ObjectMap.descriptionDisplay-10456.test.tsx` pins
|
|
481
|
+
each case above.
|
|
482
|
+
- 02e6d36: Five more page blocks re-read when the data-invalidation bus (`notifyDataChanged` from `@object-ui/react`) reports a write to the object they read (objectui#10623). These blocks read neither `onMutation` nor the bus, so any write — through the data source or past it (a page action over raw HTTP, a flow, a server action) — showed only when something remounted them. Each fetch effect now names the `useDataInvalidation` nonce for its object; an unscoped change (`'*'`) matches too, and a change to another object does not.
|
|
483
|
+
|
|
484
|
+
- `@object-ui/plugin-timeline`: `object-timeline` re-reads its rows; a canvas that already shows rows stays mounted while the re-read runs.
|
|
485
|
+
- `@object-ui/plugin-list`: `object-gallery` re-reads its cards; collapsed groups stay collapsed.
|
|
486
|
+
- `@object-ui/plugin-map`: `object-map` re-reads the markers it is showing without its loading placeholder, so the map stays mounted and the camera stays where the user left it. If that re-read fails, the last markers stay on the map and the failure is logged to the console, as `ObjectGantt`'s background refresh does. A changed query still shows the placeholder and re-fits the camera, even when a bus event arrives with it. Two older faults in the same fetch are fixed as well: a slow earlier answer can no longer overwrite a newer one, and a load that succeeds now takes the map off an earlier error screen.
|
|
487
|
+
- `@object-ui/components`: `element:number` re-reads its aggregate and `element:repeater` its rows.
|
|
488
|
+
|
|
489
|
+
Rows a host hands these blocks (`data`, `bind`, authored `items`, an inline `value` set) are still the host's to refresh; only the blocks' own queries follow the bus.
|
|
490
|
+
- 7afc81d: An `object-map` block reads its records once per mount, and that read already carries the lookup expansion (objectui#10664).
|
|
491
|
+
|
|
492
|
+
The map loaded the object definition in an effect of its own and listed it among the fetch effect's dependencies. The definition lands after the first query, so every mount issued two `find` calls, the first without `$expand`. Switching the bound object also sent the new object's query with the previous object's expansion. The map now reads the definition through `useSettledSchema` from `@object-ui/react`, and its object query waits until that read settles, the way `object-timeline` (objectui#7895) and `object-gallery` (objectui#7903) already do. A definition read that fails, or an adapter with no `getObjectSchema`, settles with no definition, so the map still loads, unexpanded. Host rows (`data`) and an inline `value` set are not held.
|
|
493
|
+
- 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:
|
|
494
|
+
|
|
495
|
+
- `object-calendar`, `object-map` and `object-tree`, on both the object query and the inline (`provider: 'value'`) query;
|
|
496
|
+
- `object-gantt`, `object-kanban` and `object-timeline`;
|
|
497
|
+
- `record:related_list` and `record:line_items`, where the node's own filter is combined with the parent-record condition;
|
|
498
|
+
- the `element:repeater`, `element:number` (both the `aggregate` filter and the `find` fallback) and `element:record_picker` page elements.
|
|
499
|
+
|
|
500
|
+
`list-view`, `object-grid` and `object-gallery` already did this, and are unchanged.
|
|
501
|
+
|
|
502
|
+
**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.
|
|
503
|
+
|
|
504
|
+
What changes for an app:
|
|
505
|
+
|
|
506
|
+
- A filter with no placeholders reaches the query as before, unchanged.
|
|
507
|
+
- 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.
|
|
508
|
+
- 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.
|
|
509
|
+
|
|
510
|
+
`@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.
|
|
511
|
+
- 997ce38: docs(plugin-map): authored `object-map` examples write their props in the `properties` bag, and the `objectName` input names the `dataSource` binding (objectui#10859, batch 5)
|
|
512
|
+
|
|
513
|
+
- The README's authored `object-map` examples now write `{ "type": "object-map", "properties": { … } }`, the spelling `@objectstack/spec`'s `ComponentPropsMap['object-map']` row declares and `objectui validate` now requires. The example that mounts `ObjectMap` directly keeps the flat `schema` prop: a component mounted without `SchemaRenderer` receives the node as it reads it, and nothing hoists a bag there.
|
|
514
|
+
- The registration's `objectName` input description names the node's `dataSource` binding beside `data`, `staticData` and `objectName` as a record source, because the authored arm now counts it. No runtime change.
|
|
515
|
+
- 20d23be: `object-map` reads `mapStyle` before `map.style`, as `@objectstack/spec`'s `object-map` row says in `mapStyle`'s own description ("Read before `map.style`"). This is objectui#11168 slice 3, under the seat's ruling: the renderer follows the spec.
|
|
516
|
+
|
|
517
|
+
**Behaviour change.** A map that writes both a node-level `mapStyle` and a `style` inside its `map` block now draws `mapStyle`. Until now, the block's `style` won on that path. A map writing only one of the two, or neither, draws exactly what it drew before. The map path with no `map` block already read `mapStyle` first.
|
|
518
|
+
|
|
519
|
+
No authored producer in objectui or objectstack writes both. The only producers of `mapStyle` are the `ListView` / `ObjectView` flatteners, and they write it on the path with no `map` block. So no stored document changes what it draws. The `object-map` registration publishes the spec's description for `mapStyle` verbatim.
|
|
520
|
+
- 3c3ce15: Small reader sites stop riding `BaseSchema`'s index signature (objectui#11355, part of the preparation for objectui#8347's removal of that signature). Each key was measured on its own.
|
|
521
|
+
|
|
522
|
+
**Two keys are now declared, each with a spec row's type, by reference.**
|
|
523
|
+
|
|
524
|
+
- `ObjectKanbanSchema.swimlaneField`. The installed `@objectstack/spec` declares it on the `object-kanban` row as an optional string, `ObjectKanban` reads it, and the registration publishes it as an input. The TypeScript member takes the row's type, and the zod mirror now refuses a non-string `swimlaneField` where `.passthrough()` used to keep it unjudged. `grouping`, the read's fallback, is still undeclared; aligning it with the spec's typed row is objectui#11216.
|
|
525
|
+
- `DetailViewSchema.showHeader`. `detail-view` has no spec row. `DetailView` reads the key, and its producer is `record:details`, which writes its own spec-declared `showHeader` onto the `detail-view` node it builds. So the member takes the `record:details` row's type, and the two cannot drift apart. The zod mirror declares it too. The defaults are unchanged: a bare `detail-view` draws its heading unless `showHeader` is `false`, and `record:details` keeps its own default of off.
|
|
526
|
+
|
|
527
|
+
**Two reads are typed where they stand, with no behaviour change.**
|
|
528
|
+
|
|
529
|
+
- `@object-ui/cli`: `objectui validate` reads a parsed node's `title` only where the node carries one. The read used to span every arm of the parsed union. The printed output is unchanged.
|
|
530
|
+
- `@object-ui/plugin-map`: the dev warning about flat map keys that a `map` block shadows reads those keys through their own type, not through a `Record` conversion.
|
|
531
|
+
|
|
532
|
+
**minor, not patch, for `@object-ui/types`.** Both members are new in the shipped `.d.ts` and in the zod mirror's `.shape`, and the mirror now refuses a wrongly typed value for each, where it used to keep one unjudged.
|
|
533
|
+
|
|
534
|
+
⚠️ **Dated note, 2026-10-03 — `ObjectKanbanSchema.grouping` is now declared — objectui#11216.**
|
|
535
|
+
At this change `grouping`, the fallback `ObjectKanban` reads for `swimlaneField`,
|
|
536
|
+
was undeclared on both faces, as the first bullet above says. objectui#11216
|
|
537
|
+
declares it on both faces in this release, by reference: the TypeScript member is
|
|
538
|
+
the spec's `GroupingConfig`, and the zod mirror takes the spec's
|
|
539
|
+
`GroupingConfigSchema`, the type the `object-kanban` row gives the key. So the
|
|
540
|
+
sentence above that calls `grouping` "still undeclared" does not hold in this
|
|
541
|
+
release. The rest of this entry is kept as the reading of this change.
|
|
542
|
+
- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
|
|
543
|
+
every relative specifier, and a type error in the declaration build now fails the build
|
|
544
|
+
instead of being printed and ignored (objectui#5439, objectui#5483).
|
|
545
|
+
|
|
546
|
+
**Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
|
|
547
|
+
is the fix working.** These packages re-export mostly through NAMED re-exports —
|
|
548
|
+
`export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
|
|
549
|
+
extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
|
|
550
|
+
`any`. Nothing errored; consumers simply got no types. With the extension emitted, the
|
|
551
|
+
symbol carries its real type, and any call site that was relying on the `any` now type
|
|
552
|
+
checks for the first time. This is the mode that produced the 21 residual `TS7006` on
|
|
553
|
+
`@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
|
|
554
|
+
unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
|
|
555
|
+
immediately as `TS2305: has no exported member`.
|
|
556
|
+
|
|
557
|
+
410 extensionless relative specifiers across 19 packages were emitted before this change;
|
|
558
|
+
the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
|
|
559
|
+
`@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
|
|
560
|
+
is wired so it stays that way.
|
|
561
|
+
|
|
562
|
+
The second half changes no emitted output today: 22/22 packages built green unmodified, so
|
|
563
|
+
making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
|
|
564
|
+
regression does — print and exit 0, versus fail the build.
|
|
565
|
+
- 0a2918f: The package README stops documenting a marker-title fallback that objectui#5953 replaced.
|
|
566
|
+
|
|
567
|
+
`README.md`'s `map` block table described `titleField` as: "Omitted, markers are
|
|
568
|
+
titled `Marker`." That was true of the pre-#5953 read site, which bound the
|
|
569
|
+
marker title to a field name directly. objectui#5953 moved the marker title onto
|
|
570
|
+
`@object-ui/core`'s `getRecordDisplayName`, and `'Marker'` is now passed only as
|
|
571
|
+
that resolver's `fallback` option — a position the resolver reaches **only for a
|
|
572
|
+
record carrying no id at all**. A record with an id and no resolvable name reads
|
|
573
|
+
`Record #<id>`; a record whose object declares a `nameField` or a `titleFormat`,
|
|
574
|
+
or which simply carries a name-ish key, reads that. So "omitted ⇒ `Marker`" was
|
|
575
|
+
true in one narrow corner and false in the common case, and an author reading the
|
|
576
|
+
row would either under-specify `titleField` for a reason that stopped being true
|
|
577
|
+
or over-specify it to avoid a `Marker` that would never have appeared.
|
|
578
|
+
|
|
579
|
+
The row now names the precedence an omitted `titleField` hands the decision to:
|
|
580
|
+
the declared `nameField`, its deprecated `displayNameField` alias, the legacy
|
|
581
|
+
`titleFormat` template, a type-aware pick from the object's fields, then
|
|
582
|
+
name-ish keys read straight off the record — with `Record #<id>` as the floor and
|
|
583
|
+
`Marker` reached only by an id-less record.
|
|
584
|
+
|
|
585
|
+
Two details the row states deliberately:
|
|
586
|
+
|
|
587
|
+
- It does **not** describe an object-level `objectDef.titleField` rung. The
|
|
588
|
+
resolver consulted one at step 0 as a second `??` leg, but objectui#6531 (PR
|
|
589
|
+
#6560) removes it — `@objectstack/spec`'s object schema is a `strictObject`
|
|
590
|
+
that rejects the key with `unrecognized_keys`, so no producer can ship it.
|
|
591
|
+
What survives is `options.titleField`, which is exactly what `map.titleField`
|
|
592
|
+
becomes at `ObjectMap`'s call site, so "a declared `titleField` wins" stays
|
|
593
|
+
true either way and the row does not go stale when that lands.
|
|
594
|
+
- It names the record-key probe (the resolver's step 4b) as its own rung. That
|
|
595
|
+
is not a footnote for this component: `ObjectMap` fetches an object schema
|
|
596
|
+
only when `!hasInlineData && dataSource`, so for `staticData` or an inline
|
|
597
|
+
`data` array no object definition ever reaches the resolver and the record-key
|
|
598
|
+
probe is the only rung that can produce a title —
|
|
599
|
+
`ObjectMap.markerTitle.test.tsx` pins exactly that case.
|
|
600
|
+
|
|
601
|
+
A second row falsified by the same commit goes with it. Two lines below the table,
|
|
602
|
+
the field-name defaults paragraph listed what an unconfigured map falls back to as
|
|
603
|
+
"`latitude` / `longitude` / `location` / `name` / `description`". objectui#5953 removed
|
|
604
|
+
the title default: `getMapConfig`'s default branch returns coordinate keys and
|
|
605
|
+
`descriptionField` only, under a comment that spells out why — "Deliberately NO
|
|
606
|
+
`titleField` (objectui#5953)… `getRecordDisplayName` resolves it from the object
|
|
607
|
+
definition, and it does so better than any literal here could". The paragraph now
|
|
608
|
+
lists the four defaults that exist and says where an unconfigured marker's title
|
|
609
|
+
actually comes from. Left alone in the same sentence: `map: { titleField: 'name' }`
|
|
610
|
+
still names no coordinate field and still renders an empty map, which is accurate.
|
|
611
|
+
|
|
612
|
+
Prose only: no behaviour changes, and the placeholders were already pinned in
|
|
613
|
+
order by `ObjectMap.markerTitle.test.tsx`.
|
|
614
|
+
- f9653ae: Re-key the load-bearing fetch effects in `ObjectMap`, `ObjectCalendar` and
|
|
615
|
+
`ObjectGantt` onto the primitive fields they actually read off `dataConfig`
|
|
616
|
+
(`provider` / `object` / `items`) instead of the whole memoised `dataConfig`
|
|
617
|
+
object (objectui#6592, the deferred half of objectui#6270/PR #6591).
|
|
618
|
+
`ObjectTree` is a census member too but is deferred out of this change — see
|
|
619
|
+
the PR body — because its own fetch effects are the surface of PR #6696
|
|
620
|
+
(objectui#6481), open at the same time.
|
|
621
|
+
|
|
622
|
+
`useMemo` carries no semantic guarantee — React is permitted to discard a
|
|
623
|
+
memo cache and recompute even when its dependency array compares equal to
|
|
624
|
+
the previous render, and the local `getDataConfig(schema)` helper each of
|
|
625
|
+
these renderers carries builds a fresh `{ provider, object }` /
|
|
626
|
+
`{ provider, items }` wrapper object on every call. So a fetch effect keyed
|
|
627
|
+
on `dataConfig` itself was correct only for as long as that identity
|
|
628
|
+
happened to survive a discard: a recompute alone (no author or caller
|
|
629
|
+
action) was enough to re-run the effect and issue an extra
|
|
630
|
+
`dataSource.find` / `dataSource.getObjectSchema` call. Keying the effects
|
|
631
|
+
on the primitives instead makes a cache discard a no-op, restoring
|
|
632
|
+
`useMemo` to a pure optimisation.
|
|
633
|
+
|
|
634
|
+
`ObjectGantt`'s `effectiveDataSource` memo deliberately keeps `dataConfig`
|
|
635
|
+
as a dependency (`resolveDataSource` needs the whole provider-shaped
|
|
636
|
+
value — the `api` provider's `read`/`write` request config cannot be
|
|
637
|
+
flattened to a fixed primitive list the way `object`/`value` can), so its
|
|
638
|
+
`reload()` fetch is decoupled from the redundant direct `dataConfig`
|
|
639
|
+
dependency but not from `effectiveDataSource`'s own; for the `object`/`value`
|
|
640
|
+
providers `resolveDataSource` returns its `fallback`/a fresh
|
|
641
|
+
`ValueDataSource` respectively rather than reading further into the config,
|
|
642
|
+
which is enough for the two fetch effects to observe no extra call under a
|
|
643
|
+
recomputed-but-equivalent `dataConfig` in the common case.
|
|
644
|
+
|
|
645
|
+
No behaviour change for a schema whose `useMemo` caches survive normally;
|
|
646
|
+
the effects are unaffected by React discarding one.
|
|
647
|
+
- 3beef6d: The spec's `dataSource` element binding is now DECLARED by the blocks that read
|
|
648
|
+
it, so the html tier stops reporting the one working saved-view spelling as
|
|
649
|
+
`unknown-prop` (objectui#6678).
|
|
650
|
+
|
|
651
|
+
`PageComponentSchema.dataSource` — `{ object, view, filter, sort, limit }` — is
|
|
652
|
+
the one spelling that resolves a saved view for an object-bound block. It works,
|
|
653
|
+
and it drew the identical `unknown-prop` warning as the two spellings that do
|
|
654
|
+
nothing (`viewName`, `view`), because `validateTree` looks a prop up in the
|
|
655
|
+
block's declared `inputs` and no registration declared this key. On the tier
|
|
656
|
+
built to accept AI-authored pages, where the diagnostic IS the contract, the
|
|
657
|
+
only signal pointed away from the key that works.
|
|
658
|
+
|
|
659
|
+
Adopting the maintainer ruling of 2026-08-29 — option B **in the injection
|
|
660
|
+
form**:
|
|
661
|
+
|
|
662
|
+
- `ELEMENT_DATA_SOURCE_INPUT` is the single declaration, in `@object-ui/core`
|
|
663
|
+
beside the binding's own semantics; `Registry.register` emits it for any
|
|
664
|
+
registration whose renderer passed through the new `elementDataSourceBlock()`
|
|
665
|
+
seam. One mechanism, one copy — not a hand-kept declaration per block, which is
|
|
666
|
+
the shape that drifts and that a new block forgets. The seam lives in
|
|
667
|
+
`@object-ui/core` and is re-exported by `@object-ui/react` beside
|
|
668
|
+
`ElementDataSourceGate` for discoverability; call sites take the core import,
|
|
669
|
+
because a registration runs at module scope and this repo's suites partially
|
|
670
|
+
mock `@object-ui/react`.
|
|
671
|
+
- Seventeen renderers, in thirteen files across twelve packages, reach the seam
|
|
672
|
+
and now publish the key to the save gate, the parser whitelist, the generated
|
|
673
|
+
JSX authoring types and the block list. The card named nine blocks; the tree
|
|
674
|
+
also has `plugin-grid`, `plugin-timeline`, two further `plugin-form` blocks and
|
|
675
|
+
`element:record_picker` — nothing was hand-listed, so the mechanism covered
|
|
676
|
+
them. `element:record_picker` consumes the gate's HOOK and status panels rather
|
|
677
|
+
than the wrapper tag (its object lives under `properties`), and was found by a
|
|
678
|
+
render probe rather than by reading sources.
|
|
679
|
+
- `dataSource` on a block that does NOT read it (`flex`, `card`) still reports
|
|
680
|
+
`unknown-prop`. Adding the key to `sdui-parser`'s `BASE_PROPS` was refused for
|
|
681
|
+
exactly this reason — that set mirrors `BaseSchema`, and silencing the key
|
|
682
|
+
everywhere would make the diagnostic lie in the other direction.
|
|
683
|
+
- New `check:element-data-source-declaration` fails any source that consumes the
|
|
684
|
+
gate without reaching the seam, so a block added tomorrow cannot forget.
|
|
685
|
+
|
|
686
|
+
Behaviour of the binding itself is unchanged — this is a declaration, not a
|
|
687
|
+
resolution change. The saved view still resolves its columns, and an
|
|
688
|
+
unresolvable `view` still fails loudly rather than widening to the object's full
|
|
689
|
+
scope.
|
|
690
|
+
|
|
691
|
+
The spec/registry parity gates (repo-wide and the `record:related_list` per-block
|
|
692
|
+
pin) now derive their accepted set from the WHOLE node contract rather than from
|
|
693
|
+
`ComponentPropsMap[type]` alone. `PageComponentSchema` accepts and keeps
|
|
694
|
+
`dataSource` on a page-component node — it is a node-level key, a sibling of
|
|
695
|
+
`type` and `className`, not a per-block prop — so the gates' previous complaint
|
|
696
|
+
was measurably wrong. Derived from the spec, not exempted, and both still
|
|
697
|
+
discriminate against an invented key.
|
|
698
|
+
- d327b9c: FLS-gate the `$expand` projection at the seven remaining `buildExpandFields`
|
|
699
|
+
call sites (objectui#7429).
|
|
700
|
+
|
|
701
|
+
objectui#7215 / PR #7229 gated the two projection sites in its scope
|
|
702
|
+
(`ObjectGrid`, `ListView`). objectui#7230 / PR #7428 gated four more
|
|
703
|
+
(`ObjectCalendar`, `ObjectGantt`, `RecordDetailView`, `DetailView`). This
|
|
704
|
+
closes the seven that were left: `ObjectKanban`, `ObjectTree`, `ObjectView`
|
|
705
|
+
(the non-grid record-fetch effect), `ObjectMap`, `ObjectGallery`,
|
|
706
|
+
`ObjectTimeline`, and the metadata-admin `PagePreview`'s record-binding fetch.
|
|
707
|
+
|
|
708
|
+
**All seven pass no column list at all**, which makes every one of them the
|
|
709
|
+
sharp shape: `buildExpandFields` reads an absent column list as "no column
|
|
710
|
+
restriction" and falls back to **every declared relation on the object**,
|
|
711
|
+
denied ones included. So each of these components asked the server to resolve
|
|
712
|
+
the object's full relation set by default, not by configuration — the
|
|
713
|
+
ordinary shape of each surface, not a corner of it.
|
|
714
|
+
|
|
715
|
+
**`PagePreview` is the one site where the judged principal is not the page's
|
|
716
|
+
eventual audience.** It calls the browser's own `fetch` with
|
|
717
|
+
`credentials: 'include'` rather than `DataSource.find`, so it runs under
|
|
718
|
+
whichever session is loading the Studio preview. Gating on that same session's
|
|
719
|
+
`usePermissions()` is still the correct principal: it is exactly the request
|
|
720
|
+
the browser is about to make, on its own credentials, regardless of who later
|
|
721
|
+
opens the published page.
|
|
722
|
+
|
|
723
|
+
**Reproduced before it was fixed**, as a failing test per site (and, for the
|
|
724
|
+
two sites — `ObjectView`, `PagePreview` — where the gate was implemented
|
|
725
|
+
before its test was run red, a reverse-verification: the gate was reverted,
|
|
726
|
+
all four denial-and-set pins on each went red, and the two deferral/positive
|
|
727
|
+
control pins stayed green, before the gate was restored).
|
|
728
|
+
|
|
729
|
+
**Grading, measured rather than assumed** — the same reading objectui#6898,
|
|
730
|
+
#7215 and #7230 recorded: against ObjectStack's own server this is
|
|
731
|
+
defence-in-depth, not a live disclosure. `plugin-security`'s
|
|
732
|
+
`FieldMasker.maskRecord` deletes every unreadable key from each returned row
|
|
733
|
+
and objectql's expand path writes the resolved record back under that same
|
|
734
|
+
key, so one statement removes the expanded object and the bare id alike; the
|
|
735
|
+
expansion sub-read is itself gated (the referenced object's full CRUD + RLS +
|
|
736
|
+
FLS treatment, objectstack#7626). It is load-bearing for any backend that does
|
|
737
|
+
not strip, and the client-request side is real regardless.
|
|
738
|
+
|
|
739
|
+
**Nothing a permitted view did stops working.** The gate judges each site's
|
|
740
|
+
`buildExpandFields` OUTPUT, which contains only the object's declared
|
|
741
|
+
reference-bearing fields, so the "`checkField` answers false for an
|
|
742
|
+
undeclared key" trap cannot be reached. An unanswered permission policy
|
|
743
|
+
filters nothing. `buildExpandFields` itself is unchanged.
|
|
744
|
+
|
|
745
|
+
`@object-ui/permissions` is added to `dependencies` for `plugin-kanban`,
|
|
746
|
+
`plugin-tree`, `plugin-map`, `plugin-timeline`, and `plugin-view` — the fifth
|
|
747
|
+
one objectui#7429's own dependency count missed (it named four); `plugin-list`
|
|
748
|
+
and `app-shell` already had it.
|
|
749
|
+
- 3ef0b51: fix(plugin-map, plugin-gantt): the registrations no longer declare `objectName` a required input
|
|
750
|
+
|
|
751
|
+
Both renderers read their records from one of three keys (`data`, then
|
|
752
|
+
`staticData`, then `objectName`), and the `object-map` / `object-gantt` zod schemas
|
|
753
|
+
enforce "one of the three" through `requireRecordSource` (`77cb489b4`). The
|
|
754
|
+
registrations' designer-facing `inputs` still said `objectName` was required, on
|
|
755
|
+
`object-map`, `map` and `object-gantt`, so the html tier's validator reported a
|
|
756
|
+
`missing-required-prop` error on a block authored on `staticData` or `data` that
|
|
757
|
+
the schema accepts and the renderer draws.
|
|
758
|
+
|
|
759
|
+
`objectName` is now declared without `required`, and its description states the
|
|
760
|
+
rule: the record source is one of `data`, `staticData` and `objectName`, and the
|
|
761
|
+
schema refuses a block that declares none of them. No one-of form was added to the
|
|
762
|
+
input declaration; the zod refinement stays the place that enforces it. The
|
|
763
|
+
renderers' read order is unchanged. The `@object-ui/plugin-gantt` README sentence
|
|
764
|
+
that called `objectName` required is corrected (objectui#7470).
|
|
765
|
+
|
|
766
|
+
**Correction, 2026-10-01 (objectui#11117).** The rule this entry describes gained an exception:
|
|
767
|
+
the `object-map` and `object-gantt` schemas also accept a block that declares none of the three
|
|
768
|
+
when its `dataSource.object` names the object, because the registration's `ElementDataSourceGate`
|
|
769
|
+
lands that name on `objectName`. The `objectName` input description now says so.
|
|
770
|
+
- c6198c2: **Breaking for authored metadata:** `ComponentInput.label`, `ComponentInput.defaultValue` and
|
|
771
|
+
`ComponentInput.advanced` are RETIRED on both faces (objectui#7493 item ① and objectui#7781;
|
|
772
|
+
maintainer ruling A of 2026-09-06, immediate, no deprecation window; ADR-0049 enforce-or-remove).
|
|
773
|
+
They are the three keys the manifest serializer does not forward, and nothing read them on any
|
|
774
|
+
publication or consumption path.
|
|
775
|
+
|
|
776
|
+
No manifest ever published them, so no consumer could ever have read them. `sdui-parser`'s
|
|
777
|
+
serializer (`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`,
|
|
778
|
+
`type`, `of`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
|
|
779
|
+
never reached `sdui.manifest.json`, the generated JSX `.d.ts`, or a diagnostic; its boundary type
|
|
780
|
+
has no slot for them; the registry's data-source seam reads `name` only; and neither the designer
|
|
781
|
+
nor the app-shell inspectors consult registry `inputs` at all. A structural census over every
|
|
782
|
+
`inputs:` array in the repository (re-measured on this change's merge-base, `name` 951 and `type`
|
|
783
|
+
951 as the controls) counted the writes: `label` 908, `defaultValue` 245, `advanced` 9 — written on
|
|
784
|
+
nearly every registration, read by nothing.
|
|
785
|
+
|
|
786
|
+
FROM → TO, per key — all three **TOMBSTONED, not removed**, because the route was measured on
|
|
787
|
+
the built face before it was chosen: `ComponentInputSchema` is a non-strict `z.object`, and an
|
|
788
|
+
undeclared key parses GREEN and is silently STRIPPED, so a deletion would have swallowed 1,162
|
|
789
|
+
authored values in silence. The tombstone is what makes the refusal loud and by name.
|
|
790
|
+
|
|
791
|
+
- `label?: string` → `label?: never` on the interface, `retirementTombstone()` on the Zod mirror.
|
|
792
|
+
Migration: delete the key. An input is identified by its `name` on every path that reaches it;
|
|
793
|
+
nothing ever rendered a label for it.
|
|
794
|
+
- `defaultValue?: any` → `defaultValue?: never` / `retirementTombstone()`. Migration: delete the
|
|
795
|
+
key. The renderer's own fallback read IS the default; tell the author about it in `description`,
|
|
796
|
+
which IS published. (Tightening the type to `unknown` was ruled out: it closes no error class,
|
|
797
|
+
since nothing reads the value.)
|
|
798
|
+
- `advanced?: boolean` → `advanced?: never` / `retirementTombstone()`. Migration: delete the key.
|
|
799
|
+
No designer surface ever hid an "advanced" input; there is nothing to write instead.
|
|
800
|
+
|
|
801
|
+
The retirement kit: `?: never` on `ComponentInput` (`packages/types/src/base.ts`), so authoring one
|
|
802
|
+
is a `tsc` error at the registration site; `retirementTombstone()` on `ComponentInputSchema`
|
|
803
|
+
(`packages/types/src/zod/base.zod.ts`), so an authored value is REFUSED at parse time with
|
|
804
|
+
`code: 'invalid_type'`, the key named in the issue `path`, and the migration note as the message
|
|
805
|
+
(one string, both channels). Pinned in
|
|
806
|
+
`packages/types/src/__tests__/component-input-retired-keys-7493.test.ts`, which also holds a
|
|
807
|
+
tree-scoped absence census over every `inputs:` array under `packages/**` and `apps/**`.
|
|
808
|
+
|
|
809
|
+
Accept-set change, stated plainly for reviewers: a document that sets any of the three keys on a
|
|
810
|
+
`ComponentInput` used to parse GREEN (the value was then dropped by the serializer) and now parses
|
|
811
|
+
RED. Every in-repo authoring site — 1,199 keys across 110 registration files, the three standalone
|
|
812
|
+
`ComponentInput[]` arrays and the two named input arrays `tsc` found included — is deleted in the same change, as the ruling's split rule
|
|
813
|
+
requires; the `WidgetRegistry` seam no longer copies the widget-manifest values onto the synthesized
|
|
814
|
+
`ComponentInput` (they fed nothing), and the data-source declaration `ELEMENT_DATA_SOURCE_INPUT`
|
|
815
|
+
drops its `label`. The patch entries on the other packages record exactly that: their registrations
|
|
816
|
+
stop authoring inert keys, with no runtime or published-manifest change.
|
|
817
|
+
|
|
818
|
+
The nine test files that read `defaultValue` off a registration were re-pinned against the
|
|
819
|
+
renderer's ACTUAL default (its own fallback read, or the `defaultProps` it ships) instead of the
|
|
820
|
+
declaration that went away; two assertions that only restated the shadow default were dropped with
|
|
821
|
+
the reason on the line.
|
|
822
|
+
|
|
823
|
+
The in-repo zero is what was measured. Whether anything OUTSIDE this repository writes these keys
|
|
824
|
+
is not measurable from here (the objectui#5674 limit); converting such a write from a silent drop
|
|
825
|
+
into a named refusal is exactly what the tombstones buy. `WidgetInput`'s own `label` /
|
|
826
|
+
`defaultValue` / `advanced` (the widget-manifest face) stay declared and writable — nothing has
|
|
827
|
+
ruled on that face; that it now has no reader either is recorded as objectui#7911.
|
|
828
|
+
- ce2aaef: One shared record-source ladder, five plugins delegate.
|
|
829
|
+
|
|
830
|
+
`@object-ui/core` publishes `resolveRecordSourceConfig(schema)` — the ONE implementation
|
|
831
|
+
of the ruled three-rung record source ladder: `data` first, then `staticData` wrapped as
|
|
832
|
+
`{ provider: 'value', items }`, then `objectName` folded to `{ provider: 'object' }`, and
|
|
833
|
+
`null` when nothing is bound. It is the PRODUCER whose output the reader
|
|
834
|
+
`resolveRecordSourceObjectName` (`b041b9c0c`) consumes, and it now sits beside it in the same module.
|
|
835
|
+
|
|
836
|
+
That ladder is published contract on both faces — `packages/types/src/objectql.ts` and its
|
|
837
|
+
zod mirror both ship `.describe()` strings naming `getDataConfig`'s order (`77cb489b4`,
|
|
838
|
+
maintainer ruling 2026-09-02), pinned by `objectql-record-source-refinement-6939.test.ts` —
|
|
839
|
+
and it was hand-copied into five plugin components with no gate holding them together. A
|
|
840
|
+
change to the ruled order had five edit sites and nothing that noticed a missed one; that
|
|
841
|
+
is the AGENTS.md #0.1 drift class.
|
|
842
|
+
|
|
843
|
+
**No behaviour changes.** `ObjectCalendar`, `ObjectGantt` and `ObjectTree` now call the
|
|
844
|
+
shared reader directly. `ObjectGrid` and `ObjectMap` keep their own bare-array `data`
|
|
845
|
+
shorthand as a documented head above the shared call and are otherwise unchanged.
|
|
846
|
+
`record-source-config.behaviourNeutrality-7632.test.ts` transcribes all five pre-collapse
|
|
847
|
+
bodies verbatim and asserts the post-collapse spelling agrees with each across the whole
|
|
848
|
+
input matrix, so a later edit to the shared reader that moves any site turns red.
|
|
849
|
+
|
|
850
|
+
**Two divergences were measured rather than assumed, and both are preserved.**
|
|
851
|
+
|
|
852
|
+
`ObjectCalendar`'s `'data' in schema && schema.data` guards existed because its parameter was
|
|
853
|
+
at that time the union `ObjectGridSchema | CalendarSchema`, whose `CalendarSchema` arm declared
|
|
854
|
+
neither key. (objectui#8651 has since re-pointed that parameter at the published
|
|
855
|
+
`ObjectCalendarSchema`, so the union is gone; the CONCLUSION below — that the guard had no
|
|
856
|
+
runtime effect and removing it is behaviour-neutral — is unaffected.)
|
|
857
|
+
That is a TypeScript narrowing device with no runtime effect — an absent property reads
|
|
858
|
+
`undefined`, falsy either way — so the guard could never change which rung is taken. The
|
|
859
|
+
shared reader's optional-property parameter accepts the union directly, and the
|
|
860
|
+
equivalence is pinned on a fixture that really lacks both keys rather than argued.
|
|
861
|
+
|
|
862
|
+
`ObjectGrid` and `ObjectMap` normalize a bare-array `data` to `{ provider: 'value', items }`;
|
|
863
|
+
`ObjectCalendar`, `ObjectGantt` and `ObjectTree` do not, and return the array verbatim. That
|
|
864
|
+
is a real divergence on off-contract input — `ViewData` is a discriminated union over object
|
|
865
|
+
variants, so an array under `data` cannot be published. It is NOT unified here: the shared
|
|
866
|
+
rung stays contract-strict and the two sites keep the head locally, the same way `b041b9c0c`
|
|
867
|
+
left the off-contract `{ provider: 'object' }` tails at their sites. Both sides of the fork are
|
|
868
|
+
pinned, so neither folding the head in nor deleting it as redundant can happen silently.
|
|
869
|
+
|
|
870
|
+
`ObjectTree`'s copy took `schema: any`; it now goes through the shared reader's typed
|
|
871
|
+
parameter. Types are erased at runtime, so nothing it resolves moves.
|
|
872
|
+
- 9a853f2: Retire the legacy string `sort` clause: one spelling, the array
|
|
873
|
+
(objectui#8221) — `convertSortToQueryParams` now REFUSES `"name desc"` with a
|
|
874
|
+
diagnostic naming `[{ field: 'name', order: 'desc' }]`, instead of lowering it.
|
|
875
|
+
|
|
876
|
+
**BREAKING for `@object-ui/core` consumers — scored `minor`, not `major`, per
|
|
877
|
+
AGENTS.md 版本号策略** (every package is in one fixed group, so a `major` here
|
|
878
|
+
would carry all 39 off the `@objectstack` major this repo is pinned to). The
|
|
879
|
+
breaking semantics are stated below rather than encoded in the version.
|
|
880
|
+
|
|
881
|
+
Director ruling, decision batch #77 (2026-09-07), option B. Three faces
|
|
882
|
+
disagreed about one key: `@object-ui/core` implemented the string clause
|
|
883
|
+
on purpose (`sort-query.ts`, docblock and all), `content/docs/plugins/plugin-map.mdx`
|
|
884
|
+
taught it as `sort?: string | SortConfig[]`, and the html tier answered
|
|
885
|
+
`type-mismatch` for it because all seven `sort` registrations publish
|
|
886
|
+
`type: 'array'` alone — while `@objectstack/spec` refuses the string outright on
|
|
887
|
+
`element-record-picker`. Option A (per-block string arms) was rejected by name:
|
|
888
|
+
it would make one key mean different things on different blocks.
|
|
889
|
+
|
|
890
|
+
**What moves.** `convertSortToQueryParams(sort)` narrows from
|
|
891
|
+
`string | QuerySortEntry[]` to `QuerySortEntry[]`, and the three declarations
|
|
892
|
+
that published a string arm narrow with it — `ObjectGridSchema.sort`,
|
|
893
|
+
`ObjectMapSchema.sort` and `ObjectGanttSchema.sort`, in the TypeScript face AND
|
|
894
|
+
in the zod mirror, together, because a narrowing that left `z.string()` in the
|
|
895
|
+
mirror is the declared-vs-enforced split this change exists to close. The local
|
|
896
|
+
`sort` declarations on `LineItemsPanel`, `ObjectTimeline` and
|
|
897
|
+
`deriveRelatedLists`'s ListView input narrow the same way.
|
|
898
|
+
|
|
899
|
+
**What a string does now.** Types are erased, so the signature stops a string
|
|
900
|
+
only at compile time; authored JSON and stored `sys_metadata` rows still reach
|
|
901
|
+
the sink carrying `"name desc"`. Such a value is REFUSED — the query carries no
|
|
902
|
+
`$orderby` — and `console.error` names the array form, quotes what arrived and
|
|
903
|
+
states the consequence, once per spelling. A silent `undefined` was the one
|
|
904
|
+
outcome the ruling ruled out.
|
|
905
|
+
|
|
906
|
+
**Measured consequences you may see.** A related list that inherited its child
|
|
907
|
+
object's default list-view sort in the legacy spelling stops inheriting it (the
|
|
908
|
+
console says so). `@objectstack/spec@17.3.0` still ACCEPTS the string on
|
|
909
|
+
`ListViewSchema.sort` and on `RecordRelatedListProps.sort`, so such metadata is
|
|
910
|
+
still spec-legal today; the spec-side pull-back is its own card. Two surfaces
|
|
911
|
+
are deliberately untouched, because they are a DIFFERENT string dialect that
|
|
912
|
+
never reaches this sink: `record:related_list`'s `'field'` / `'-field'` form,
|
|
913
|
+
normalized by `RelatedList.normalizeSortSpec`, and `ListView.parseSortConfig`,
|
|
914
|
+
which reads the platform view record the spec still blesses.
|
|
915
|
+
|
|
916
|
+
Docs teach the array only: `content/docs/plugins/plugin-map.mdx`,
|
|
917
|
+
`content/docs/plugins/plugin-view.mdx` and `packages/plugin-view/README.md`.
|
|
918
|
+
- ff7543c: `ObjectMapProps.clusterRadius`'s JSDoc said "in pixels"; `clusterMarkers` has
|
|
919
|
+
always used it as a coordinate-degree grid cell edge (`radius / 2 ** zoom`,
|
|
920
|
+
divided into the marker's `[lng, lat]` degrees), not a screen-space radius —
|
|
921
|
+
a host tuning clustering granularity by the documented unit would get a
|
|
922
|
+
completely different result than intended (objectui#5020).
|
|
923
|
+
|
|
924
|
+
No behavior, default, or name changes: clustering, the >100-visible-marker
|
|
925
|
+
auto-threshold, and tap-through zoom are unaffected, and `clusterRadius` has
|
|
926
|
+
no call sites outside `plugin-map/src` today (re-confirmed repo-wide,
|
|
927
|
+
including `apps/`, `examples/`, and the `objectstack` spec/server repo — the
|
|
928
|
+
default of `50` is what runs everywhere). This is a doc-comment correction
|
|
929
|
+
only, bringing the JSDoc in line with the README's already-correct wording
|
|
930
|
+
(post objectui#5002).
|
|
931
|
+
|
|
932
|
+
The latitude-anisotropy trade-off (a degree grid distorts east-west as
|
|
933
|
+
latitude rises) is a known design trade-off, not part of this fix.
|
|
934
|
+
- 2aac61f: `ObjectMap` now resolves marker titles through `@object-ui/core`'s
|
|
935
|
+
`getRecordDisplayName` (ADR-0079), instead of reading a hard-coded `'name'` key.
|
|
936
|
+
|
|
937
|
+
`getMapConfig` used to fill an absent title binding with the string literal
|
|
938
|
+
`'name'`, and the marker transform then did a bare `record[titleField]` read. For
|
|
939
|
+
every object whose display field is not literally `name`, that read was
|
|
940
|
+
`undefined`, so each marker popup titled itself `undefined`. The literal is gone
|
|
941
|
+
from both branches that carried it, and the read site hands the decision to the
|
|
942
|
+
same resolver `ObjectKanban`, `ObjectCalendar` and `ObjectGantt` already title
|
|
943
|
+
their items through — `ObjectMap` was the fourth renderer and the only one still
|
|
944
|
+
outside it.
|
|
945
|
+
|
|
946
|
+
An authored `map.titleField` keeps winning outright: it is passed through as the
|
|
947
|
+
resolver's explicit `titleField` option, which it checks first. What is new
|
|
948
|
+
underneath is everything a static field-name binding cannot express — the
|
|
949
|
+
object's declared `nameField`, its deprecated `displayNameField` alias, a legacy
|
|
950
|
+
`titleFormat` template, type-aware field derivation, and a name-ish probe over
|
|
951
|
+
the record's own keys for the inline-data case where no object definition is
|
|
952
|
+
fetched at all.
|
|
953
|
+
|
|
954
|
+
Records with no resolvable name now read `Record #<id>` rather than `undefined`
|
|
955
|
+
or a uniform `Marker`; the `Marker` placeholder is kept only for a record that
|
|
956
|
+
carries no id either. No authoring surface changes and no new map config keys.
|
|
957
|
+
- b180a64: `ObjectMap` reads `schema.data` in one place again, so an array-shorthand map stops
|
|
958
|
+
making a metadata request it never uses.
|
|
959
|
+
|
|
960
|
+
The fetch effect carried a second short-circuit beside the `props.data` one
|
|
961
|
+
objectui#5003 fixed: it read `schema.data` directly and tested whether that value was
|
|
962
|
+
itself an array. eslint reported it as `missing dependency: schema.data` — the last
|
|
963
|
+
`react-hooks/exhaustive-deps` warning on that effect.
|
|
964
|
+
|
|
965
|
+
The dependency was never actually missing. `getDataConfig(schema)` already returns
|
|
966
|
+
`schema.data` verbatim, and the result is memoized on `JSON.stringify(rawDataConfig)`
|
|
967
|
+
into `dataConfig`, which **is** one of the effect's declared dependencies. The authored
|
|
968
|
+
rows therefore reached the effect before this change; the direct read was a duplicate of
|
|
969
|
+
an already-threaded value, which is why neither adding a dependency nor deleting the
|
|
970
|
+
branch was right.
|
|
971
|
+
|
|
972
|
+
The array handling moved into `getDataConfig`, where `ObjectGrid`'s own `getDataConfig`
|
|
973
|
+
already pins the same normalization (`"Check if data is an array (shorthand format)"`).
|
|
974
|
+
Same rows render, and the effect now reads only `dataConfig`.
|
|
975
|
+
|
|
976
|
+
One behavioural consequence, and it is the point: an array under `data` now yields
|
|
977
|
+
`provider: 'value'`, so `hasInlineData` is true and the sibling effect no longer calls
|
|
978
|
+
`dataSource.getObjectSchema()` for it. That request's only read site is
|
|
979
|
+
`buildExpandFields()` inside the object-provider fetch branch, which an inline schema
|
|
980
|
+
never reaches — so the call was pure waste, and the shorthand now behaves exactly like
|
|
981
|
+
the declared `{ provider: 'value', items }` form it is shorthand for.
|
|
982
|
+
|
|
983
|
+
Deleting the branch instead was measured, not assumed: with no producer-side handling,
|
|
984
|
+
an array-shorthand map renders `Error: DataSource required for object/api providers`
|
|
985
|
+
rather than its markers. The shorthand is a live convention in six sibling blocks
|
|
986
|
+
(`ObjectGrid`, `ListView`, `ObjectTree`, `ObjectChart`, `ObjectDataTable`,
|
|
987
|
+
`calendar-view-renderer`), so `object-map` would have become the one block in the family
|
|
988
|
+
that answers it with an error box.
|
|
989
|
+
- 538ed92: `ObjectMap`: make the marker `useMemo` actually memoize.
|
|
990
|
+
|
|
991
|
+
`getMapConfig(schema)` ran unmemoized in the render body, so `mapConfig` carried
|
|
992
|
+
a fresh object identity on every render. The marker transform names `mapConfig`
|
|
993
|
+
in its dependency array, so it recomputed on every single render — walking every
|
|
994
|
+
record through `extractCoordinates` and the display-name resolver, and re-running
|
|
995
|
+
`ObjectMapConfigSchema.safeParse` on each pass — while declaring that it does not.
|
|
996
|
+
The invalidation cascaded on into `filteredMarkers`, `clusteredData`,
|
|
997
|
+
`markerBounds` and `initialViewState`.
|
|
998
|
+
|
|
999
|
+
`mapConfig` is now memoized on `schema`, the one value `getMapConfig` reads.
|
|
1000
|
+
Behaviour is unchanged; the config is still rebuilt whenever the schema
|
|
1001
|
+
genuinely changes.
|
|
1002
|
+
- cfcff30: Each package's README now states, up front, that it needs a bundler: importing it from plain Node ESM fails, and that is a supported-configuration boundary rather than a defect.
|
|
1003
|
+
|
|
1004
|
+
`@object-ui/plugin-dashboard` imports `react-grid-layout/css/styles.css` at module
|
|
1005
|
+
scope and `@object-ui/plugin-map` imports `maplibre-gl/dist/maplibre-gl.css`;
|
|
1006
|
+
`@object-ui/app-shell` reaches the first of those through the static
|
|
1007
|
+
`@object-ui/plugin-dashboard` imports in `DashboardView` and `ReportView`. Node has
|
|
1008
|
+
no loader for `.css` at all, so all three resolve and then die during evaluation:
|
|
1009
|
+
|
|
1010
|
+
```
|
|
1011
|
+
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".css"
|
|
1012
|
+
for .../react-grid-layout/css/styles.css
|
|
1013
|
+
```
|
|
1014
|
+
|
|
1015
|
+
Nothing about how these packages load has changed — every supported host bundles
|
|
1016
|
+
them (Vite, webpack, or Next with the package in `transpilePackages`), and that is
|
|
1017
|
+
still the only supported way to consume them. What changed is that the boundary is
|
|
1018
|
+
now written where a consumer meets it, instead of being learned from a red import.
|
|
1019
|
+
|
|
1020
|
+
objectui#5384 ruled unbundled Node consumption **unsupported** for style-carrying
|
|
1021
|
+
plugin packages — permanently, over the three packages as a group — rather than
|
|
1022
|
+
moving the stylesheet imports out of module scope. No unbundled-Node consumer
|
|
1023
|
+
exists, and buying permanent machinery to close a capability gap nobody is pulling
|
|
1024
|
+
on was the trade the ruling declined. A real consumer request reopens it as a
|
|
1025
|
+
design question, not as a defect: the READMEs say so and name the issue.
|
|
1026
|
+
- 2aa2c22: `ObjectMap` no longer serializes its data config on every render.
|
|
1027
|
+
|
|
1028
|
+
`getDataConfig(schema)` was called bare in the render body and its result
|
|
1029
|
+
re-serialized with `JSON.stringify` on every render, purely to give `dataConfig`
|
|
1030
|
+
the stable identity its fetch effect depends on. `getDataConfig` is a pure
|
|
1031
|
+
function of `schema`, so `useMemo(() => getDataConfig(schema), [schema])` gives
|
|
1032
|
+
the same identity with no serialize and no per-render rebuild.
|
|
1033
|
+
|
|
1034
|
+
This also fixes a crash. `JSON.stringify` throws on a value it cannot serialize,
|
|
1035
|
+
and the config's passthrough branch returns the author's own `schema.data`
|
|
1036
|
+
object verbatim — inline rows included. A map handed inline records carrying a
|
|
1037
|
+
back-reference (an `$expand`-ed lookup) or a `BigInt` id threw from the render
|
|
1038
|
+
body and took the whole map subtree down with it. Comparing identities never
|
|
1039
|
+
serializes, so the config no longer has to be serializable at all.
|
|
1040
|
+
- Updated dependencies [7b10bef]
|
|
1041
|
+
- Updated dependencies [97abedc]
|
|
1042
|
+
- Updated dependencies [b46c58f]
|
|
1043
|
+
- Updated dependencies [ad694ac]
|
|
1044
|
+
- Updated dependencies [6f96fca]
|
|
1045
|
+
- Updated dependencies [0aacecc]
|
|
1046
|
+
- Updated dependencies [777fca2]
|
|
1047
|
+
- Updated dependencies [c131d9e]
|
|
1048
|
+
- Updated dependencies [5f00ff4]
|
|
1049
|
+
- Updated dependencies [c9e073a]
|
|
1050
|
+
- Updated dependencies [7b395d8]
|
|
1051
|
+
- Updated dependencies [0879812]
|
|
1052
|
+
- Updated dependencies [8cedb0d]
|
|
1053
|
+
- Updated dependencies [162621b]
|
|
1054
|
+
- Updated dependencies [4c6f549]
|
|
1055
|
+
- Updated dependencies [6cc910b]
|
|
1056
|
+
- Updated dependencies [061f5e8]
|
|
1057
|
+
- Updated dependencies [2dd4d3f]
|
|
1058
|
+
- Updated dependencies [4ab4f1b]
|
|
1059
|
+
- Updated dependencies [e3ea4f9]
|
|
1060
|
+
- Updated dependencies [8b1f066]
|
|
1061
|
+
- Updated dependencies [af243c1]
|
|
1062
|
+
- Updated dependencies [cff4b77]
|
|
1063
|
+
- Updated dependencies [961ceaa]
|
|
1064
|
+
- Updated dependencies [f3f4e4c]
|
|
1065
|
+
- Updated dependencies [a05c350]
|
|
1066
|
+
- Updated dependencies [2b5f509]
|
|
1067
|
+
- Updated dependencies [808f339]
|
|
1068
|
+
- Updated dependencies [6cf5999]
|
|
1069
|
+
- Updated dependencies [274e14a]
|
|
1070
|
+
- Updated dependencies [8c10f4f]
|
|
1071
|
+
- Updated dependencies [90dac98]
|
|
1072
|
+
- Updated dependencies [6096f20]
|
|
1073
|
+
- Updated dependencies [544aca2]
|
|
1074
|
+
- Updated dependencies [ea02938]
|
|
1075
|
+
- Updated dependencies [a14fb23]
|
|
1076
|
+
- Updated dependencies [ae98f1d]
|
|
1077
|
+
- Updated dependencies [f98eddf]
|
|
1078
|
+
- Updated dependencies [ce6bd99]
|
|
1079
|
+
- Updated dependencies [a5b08c9]
|
|
1080
|
+
- Updated dependencies [86982ac]
|
|
1081
|
+
- Updated dependencies [cdefa2a]
|
|
1082
|
+
- Updated dependencies [0961d5e]
|
|
1083
|
+
- Updated dependencies [6276478]
|
|
1084
|
+
- Updated dependencies [ff14e29]
|
|
1085
|
+
- Updated dependencies [9b28151]
|
|
1086
|
+
- Updated dependencies [64563a9]
|
|
1087
|
+
- Updated dependencies [1a5003f]
|
|
1088
|
+
- Updated dependencies [09ab32b]
|
|
1089
|
+
- Updated dependencies [8acc51b]
|
|
1090
|
+
- Updated dependencies [93a689d]
|
|
1091
|
+
- Updated dependencies [e5f4343]
|
|
1092
|
+
- Updated dependencies [3261e64]
|
|
1093
|
+
- Updated dependencies [f5178a2]
|
|
1094
|
+
- Updated dependencies [2ad3671]
|
|
1095
|
+
- Updated dependencies [d22b37b]
|
|
1096
|
+
- Updated dependencies [1daf477]
|
|
1097
|
+
- Updated dependencies [3d614ea]
|
|
1098
|
+
- Updated dependencies [6c2f3c5]
|
|
1099
|
+
- Updated dependencies [fb13e85]
|
|
1100
|
+
- Updated dependencies [c2d8659]
|
|
1101
|
+
- Updated dependencies [e0f8202]
|
|
1102
|
+
- Updated dependencies [9fbbb17]
|
|
1103
|
+
- Updated dependencies [c3a26cc]
|
|
1104
|
+
- Updated dependencies [a66e58e]
|
|
1105
|
+
- Updated dependencies [d89492c]
|
|
1106
|
+
- Updated dependencies [9a5f998]
|
|
1107
|
+
- Updated dependencies [9327397]
|
|
1108
|
+
- Updated dependencies [17cc3a3]
|
|
1109
|
+
- Updated dependencies [02e6d36]
|
|
1110
|
+
- Updated dependencies [4758b33]
|
|
1111
|
+
- Updated dependencies [4758b33]
|
|
1112
|
+
- Updated dependencies [9c78ebe]
|
|
1113
|
+
- Updated dependencies [9c78ebe]
|
|
1114
|
+
- Updated dependencies [12809a5]
|
|
1115
|
+
- Updated dependencies [7afc81d]
|
|
1116
|
+
- Updated dependencies [f9c06ef]
|
|
1117
|
+
- Updated dependencies [5ad3b88]
|
|
1118
|
+
- Updated dependencies [f9d772b]
|
|
1119
|
+
- Updated dependencies [97b6c21]
|
|
1120
|
+
- Updated dependencies [26ca2ad]
|
|
1121
|
+
- Updated dependencies [41ae65b]
|
|
1122
|
+
- Updated dependencies [baac95a]
|
|
1123
|
+
- Updated dependencies [13220af]
|
|
1124
|
+
- Updated dependencies [29b45f6]
|
|
1125
|
+
- Updated dependencies [39b8d51]
|
|
1126
|
+
- Updated dependencies [17b323e]
|
|
1127
|
+
- Updated dependencies [b956e69]
|
|
1128
|
+
- Updated dependencies [33e58d8]
|
|
1129
|
+
- Updated dependencies [256b4c9]
|
|
1130
|
+
- Updated dependencies [c5ec15c]
|
|
1131
|
+
- Updated dependencies [fec3b1a]
|
|
1132
|
+
- Updated dependencies [b8e0941]
|
|
1133
|
+
- Updated dependencies [0c50f18]
|
|
1134
|
+
- Updated dependencies [1dae95a]
|
|
1135
|
+
- Updated dependencies [e32dae1]
|
|
1136
|
+
- Updated dependencies [30b11ad]
|
|
1137
|
+
- Updated dependencies [4aebea0]
|
|
1138
|
+
- Updated dependencies [f976774]
|
|
1139
|
+
- Updated dependencies [3d6badf]
|
|
1140
|
+
- Updated dependencies [25cb364]
|
|
1141
|
+
- Updated dependencies [a60539b]
|
|
1142
|
+
- Updated dependencies [de1b879]
|
|
1143
|
+
- Updated dependencies [c6678b1]
|
|
1144
|
+
- Updated dependencies [0638322]
|
|
1145
|
+
- Updated dependencies [e3782d2]
|
|
1146
|
+
- Updated dependencies [db0beb2]
|
|
1147
|
+
- Updated dependencies [997ce38]
|
|
1148
|
+
- Updated dependencies [ae0b9d3]
|
|
1149
|
+
- Updated dependencies [ad1785c]
|
|
1150
|
+
- Updated dependencies [3b469c8]
|
|
1151
|
+
- Updated dependencies [990a2d6]
|
|
1152
|
+
- Updated dependencies [1c84036]
|
|
1153
|
+
- Updated dependencies [1c84036]
|
|
1154
|
+
- Updated dependencies [6650259]
|
|
1155
|
+
- Updated dependencies [4f8b7f8]
|
|
1156
|
+
- Updated dependencies [9e6619f]
|
|
1157
|
+
- Updated dependencies [f6ae5e2]
|
|
1158
|
+
- Updated dependencies [7343376]
|
|
1159
|
+
- Updated dependencies [b2683a2]
|
|
1160
|
+
- Updated dependencies [dded788]
|
|
1161
|
+
- Updated dependencies [b45d463]
|
|
1162
|
+
- Updated dependencies [54a7830]
|
|
1163
|
+
- Updated dependencies [f3135a4]
|
|
1164
|
+
- Updated dependencies [b5696d3]
|
|
1165
|
+
- Updated dependencies [3f9d926]
|
|
1166
|
+
- Updated dependencies [e978ed5]
|
|
1167
|
+
- Updated dependencies [6a7f24e]
|
|
1168
|
+
- Updated dependencies [b3c96d6]
|
|
1169
|
+
- Updated dependencies [8d0ca91]
|
|
1170
|
+
- Updated dependencies [c30c8dd]
|
|
1171
|
+
- Updated dependencies [deca847]
|
|
1172
|
+
- Updated dependencies [328abeb]
|
|
1173
|
+
- Updated dependencies [dd0d78f]
|
|
1174
|
+
- Updated dependencies [24d3e65]
|
|
1175
|
+
- Updated dependencies [95a7c8d]
|
|
1176
|
+
- Updated dependencies [e227156]
|
|
1177
|
+
- Updated dependencies [cc4e476]
|
|
1178
|
+
- Updated dependencies [92970c4]
|
|
1179
|
+
- Updated dependencies [d570eaa]
|
|
1180
|
+
- Updated dependencies [4b742f4]
|
|
1181
|
+
- Updated dependencies [42687ba]
|
|
1182
|
+
- Updated dependencies [6cd8f66]
|
|
1183
|
+
- Updated dependencies [24a0f14]
|
|
1184
|
+
- Updated dependencies [797a30f]
|
|
1185
|
+
- Updated dependencies [b4075c0]
|
|
1186
|
+
- Updated dependencies [9b85600]
|
|
1187
|
+
- Updated dependencies [99878d8]
|
|
1188
|
+
- Updated dependencies [3c13675]
|
|
1189
|
+
- Updated dependencies [63ab761]
|
|
1190
|
+
- Updated dependencies [0eb9f36]
|
|
1191
|
+
- Updated dependencies [ae582b7]
|
|
1192
|
+
- Updated dependencies [a4b017e]
|
|
1193
|
+
- Updated dependencies [559a2e2]
|
|
1194
|
+
- Updated dependencies [db11afd]
|
|
1195
|
+
- Updated dependencies [154075a]
|
|
1196
|
+
- Updated dependencies [582edef]
|
|
1197
|
+
- Updated dependencies [19f484f]
|
|
1198
|
+
- Updated dependencies [0a78a20]
|
|
1199
|
+
- Updated dependencies [615346d]
|
|
1200
|
+
- Updated dependencies [75dcc81]
|
|
1201
|
+
- Updated dependencies [55a12a8]
|
|
1202
|
+
- Updated dependencies [edfcf5a]
|
|
1203
|
+
- Updated dependencies [0a3e540]
|
|
1204
|
+
- Updated dependencies [c021b35]
|
|
1205
|
+
- Updated dependencies [f61dab1]
|
|
1206
|
+
- Updated dependencies [b0a05dd]
|
|
1207
|
+
- Updated dependencies [dd5ff19]
|
|
1208
|
+
- Updated dependencies [81f8498]
|
|
1209
|
+
- Updated dependencies [a782fa7]
|
|
1210
|
+
- Updated dependencies [0645133]
|
|
1211
|
+
- Updated dependencies [76e9df0]
|
|
1212
|
+
- Updated dependencies [0ecaa7d]
|
|
1213
|
+
- Updated dependencies [b24f93a]
|
|
1214
|
+
- Updated dependencies [6158e4c]
|
|
1215
|
+
- Updated dependencies [c27b575]
|
|
1216
|
+
- Updated dependencies [84b275c]
|
|
1217
|
+
- Updated dependencies [0e6e76b]
|
|
1218
|
+
- Updated dependencies [bf43afa]
|
|
1219
|
+
- Updated dependencies [858eafb]
|
|
1220
|
+
- Updated dependencies [0ffc423]
|
|
1221
|
+
- Updated dependencies [3cc4fe5]
|
|
1222
|
+
- Updated dependencies [cd5b19a]
|
|
1223
|
+
- Updated dependencies [cd5b19a]
|
|
1224
|
+
- Updated dependencies [17dc167]
|
|
1225
|
+
- Updated dependencies [20d23be]
|
|
1226
|
+
- Updated dependencies [20d23be]
|
|
1227
|
+
- Updated dependencies [2e3da72]
|
|
1228
|
+
- Updated dependencies [1263e40]
|
|
1229
|
+
- Updated dependencies [e6bc087]
|
|
1230
|
+
- Updated dependencies [8bab157]
|
|
1231
|
+
- Updated dependencies [a7557a7]
|
|
1232
|
+
- Updated dependencies [7d074ba]
|
|
1233
|
+
- Updated dependencies [6158e4c]
|
|
1234
|
+
- Updated dependencies [6158e4c]
|
|
1235
|
+
- Updated dependencies [52aad5c]
|
|
1236
|
+
- Updated dependencies [18d1a0a]
|
|
1237
|
+
- Updated dependencies [7fed09d]
|
|
1238
|
+
- Updated dependencies [58da8ae]
|
|
1239
|
+
- Updated dependencies [a8b9889]
|
|
1240
|
+
- Updated dependencies [138ad45]
|
|
1241
|
+
- Updated dependencies [138ad45]
|
|
1242
|
+
- Updated dependencies [5262f7d]
|
|
1243
|
+
- Updated dependencies [6aa029b]
|
|
1244
|
+
- Updated dependencies [2124d04]
|
|
1245
|
+
- Updated dependencies [be52115]
|
|
1246
|
+
- Updated dependencies [770cc5b]
|
|
1247
|
+
- Updated dependencies [1a88ce2]
|
|
1248
|
+
- Updated dependencies [a1a44d6]
|
|
1249
|
+
- Updated dependencies [e0a9c67]
|
|
1250
|
+
- Updated dependencies [5638529]
|
|
1251
|
+
- Updated dependencies [5638529]
|
|
1252
|
+
- Updated dependencies [c476be0]
|
|
1253
|
+
- Updated dependencies [c82ff39]
|
|
1254
|
+
- Updated dependencies [6c3da53]
|
|
1255
|
+
- Updated dependencies [31987bd]
|
|
1256
|
+
- Updated dependencies [3c3ce15]
|
|
1257
|
+
- Updated dependencies [063119f]
|
|
1258
|
+
- Updated dependencies [e100589]
|
|
1259
|
+
- Updated dependencies [304f611]
|
|
1260
|
+
- Updated dependencies [e46ee77]
|
|
1261
|
+
- Updated dependencies [f9c8c4e]
|
|
1262
|
+
- Updated dependencies [6e9c8d2]
|
|
1263
|
+
- Updated dependencies [9547063]
|
|
1264
|
+
- Updated dependencies [3f6efd6]
|
|
1265
|
+
- Updated dependencies [c4ab6d0]
|
|
1266
|
+
- Updated dependencies [0e9058b]
|
|
1267
|
+
- Updated dependencies [5988b6b]
|
|
1268
|
+
- Updated dependencies [6158e4c]
|
|
1269
|
+
- Updated dependencies [00ccdf7]
|
|
1270
|
+
- Updated dependencies [9d9ed54]
|
|
1271
|
+
- Updated dependencies [4a1adb7]
|
|
1272
|
+
- Updated dependencies [50c73fe]
|
|
1273
|
+
- Updated dependencies [ca3de72]
|
|
1274
|
+
- Updated dependencies [83e3f83]
|
|
1275
|
+
- Updated dependencies [401611b]
|
|
1276
|
+
- Updated dependencies [2c0ddf2]
|
|
1277
|
+
- Updated dependencies [4abc0aa]
|
|
1278
|
+
- Updated dependencies [f560ded]
|
|
1279
|
+
- Updated dependencies [2b188fa]
|
|
1280
|
+
- Updated dependencies [b654d4e]
|
|
1281
|
+
- Updated dependencies [f68e0a0]
|
|
1282
|
+
- Updated dependencies [aea682a]
|
|
1283
|
+
- Updated dependencies [fcdc8ec]
|
|
1284
|
+
- Updated dependencies [2d576e4]
|
|
1285
|
+
- Updated dependencies [8366acc]
|
|
1286
|
+
- Updated dependencies [95e58a3]
|
|
1287
|
+
- Updated dependencies [9d7419b]
|
|
1288
|
+
- Updated dependencies [fc7db05]
|
|
1289
|
+
- Updated dependencies [9ed8d0f]
|
|
1290
|
+
- Updated dependencies [c73cdb5]
|
|
1291
|
+
- Updated dependencies [6f5719e]
|
|
1292
|
+
- Updated dependencies [64dae8e]
|
|
1293
|
+
- Updated dependencies [06a8af5]
|
|
1294
|
+
- Updated dependencies [6a91586]
|
|
1295
|
+
- Updated dependencies [a04d7c6]
|
|
1296
|
+
- Updated dependencies [5ccc500]
|
|
1297
|
+
- Updated dependencies [f3c2bb0]
|
|
1298
|
+
- Updated dependencies [978507b]
|
|
1299
|
+
- Updated dependencies [778138e]
|
|
1300
|
+
- Updated dependencies [9801765]
|
|
1301
|
+
- Updated dependencies [9cebfca]
|
|
1302
|
+
- Updated dependencies [460575f]
|
|
1303
|
+
- Updated dependencies [d796c8d]
|
|
1304
|
+
- Updated dependencies [1b1d772]
|
|
1305
|
+
- Updated dependencies [d88e20f]
|
|
1306
|
+
- Updated dependencies [2d7304d]
|
|
1307
|
+
- Updated dependencies [636b236]
|
|
1308
|
+
- Updated dependencies [4172589]
|
|
1309
|
+
- Updated dependencies [d6d8fb9]
|
|
1310
|
+
- Updated dependencies [64d624d]
|
|
1311
|
+
- Updated dependencies [053fdc8]
|
|
1312
|
+
- Updated dependencies [ae476b8]
|
|
1313
|
+
- Updated dependencies [39f4309]
|
|
1314
|
+
- Updated dependencies [95bad12]
|
|
1315
|
+
- Updated dependencies [d2fb6ef]
|
|
1316
|
+
- Updated dependencies [7cd3987]
|
|
1317
|
+
- Updated dependencies [ee3b878]
|
|
1318
|
+
- Updated dependencies [e304a4e]
|
|
1319
|
+
- Updated dependencies [fda49e5]
|
|
1320
|
+
- Updated dependencies [490d9a9]
|
|
1321
|
+
- Updated dependencies [fc62bb4]
|
|
1322
|
+
- Updated dependencies [41df893]
|
|
1323
|
+
- Updated dependencies [0cba1b7]
|
|
1324
|
+
- Updated dependencies [00f3eb5]
|
|
1325
|
+
- Updated dependencies [1ec291c]
|
|
1326
|
+
- Updated dependencies [453dbaa]
|
|
1327
|
+
- Updated dependencies [f8cdbf2]
|
|
1328
|
+
- Updated dependencies [69a2163]
|
|
1329
|
+
- Updated dependencies [24e027e]
|
|
1330
|
+
- Updated dependencies [2c3cd1b]
|
|
1331
|
+
- Updated dependencies [e176053]
|
|
1332
|
+
- Updated dependencies [e30ed15]
|
|
1333
|
+
- Updated dependencies [90665e0]
|
|
1334
|
+
- Updated dependencies [194fae1]
|
|
1335
|
+
- Updated dependencies [7e19d03]
|
|
1336
|
+
- Updated dependencies [1e946c9]
|
|
1337
|
+
- Updated dependencies [546ddf7]
|
|
1338
|
+
- Updated dependencies [864154e]
|
|
1339
|
+
- Updated dependencies [b023625]
|
|
1340
|
+
- Updated dependencies [75bd83d]
|
|
1341
|
+
- Updated dependencies [44d075b]
|
|
1342
|
+
- Updated dependencies [40c479a]
|
|
1343
|
+
- Updated dependencies [971d387]
|
|
1344
|
+
- Updated dependencies [ee851c3]
|
|
1345
|
+
- Updated dependencies [6414dfd]
|
|
1346
|
+
- Updated dependencies [a8d5c71]
|
|
1347
|
+
- Updated dependencies [905b21f]
|
|
1348
|
+
- Updated dependencies [88e9109]
|
|
1349
|
+
- Updated dependencies [2c45966]
|
|
1350
|
+
- Updated dependencies [db3a600]
|
|
1351
|
+
- Updated dependencies [3a3db76]
|
|
1352
|
+
- Updated dependencies [0d723a3]
|
|
1353
|
+
- Updated dependencies [0c95d3d]
|
|
1354
|
+
- Updated dependencies [3e4fa2c]
|
|
1355
|
+
- Updated dependencies [b5b928a]
|
|
1356
|
+
- Updated dependencies [6fd2cf7]
|
|
1357
|
+
- Updated dependencies [52a43de]
|
|
1358
|
+
- Updated dependencies [195052f]
|
|
1359
|
+
- Updated dependencies [e4559d1]
|
|
1360
|
+
- Updated dependencies [2c71482]
|
|
1361
|
+
- Updated dependencies [129bcc5]
|
|
1362
|
+
- Updated dependencies [a26b9e4]
|
|
1363
|
+
- Updated dependencies [5ef9c4f]
|
|
1364
|
+
- Updated dependencies [46f0bb4]
|
|
1365
|
+
- Updated dependencies [06b82b8]
|
|
1366
|
+
- Updated dependencies [8ec11e1]
|
|
1367
|
+
- Updated dependencies [6f81384]
|
|
1368
|
+
- Updated dependencies [22ba927]
|
|
1369
|
+
- Updated dependencies [f8c70f4]
|
|
1370
|
+
- Updated dependencies [8f1d995]
|
|
1371
|
+
- Updated dependencies [f9c34df]
|
|
1372
|
+
- Updated dependencies [dddb942]
|
|
1373
|
+
- Updated dependencies [29754cf]
|
|
1374
|
+
- Updated dependencies [d7de534]
|
|
1375
|
+
- Updated dependencies [3c2b6f7]
|
|
1376
|
+
- Updated dependencies [6e88630]
|
|
1377
|
+
- Updated dependencies [b84dc18]
|
|
1378
|
+
- Updated dependencies [ac8abb0]
|
|
1379
|
+
- Updated dependencies [9d86e1d]
|
|
1380
|
+
- Updated dependencies [3a5817f]
|
|
1381
|
+
- Updated dependencies [99a3c2d]
|
|
1382
|
+
- Updated dependencies [5961030]
|
|
1383
|
+
- Updated dependencies [f24de8b]
|
|
1384
|
+
- Updated dependencies [c8ea8af]
|
|
1385
|
+
- Updated dependencies [3190414]
|
|
1386
|
+
- Updated dependencies [4e480f5]
|
|
1387
|
+
- Updated dependencies [38a123c]
|
|
1388
|
+
- Updated dependencies [299102e]
|
|
1389
|
+
- Updated dependencies [30c73cd]
|
|
1390
|
+
- Updated dependencies [830ed58]
|
|
1391
|
+
- Updated dependencies [d7acad6]
|
|
1392
|
+
- Updated dependencies [45a9aeb]
|
|
1393
|
+
- Updated dependencies [713db46]
|
|
1394
|
+
- Updated dependencies [c71e14d]
|
|
1395
|
+
- Updated dependencies [bf3a03c]
|
|
1396
|
+
- Updated dependencies [cb55718]
|
|
1397
|
+
- Updated dependencies [748494b]
|
|
1398
|
+
- Updated dependencies [5967be0]
|
|
1399
|
+
- Updated dependencies [831be72]
|
|
1400
|
+
- Updated dependencies [29cb85b]
|
|
1401
|
+
- Updated dependencies [3e028c8]
|
|
1402
|
+
- Updated dependencies [d0889e2]
|
|
1403
|
+
- Updated dependencies [ce503e5]
|
|
1404
|
+
- Updated dependencies [f20dcf0]
|
|
1405
|
+
- Updated dependencies [12402a9]
|
|
1406
|
+
- Updated dependencies [aff3d7a]
|
|
1407
|
+
- Updated dependencies [4ca30d0]
|
|
1408
|
+
- Updated dependencies [7a5da14]
|
|
1409
|
+
- Updated dependencies [2c1c967]
|
|
1410
|
+
- Updated dependencies [9486ac6]
|
|
1411
|
+
- Updated dependencies [9486ac6]
|
|
1412
|
+
- Updated dependencies [4d5f9b4]
|
|
1413
|
+
- Updated dependencies [d6ceb8d]
|
|
1414
|
+
- Updated dependencies [dc4365c]
|
|
1415
|
+
- Updated dependencies [e321d52]
|
|
1416
|
+
- Updated dependencies [4c68077]
|
|
1417
|
+
- Updated dependencies [7977ff9]
|
|
1418
|
+
- Updated dependencies [3beef6d]
|
|
1419
|
+
- Updated dependencies [06b8c42]
|
|
1420
|
+
- Updated dependencies [46b9bc9]
|
|
1421
|
+
- Updated dependencies [45ac2cb]
|
|
1422
|
+
- Updated dependencies [b97790a]
|
|
1423
|
+
- Updated dependencies [7c9b044]
|
|
1424
|
+
- Updated dependencies [d47de51]
|
|
1425
|
+
- Updated dependencies [3fe6463]
|
|
1426
|
+
- Updated dependencies [31ab372]
|
|
1427
|
+
- Updated dependencies [846889b]
|
|
1428
|
+
- Updated dependencies [2acd8e1]
|
|
1429
|
+
- Updated dependencies [26896c6]
|
|
1430
|
+
- Updated dependencies [67fc3b0]
|
|
1431
|
+
- Updated dependencies [33a3b3c]
|
|
1432
|
+
- Updated dependencies [b87f15b]
|
|
1433
|
+
- Updated dependencies [045d20b]
|
|
1434
|
+
- Updated dependencies [a2d2515]
|
|
1435
|
+
- Updated dependencies [c18d099]
|
|
1436
|
+
- Updated dependencies [adb2a86]
|
|
1437
|
+
- Updated dependencies [03380aa]
|
|
1438
|
+
- Updated dependencies [4562ea5]
|
|
1439
|
+
- Updated dependencies [3619792]
|
|
1440
|
+
- Updated dependencies [3561bd2]
|
|
1441
|
+
- Updated dependencies [bf97b98]
|
|
1442
|
+
- Updated dependencies [b0d308d]
|
|
1443
|
+
- Updated dependencies [40f34b4]
|
|
1444
|
+
- Updated dependencies [8063bcb]
|
|
1445
|
+
- Updated dependencies [b74a859]
|
|
1446
|
+
- Updated dependencies [d4493fd]
|
|
1447
|
+
- Updated dependencies [240b80f]
|
|
1448
|
+
- Updated dependencies [77cb489]
|
|
1449
|
+
- Updated dependencies [bfaa158]
|
|
1450
|
+
- Updated dependencies [777e5c6]
|
|
1451
|
+
- Updated dependencies [0c386dd]
|
|
1452
|
+
- Updated dependencies [9e37d9b]
|
|
1453
|
+
- Updated dependencies [5ad86dd]
|
|
1454
|
+
- Updated dependencies [16a725f]
|
|
1455
|
+
- Updated dependencies [4dfdcc3]
|
|
1456
|
+
- Updated dependencies [6a449fc]
|
|
1457
|
+
- Updated dependencies [446d93d]
|
|
1458
|
+
- Updated dependencies [ecd9cb2]
|
|
1459
|
+
- Updated dependencies [98d4108]
|
|
1460
|
+
- Updated dependencies [0e3b3be]
|
|
1461
|
+
- Updated dependencies [a29ae2d]
|
|
1462
|
+
- Updated dependencies [00d3f09]
|
|
1463
|
+
- Updated dependencies [4388f71]
|
|
1464
|
+
- Updated dependencies [0b1ac58]
|
|
1465
|
+
- Updated dependencies [c93b4d5]
|
|
1466
|
+
- Updated dependencies [c1fe272]
|
|
1467
|
+
- Updated dependencies [3cab570]
|
|
1468
|
+
- Updated dependencies [8ad218d]
|
|
1469
|
+
- Updated dependencies [3e41187]
|
|
1470
|
+
- Updated dependencies [5f78953]
|
|
1471
|
+
- Updated dependencies [639114c]
|
|
1472
|
+
- Updated dependencies [1f31d3a]
|
|
1473
|
+
- Updated dependencies [d1842ab]
|
|
1474
|
+
- Updated dependencies [78ca238]
|
|
1475
|
+
- Updated dependencies [351eb31]
|
|
1476
|
+
- Updated dependencies [20c04b2]
|
|
1477
|
+
- Updated dependencies [48c19bd]
|
|
1478
|
+
- Updated dependencies [a6d8b8d]
|
|
1479
|
+
- Updated dependencies [4b5bb95]
|
|
1480
|
+
- Updated dependencies [b652514]
|
|
1481
|
+
- Updated dependencies [adbda1b]
|
|
1482
|
+
- Updated dependencies [adbda1b]
|
|
1483
|
+
- Updated dependencies [e2b3826]
|
|
1484
|
+
- Updated dependencies [2e32ed4]
|
|
1485
|
+
- Updated dependencies [3ed3eec]
|
|
1486
|
+
- Updated dependencies [7c3df8f]
|
|
1487
|
+
- Updated dependencies [b9f5ff1]
|
|
1488
|
+
- Updated dependencies [e75f4c9]
|
|
1489
|
+
- Updated dependencies [19f1639]
|
|
1490
|
+
- Updated dependencies [4704aa4]
|
|
1491
|
+
- Updated dependencies [47547d0]
|
|
1492
|
+
- Updated dependencies [1bee5d0]
|
|
1493
|
+
- Updated dependencies [858cd72]
|
|
1494
|
+
- Updated dependencies [cfc9b6d]
|
|
1495
|
+
- Updated dependencies [554f2b6]
|
|
1496
|
+
- Updated dependencies [72f55c9]
|
|
1497
|
+
- Updated dependencies [26e06d7]
|
|
1498
|
+
- Updated dependencies [669d71b]
|
|
1499
|
+
- Updated dependencies [ed27d7c]
|
|
1500
|
+
- Updated dependencies [52c8cf7]
|
|
1501
|
+
- Updated dependencies [2ceb43a]
|
|
1502
|
+
- Updated dependencies [7cdd2b9]
|
|
1503
|
+
- Updated dependencies [52c8cf7]
|
|
1504
|
+
- Updated dependencies [71a4a53]
|
|
1505
|
+
- Updated dependencies [7bf244b]
|
|
1506
|
+
- Updated dependencies [f0bb9fa]
|
|
1507
|
+
- Updated dependencies [81a2eb1]
|
|
1508
|
+
- Updated dependencies [caa0cd3]
|
|
1509
|
+
- Updated dependencies [caa0cd3]
|
|
1510
|
+
- Updated dependencies [25c7d58]
|
|
1511
|
+
- Updated dependencies [00d2fa6]
|
|
1512
|
+
- Updated dependencies [c6198c2]
|
|
1513
|
+
- Updated dependencies [721d1e0]
|
|
1514
|
+
- Updated dependencies [1237ae4]
|
|
1515
|
+
- Updated dependencies [2f61238]
|
|
1516
|
+
- Updated dependencies [51eb515]
|
|
1517
|
+
- Updated dependencies [c354ce5]
|
|
1518
|
+
- Updated dependencies [8fe8e5c]
|
|
1519
|
+
- Updated dependencies [feac439]
|
|
1520
|
+
- Updated dependencies [9ae871d]
|
|
1521
|
+
- Updated dependencies [efbd566]
|
|
1522
|
+
- Updated dependencies [9587fc9]
|
|
1523
|
+
- Updated dependencies [e62c44e]
|
|
1524
|
+
- Updated dependencies [daf9d57]
|
|
1525
|
+
- Updated dependencies [c15d7ec]
|
|
1526
|
+
- Updated dependencies [5d0876c]
|
|
1527
|
+
- Updated dependencies [f7ace0a]
|
|
1528
|
+
- Updated dependencies [b041b9c]
|
|
1529
|
+
- Updated dependencies [ce2aaef]
|
|
1530
|
+
- Updated dependencies [544ecba]
|
|
1531
|
+
- Updated dependencies [2ce2612]
|
|
1532
|
+
- Updated dependencies [bc640ec]
|
|
1533
|
+
- Updated dependencies [1e215c4]
|
|
1534
|
+
- Updated dependencies [da6e191]
|
|
1535
|
+
- Updated dependencies [3e377c9]
|
|
1536
|
+
- Updated dependencies [a3eb5d0]
|
|
1537
|
+
- Updated dependencies [4ce14f1]
|
|
1538
|
+
- Updated dependencies [aef97e5]
|
|
1539
|
+
- Updated dependencies [2af1fa7]
|
|
1540
|
+
- Updated dependencies [c14d3a0]
|
|
1541
|
+
- Updated dependencies [a137d0c]
|
|
1542
|
+
- Updated dependencies [caf477f]
|
|
1543
|
+
- Updated dependencies [f6375da]
|
|
1544
|
+
- Updated dependencies [967e5d8]
|
|
1545
|
+
- Updated dependencies [a4611b3]
|
|
1546
|
+
- Updated dependencies [20316ba]
|
|
1547
|
+
- Updated dependencies [d3499b3]
|
|
1548
|
+
- Updated dependencies [309c75e]
|
|
1549
|
+
- Updated dependencies [c9f9bae]
|
|
1550
|
+
- Updated dependencies [18897a4]
|
|
1551
|
+
- Updated dependencies [8b7ea39]
|
|
1552
|
+
- Updated dependencies [dcbf0b2]
|
|
1553
|
+
- Updated dependencies [52cac38]
|
|
1554
|
+
- Updated dependencies [93fea2e]
|
|
1555
|
+
- Updated dependencies [1422a92]
|
|
1556
|
+
- Updated dependencies [d05fe17]
|
|
1557
|
+
- Updated dependencies [a480f79]
|
|
1558
|
+
- Updated dependencies [f08d1a8]
|
|
1559
|
+
- Updated dependencies [64a252d]
|
|
1560
|
+
- Updated dependencies [786bc91]
|
|
1561
|
+
- Updated dependencies [75fca96]
|
|
1562
|
+
- Updated dependencies [7ca6ddd]
|
|
1563
|
+
- Updated dependencies [f1cd290]
|
|
1564
|
+
- Updated dependencies [5a41ce7]
|
|
1565
|
+
- Updated dependencies [8d50bc2]
|
|
1566
|
+
- Updated dependencies [604476d]
|
|
1567
|
+
- Updated dependencies [d1bebb0]
|
|
1568
|
+
- Updated dependencies [95bf128]
|
|
1569
|
+
- Updated dependencies [335abea]
|
|
1570
|
+
- Updated dependencies [edea22a]
|
|
1571
|
+
- Updated dependencies [0f5cadf]
|
|
1572
|
+
- Updated dependencies [4f9f1ee]
|
|
1573
|
+
- Updated dependencies [66e8b2a]
|
|
1574
|
+
- Updated dependencies [aa083cd]
|
|
1575
|
+
- Updated dependencies [12b5992]
|
|
1576
|
+
- Updated dependencies [b93e245]
|
|
1577
|
+
- Updated dependencies [c842594]
|
|
1578
|
+
- Updated dependencies [290de37]
|
|
1579
|
+
- Updated dependencies [8c8da45]
|
|
1580
|
+
- Updated dependencies [8cd8eb5]
|
|
1581
|
+
- Updated dependencies [cf1d29e]
|
|
1582
|
+
- Updated dependencies [1bd79c8]
|
|
1583
|
+
- Updated dependencies [af9e957]
|
|
1584
|
+
- Updated dependencies [b1030c7]
|
|
1585
|
+
- Updated dependencies [c974edf]
|
|
1586
|
+
- Updated dependencies [ad852b6]
|
|
1587
|
+
- Updated dependencies [7fb22a1]
|
|
1588
|
+
- Updated dependencies [ad66d79]
|
|
1589
|
+
- Updated dependencies [ee4d19f]
|
|
1590
|
+
- Updated dependencies [496d31d]
|
|
1591
|
+
- Updated dependencies [0ea7054]
|
|
1592
|
+
- Updated dependencies [9a853f2]
|
|
1593
|
+
- Updated dependencies [cb847fd]
|
|
1594
|
+
- Updated dependencies [ee70287]
|
|
1595
|
+
- Updated dependencies [3e98e13]
|
|
1596
|
+
- Updated dependencies [fc32921]
|
|
1597
|
+
- Updated dependencies [4eaa835]
|
|
1598
|
+
- Updated dependencies [8f9d87a]
|
|
1599
|
+
- Updated dependencies [b1777ae]
|
|
1600
|
+
- Updated dependencies [24845c4]
|
|
1601
|
+
- Updated dependencies [6f864cf]
|
|
1602
|
+
- Updated dependencies [24d1edd]
|
|
1603
|
+
- Updated dependencies [645087c]
|
|
1604
|
+
- Updated dependencies [33f4a19]
|
|
1605
|
+
- Updated dependencies [4a292d2]
|
|
1606
|
+
- Updated dependencies [5323168]
|
|
1607
|
+
- Updated dependencies [841dd2b]
|
|
1608
|
+
- Updated dependencies [3014fc0]
|
|
1609
|
+
- Updated dependencies [dacb402]
|
|
1610
|
+
- Updated dependencies [846cec0]
|
|
1611
|
+
- Updated dependencies [91facae]
|
|
1612
|
+
- Updated dependencies [b38014e]
|
|
1613
|
+
- Updated dependencies [474797d]
|
|
1614
|
+
- Updated dependencies [704e695]
|
|
1615
|
+
- Updated dependencies [a407bd6]
|
|
1616
|
+
- Updated dependencies [317dbce]
|
|
1617
|
+
- Updated dependencies [3a43a15]
|
|
1618
|
+
- Updated dependencies [868e825]
|
|
1619
|
+
- Updated dependencies [f76f436]
|
|
1620
|
+
- Updated dependencies [ce45a03]
|
|
1621
|
+
- Updated dependencies [421544b]
|
|
1622
|
+
- Updated dependencies [fb01022]
|
|
1623
|
+
- Updated dependencies [e9d9212]
|
|
1624
|
+
- Updated dependencies [ecfb693]
|
|
1625
|
+
- Updated dependencies [abc1b18]
|
|
1626
|
+
- Updated dependencies [81a51db]
|
|
1627
|
+
- Updated dependencies [67749c7]
|
|
1628
|
+
- Updated dependencies [507b61b]
|
|
1629
|
+
- Updated dependencies [512c84b]
|
|
1630
|
+
- Updated dependencies [c300267]
|
|
1631
|
+
- Updated dependencies [fb3a101]
|
|
1632
|
+
- Updated dependencies [d4733f2]
|
|
1633
|
+
- Updated dependencies [1570eac]
|
|
1634
|
+
- Updated dependencies [f391ede]
|
|
1635
|
+
- Updated dependencies [f5cfbbd]
|
|
1636
|
+
- Updated dependencies [f5cfbbd]
|
|
1637
|
+
- Updated dependencies [8b532cb]
|
|
1638
|
+
- Updated dependencies [64c3cdd]
|
|
1639
|
+
- Updated dependencies [4d65991]
|
|
1640
|
+
- Updated dependencies [c42554e]
|
|
1641
|
+
- Updated dependencies [555b4ec]
|
|
1642
|
+
- Updated dependencies [1ccfc23]
|
|
1643
|
+
- Updated dependencies [542718f]
|
|
1644
|
+
- Updated dependencies [7f27bc5]
|
|
1645
|
+
- Updated dependencies [0a174f3]
|
|
1646
|
+
- Updated dependencies [f95b140]
|
|
1647
|
+
- Updated dependencies [541ce4e]
|
|
1648
|
+
- Updated dependencies [6479086]
|
|
1649
|
+
- Updated dependencies [d79f525]
|
|
1650
|
+
- Updated dependencies [d1865d2]
|
|
1651
|
+
- Updated dependencies [f1190b0]
|
|
1652
|
+
- Updated dependencies [561abef]
|
|
1653
|
+
- Updated dependencies [6a4680b]
|
|
1654
|
+
- Updated dependencies [c3a4273]
|
|
1655
|
+
- Updated dependencies [abf710d]
|
|
1656
|
+
- Updated dependencies [093af32]
|
|
1657
|
+
- Updated dependencies [1bd1be7]
|
|
1658
|
+
- Updated dependencies [d234fa9]
|
|
1659
|
+
- Updated dependencies [adf5812]
|
|
1660
|
+
- Updated dependencies [e36acd4]
|
|
1661
|
+
- Updated dependencies [5058336]
|
|
1662
|
+
- Updated dependencies [2f6b2bf]
|
|
1663
|
+
- Updated dependencies [2028b31]
|
|
1664
|
+
- Updated dependencies [63601ab]
|
|
1665
|
+
- Updated dependencies [c372b29]
|
|
1666
|
+
- Updated dependencies [152f0a7]
|
|
1667
|
+
- Updated dependencies [8693b85]
|
|
1668
|
+
- Updated dependencies [e82dad1]
|
|
1669
|
+
- Updated dependencies [58b7b3d]
|
|
1670
|
+
- Updated dependencies [84defab]
|
|
1671
|
+
- Updated dependencies [681d3f1]
|
|
1672
|
+
- Updated dependencies [969d4f2]
|
|
1673
|
+
- Updated dependencies [f3bc481]
|
|
1674
|
+
- Updated dependencies [b79aac2]
|
|
1675
|
+
- Updated dependencies [93fc0e7]
|
|
1676
|
+
- Updated dependencies [a4b723f]
|
|
1677
|
+
- Updated dependencies [2b10ca0]
|
|
1678
|
+
- Updated dependencies [7db4a81]
|
|
1679
|
+
- Updated dependencies [19a0b0e]
|
|
1680
|
+
- Updated dependencies [526fc11]
|
|
1681
|
+
- Updated dependencies [f8e3e9a]
|
|
1682
|
+
- Updated dependencies [b9d47ec]
|
|
1683
|
+
- Updated dependencies [3b6bc69]
|
|
1684
|
+
- Updated dependencies [6214db6]
|
|
1685
|
+
- Updated dependencies [6732df4]
|
|
1686
|
+
- Updated dependencies [fe9e0d0]
|
|
1687
|
+
- Updated dependencies [63fb72c]
|
|
1688
|
+
- Updated dependencies [804831c]
|
|
1689
|
+
- Updated dependencies [279e48e]
|
|
1690
|
+
- Updated dependencies [8700d6d]
|
|
1691
|
+
- Updated dependencies [8db2a0f]
|
|
1692
|
+
- Updated dependencies [689953a]
|
|
1693
|
+
- Updated dependencies [30443fb]
|
|
1694
|
+
- Updated dependencies [8d3dbb2]
|
|
1695
|
+
- Updated dependencies [efc1c9c]
|
|
1696
|
+
- Updated dependencies [da45e6b]
|
|
1697
|
+
- Updated dependencies [7533465]
|
|
1698
|
+
- Updated dependencies [835f0f3]
|
|
1699
|
+
- Updated dependencies [a9d97be]
|
|
1700
|
+
- Updated dependencies [ed35b44]
|
|
1701
|
+
- Updated dependencies [9ba7e9c]
|
|
1702
|
+
- Updated dependencies [729e851]
|
|
1703
|
+
- Updated dependencies [96919a4]
|
|
1704
|
+
- Updated dependencies [345e24a]
|
|
1705
|
+
- Updated dependencies [20b507a]
|
|
1706
|
+
- Updated dependencies [2e471dc]
|
|
1707
|
+
- Updated dependencies [6748587]
|
|
1708
|
+
- Updated dependencies [be50942]
|
|
1709
|
+
- Updated dependencies [775e079]
|
|
1710
|
+
- Updated dependencies [7e8b3c0]
|
|
1711
|
+
- Updated dependencies [53374dc]
|
|
1712
|
+
- Updated dependencies [f6fb83f]
|
|
1713
|
+
- Updated dependencies [2049b03]
|
|
1714
|
+
- Updated dependencies [7cbc724]
|
|
1715
|
+
- Updated dependencies [7098eed]
|
|
1716
|
+
- Updated dependencies [3df7c5c]
|
|
1717
|
+
- Updated dependencies [fb91ac9]
|
|
1718
|
+
- Updated dependencies [fb91ac9]
|
|
1719
|
+
- Updated dependencies [641fb55]
|
|
1720
|
+
- Updated dependencies [8524372]
|
|
1721
|
+
- Updated dependencies [7cbefa5]
|
|
1722
|
+
- Updated dependencies [72d6587]
|
|
1723
|
+
- Updated dependencies [a272a4f]
|
|
1724
|
+
- Updated dependencies [55f39ee]
|
|
1725
|
+
- Updated dependencies [0ce32d5]
|
|
1726
|
+
- Updated dependencies [0970a0e]
|
|
1727
|
+
- Updated dependencies [e427e9c]
|
|
1728
|
+
- Updated dependencies [bbc9dc3]
|
|
1729
|
+
- Updated dependencies [02f1813]
|
|
1730
|
+
- Updated dependencies [1ef89c0]
|
|
1731
|
+
- Updated dependencies [ba0b61a]
|
|
1732
|
+
- Updated dependencies [ba0b61a]
|
|
1733
|
+
- Updated dependencies [ac716ff]
|
|
1734
|
+
- Updated dependencies [f0f3cd5]
|
|
1735
|
+
- Updated dependencies [ab856ed]
|
|
1736
|
+
- Updated dependencies [20f3e65]
|
|
1737
|
+
- Updated dependencies [bbba098]
|
|
1738
|
+
- Updated dependencies [87af769]
|
|
1739
|
+
- Updated dependencies [3be720e]
|
|
1740
|
+
- Updated dependencies [43c0d17]
|
|
1741
|
+
- Updated dependencies [c3df43a]
|
|
1742
|
+
- Updated dependencies [d16d0e9]
|
|
1743
|
+
- Updated dependencies [bbe57fd]
|
|
1744
|
+
- Updated dependencies [272a530]
|
|
1745
|
+
- Updated dependencies [1779e8d]
|
|
1746
|
+
- Updated dependencies [f7fcc2c]
|
|
1747
|
+
- Updated dependencies [f0f4d6c]
|
|
1748
|
+
- Updated dependencies [4128188]
|
|
1749
|
+
- Updated dependencies [b253c4e]
|
|
1750
|
+
- Updated dependencies [78a9c67]
|
|
1751
|
+
- Updated dependencies [4a7ef0d]
|
|
1752
|
+
- Updated dependencies [4598f6d]
|
|
1753
|
+
- Updated dependencies [dea17b4]
|
|
1754
|
+
- Updated dependencies [89bb77a]
|
|
1755
|
+
- Updated dependencies [06611e4]
|
|
1756
|
+
- Updated dependencies [3939545]
|
|
1757
|
+
- Updated dependencies [66abbde]
|
|
1758
|
+
- Updated dependencies [dc3893d]
|
|
1759
|
+
- Updated dependencies [1bbaa16]
|
|
1760
|
+
- Updated dependencies [6ee259a]
|
|
1761
|
+
- Updated dependencies [7649f43]
|
|
1762
|
+
- Updated dependencies [e708426]
|
|
1763
|
+
- Updated dependencies [3b6d53b]
|
|
1764
|
+
- Updated dependencies [276d174]
|
|
1765
|
+
- Updated dependencies [2982ed9]
|
|
1766
|
+
- Updated dependencies [a8198de]
|
|
1767
|
+
- Updated dependencies [0c789a4]
|
|
1768
|
+
- Updated dependencies [05a49f2]
|
|
1769
|
+
- Updated dependencies [b234a84]
|
|
1770
|
+
- Updated dependencies [a78cd37]
|
|
1771
|
+
- Updated dependencies [5ea623e]
|
|
1772
|
+
- Updated dependencies [5eabe86]
|
|
1773
|
+
- Updated dependencies [ca5d671]
|
|
1774
|
+
- Updated dependencies [32bf2d6]
|
|
1775
|
+
- Updated dependencies [ff0c384]
|
|
1776
|
+
- Updated dependencies [af4fb29]
|
|
1777
|
+
- Updated dependencies [ff5ef1c]
|
|
1778
|
+
- Updated dependencies [befd40c]
|
|
1779
|
+
- Updated dependencies [9a97800]
|
|
1780
|
+
- Updated dependencies [6bca0e4]
|
|
1781
|
+
- Updated dependencies [81c0bc4]
|
|
1782
|
+
- Updated dependencies [3c76801]
|
|
1783
|
+
- Updated dependencies [60500cb]
|
|
1784
|
+
- Updated dependencies [2fcefb9]
|
|
1785
|
+
- Updated dependencies [b55a346]
|
|
1786
|
+
- Updated dependencies [065bba7]
|
|
1787
|
+
- Updated dependencies [dd19463]
|
|
1788
|
+
- Updated dependencies [6791717]
|
|
1789
|
+
- Updated dependencies [100547e]
|
|
1790
|
+
- Updated dependencies [6d1c155]
|
|
1791
|
+
- Updated dependencies [d7573b3]
|
|
1792
|
+
- Updated dependencies [bf3edfe]
|
|
1793
|
+
- Updated dependencies [2c8474c]
|
|
1794
|
+
- Updated dependencies [0e05aac]
|
|
1795
|
+
- Updated dependencies [ae61ad4]
|
|
1796
|
+
- Updated dependencies [5aed9e4]
|
|
1797
|
+
- Updated dependencies [83c77dc]
|
|
1798
|
+
- Updated dependencies [3c9fca3]
|
|
1799
|
+
- Updated dependencies [18a8e7d]
|
|
1800
|
+
- Updated dependencies [e7957ab]
|
|
1801
|
+
- Updated dependencies [f7e34ca]
|
|
1802
|
+
- Updated dependencies [e719ebd]
|
|
1803
|
+
- Updated dependencies [516583b]
|
|
1804
|
+
- Updated dependencies [f9e4f91]
|
|
1805
|
+
- Updated dependencies [6ef48b1]
|
|
1806
|
+
- Updated dependencies [fa429cf]
|
|
1807
|
+
- Updated dependencies [ed8df3e]
|
|
1808
|
+
- Updated dependencies [fe76ece]
|
|
1809
|
+
- Updated dependencies [8b446f5]
|
|
1810
|
+
- Updated dependencies [8e74b27]
|
|
1811
|
+
- Updated dependencies [7102b20]
|
|
1812
|
+
- Updated dependencies [8ebd57f]
|
|
1813
|
+
- Updated dependencies [617707a]
|
|
1814
|
+
- Updated dependencies [58770f3]
|
|
1815
|
+
- Updated dependencies [aefe428]
|
|
1816
|
+
- Updated dependencies [485f096]
|
|
1817
|
+
- Updated dependencies [7357447]
|
|
1818
|
+
- Updated dependencies [199d31b]
|
|
1819
|
+
- Updated dependencies [b655a9d]
|
|
1820
|
+
- Updated dependencies [3e01cb5]
|
|
1821
|
+
- Updated dependencies [7138bc1]
|
|
1822
|
+
- Updated dependencies [cef27e2]
|
|
1823
|
+
- Updated dependencies [4e8622b]
|
|
1824
|
+
- Updated dependencies [dffd752]
|
|
1825
|
+
- Updated dependencies [06973aa]
|
|
1826
|
+
- Updated dependencies [50798f3]
|
|
1827
|
+
- Updated dependencies [105f3c5]
|
|
1828
|
+
- Updated dependencies [3ccd9e8]
|
|
1829
|
+
- Updated dependencies [689b979]
|
|
1830
|
+
- Updated dependencies [c70f865]
|
|
1831
|
+
- Updated dependencies [e546222]
|
|
1832
|
+
- Updated dependencies [fd13f52]
|
|
1833
|
+
- Updated dependencies [d7bd274]
|
|
1834
|
+
- Updated dependencies [98c3a74]
|
|
1835
|
+
- Updated dependencies [ebce5a3]
|
|
1836
|
+
- Updated dependencies [fb336df]
|
|
1837
|
+
- Updated dependencies [4dc80d0]
|
|
1838
|
+
- Updated dependencies [9d9040d]
|
|
1839
|
+
- Updated dependencies [0fce2ef]
|
|
1840
|
+
- Updated dependencies [42df928]
|
|
1841
|
+
- Updated dependencies [0e2ddd4]
|
|
1842
|
+
- Updated dependencies [b7479ab]
|
|
1843
|
+
- Updated dependencies [9850c6e]
|
|
1844
|
+
- Updated dependencies [b2ea297]
|
|
1845
|
+
- Updated dependencies [5b5a5c3]
|
|
1846
|
+
- Updated dependencies [14582b8]
|
|
1847
|
+
- Updated dependencies [51e144e]
|
|
1848
|
+
- Updated dependencies [ab92940]
|
|
1849
|
+
- Updated dependencies [a691c0b]
|
|
1850
|
+
- Updated dependencies [0b1326d]
|
|
1851
|
+
- Updated dependencies [af3861f]
|
|
1852
|
+
- Updated dependencies [2609812]
|
|
1853
|
+
- Updated dependencies [515f171]
|
|
1854
|
+
- Updated dependencies [1f4e029]
|
|
1855
|
+
- Updated dependencies [4f14ad7]
|
|
1856
|
+
- Updated dependencies [258d264]
|
|
1857
|
+
- Updated dependencies [cac64b3]
|
|
1858
|
+
- Updated dependencies [8033ad1]
|
|
1859
|
+
- Updated dependencies [fa140b8]
|
|
1860
|
+
- Updated dependencies [71cba28]
|
|
1861
|
+
- Updated dependencies [190fbd0]
|
|
1862
|
+
- Updated dependencies [c00bf28]
|
|
1863
|
+
- Updated dependencies [93127bd]
|
|
1864
|
+
- Updated dependencies [f2158ec]
|
|
1865
|
+
- Updated dependencies [759606e]
|
|
1866
|
+
- Updated dependencies [72ffc34]
|
|
1867
|
+
- Updated dependencies [a51fa0c]
|
|
1868
|
+
- Updated dependencies [51f3d8d]
|
|
1869
|
+
- Updated dependencies [bf28341]
|
|
1870
|
+
- Updated dependencies [78cbdb5]
|
|
1871
|
+
- Updated dependencies [b7543a9]
|
|
1872
|
+
- Updated dependencies [6c6cee7]
|
|
1873
|
+
- Updated dependencies [42887e0]
|
|
1874
|
+
- Updated dependencies [83fe6e7]
|
|
1875
|
+
- Updated dependencies [d1ab06f]
|
|
1876
|
+
- Updated dependencies [f90b8fb]
|
|
1877
|
+
- Updated dependencies [91783c4]
|
|
1878
|
+
- Updated dependencies [982885d]
|
|
1879
|
+
- Updated dependencies [dba7d84]
|
|
1880
|
+
- Updated dependencies [ca39427]
|
|
1881
|
+
- Updated dependencies [bd09957]
|
|
1882
|
+
- Updated dependencies [5a07e67]
|
|
1883
|
+
- Updated dependencies [2d36552]
|
|
1884
|
+
- Updated dependencies [45d8288]
|
|
1885
|
+
- Updated dependencies [490f482]
|
|
1886
|
+
- Updated dependencies [27308c5]
|
|
1887
|
+
- Updated dependencies [8689166]
|
|
1888
|
+
- Updated dependencies [c9327c9]
|
|
1889
|
+
- Updated dependencies [920165d]
|
|
1890
|
+
- Updated dependencies [9101be5]
|
|
1891
|
+
- Updated dependencies [f53a8d0]
|
|
1892
|
+
- Updated dependencies [30266cf]
|
|
1893
|
+
- Updated dependencies [968dc1e]
|
|
1894
|
+
- Updated dependencies [57f9b07]
|
|
1895
|
+
- Updated dependencies [3c73d99]
|
|
1896
|
+
- Updated dependencies [d91aed9]
|
|
1897
|
+
- Updated dependencies [ed71d9e]
|
|
1898
|
+
- Updated dependencies [7776fc2]
|
|
1899
|
+
- Updated dependencies [e76634c]
|
|
1900
|
+
- Updated dependencies [c86185e]
|
|
1901
|
+
- Updated dependencies [1170ed1]
|
|
1902
|
+
- Updated dependencies [92814db]
|
|
1903
|
+
- Updated dependencies [4d73b07]
|
|
1904
|
+
- @object-ui/react@17.7.0
|
|
1905
|
+
- @object-ui/core@17.7.0
|
|
1906
|
+
- @object-ui/types@17.7.0
|
|
1907
|
+
- @object-ui/components@17.7.0
|
|
1908
|
+
- @object-ui/permissions@17.7.0
|
|
1909
|
+
|
|
1910
|
+
## 17.6.0
|
|
1911
|
+
|
|
1912
|
+
### Minor Changes
|
|
1913
|
+
|
|
1914
|
+
- 0a73b51: `ObjectView` and `ListView` now flatten a view's `map` block through a
|
|
1915
|
+
whitelist instead of spreading the whole (untyped) block to the top level.
|
|
1916
|
+
|
|
1917
|
+
Both `case 'map'` flatteners used to build the `object-map` schema with
|
|
1918
|
+
`...(options.map || {})` — a raw spread of an untyped bag
|
|
1919
|
+
(`NamedListView.options?: Record<string, any>`), so any key an author wrote in
|
|
1920
|
+
the `map` block reached the top level unfiltered. `ObjectMap`'s own
|
|
1921
|
+
`FlatMapConfigKeys = Omit<ObjectMapConfig, 'style'>` declares `style` OUT of
|
|
1922
|
+
this flat form (`style` is also `BaseSchema.style`, inline CSS legal on every
|
|
1923
|
+
node), so the two disagreed about the same shape. `style` was the live
|
|
1924
|
+
specimen: `map: { style: '<url>' }` reached the top level as a CSS-shaped
|
|
1925
|
+
`style` key it was never supposed to carry.
|
|
1926
|
+
|
|
1927
|
+
Behavior narrowing, stated because it changes what reaches the flattened
|
|
1928
|
+
schema: a `map` block key that is not one of `ObjectMapConfig`'s declared
|
|
1929
|
+
flat keys (`latitudeField` / `longitudeField` / `locationField` / `titleField`
|
|
1930
|
+
/ `descriptionField` / `zoom` / `center`) — including `style` — no longer
|
|
1931
|
+
reaches the top level of the flattened `object-map` schema. This closes a gap
|
|
1932
|
+
rather than removing working behavior: the pinned strict spec view schemas
|
|
1933
|
+
accept no `map` block at all today, so no author-facing surface could reach
|
|
1934
|
+
this path, and `ObjectMap` already stopped reading a top-level `style` as a
|
|
1935
|
+
map style (a dev warning names the correct spelling instead).
|
|
1936
|
+
|
|
1937
|
+
The whitelist is DERIVED from `ObjectMapConfigSchema` (`@object-ui/types/zod`)
|
|
1938
|
+
rather than hand-listed, so the flatteners and the declaration cannot drift
|
|
1939
|
+
apart again — a key added to (or removed from) the schema reaches both
|
|
1940
|
+
flatteners without a second edit. `ObjectMap`'s own `FLAT_MAP_CONFIG_KEYS` is
|
|
1941
|
+
derived from the same schema for the same reason.
|
|
1942
|
+
- 578e025: `ObjectMapSchema` declares what ObjectMap reads, and the `map` block outranks the flat spelling
|
|
1943
|
+
|
|
1944
|
+
`object-map` carried three disagreeing shapes for one component. The declared face
|
|
1945
|
+
(`ObjectMapSchema`) had four keys — `type`, `objectName`, `locationField`,
|
|
1946
|
+
`titleField`, `mapStyle`. The renderer read about fifteen. And `ObjectMapProps.schema`
|
|
1947
|
+
was typed `ObjectGridSchema`, so every map-specific read went through
|
|
1948
|
+
`(schema as any)`. A TypeScript author could not write the `map` block the docs teach,
|
|
1949
|
+
and misspelling `latitudeField` as `latitudeFieId` was caught by nothing: the map
|
|
1950
|
+
rendered empty and looked like bad data.
|
|
1951
|
+
|
|
1952
|
+
Declared now, each with a read site in `ObjectMap.tsx`: `data`, `staticData`, `filter`,
|
|
1953
|
+
`sort`, `map`, `enableClustering`, `navigation`. `ObjectMapConfig` (interface) and
|
|
1954
|
+
`ObjectMapConfigSchema` (zod) are lifted out of `plugin-map`, where the zod was
|
|
1955
|
+
package-private and called `MapConfigSchema`, into `@object-ui/types` and
|
|
1956
|
+
`@object-ui/types/zod` — so the declared authoring face and the validation the renderer
|
|
1957
|
+
performs are one schema rather than two that can drift. The `Object` prefix is not
|
|
1958
|
+
decoration: `@objectstack/spec/automation` already exports `MapConfigSchema` for an
|
|
1959
|
+
unrelated concept, and a local declaration under a spec export's name is what
|
|
1960
|
+
`check:spec-symbols` exists to refuse. `ObjectMapProps.schema` is `ObjectMapSchema`, and the `as any` map reads
|
|
1961
|
+
are gone.
|
|
1962
|
+
|
|
1963
|
+
Behavior change, ruled by the maintainer on objectui#5018 (2026-08-17): the `map` block
|
|
1964
|
+
is the author face and the flat top-level spelling (`schema.latitudeField`, …) is the
|
|
1965
|
+
internal form ObjectView / ListView produce when they flatten `options.map`. When a
|
|
1966
|
+
schema carries both, **the `map` block now wins** — the reverse of the previous order,
|
|
1967
|
+
under which the flatten product silently shadowed an authored block — and a dev-mode
|
|
1968
|
+
warning names the top-level keys that were ignored. The flat spelling stays out of the
|
|
1969
|
+
declared surface and out of the docs.
|
|
1970
|
+
|
|
1971
|
+
Nothing changes for views built by ObjectView / ListView: both flatteners emit the flat
|
|
1972
|
+
keys and no `map` key at all, so the branch the flip reorders is never reached for their
|
|
1973
|
+
output. That property is now pinned rather than assumed
|
|
1974
|
+
(`plugin-view/src/__tests__/ObjectView.mapFlatten.test.tsx`).
|
|
1975
|
+
|
|
1976
|
+
Bound worth stating, because it limits what the typed surface can promise: `BaseSchema`
|
|
1977
|
+
carries an index signature (`[key: string]: any`), so a misspelled key at the TOP level
|
|
1978
|
+
still type-checks — for every component schema in the repo. The `map` BLOCK is closed,
|
|
1979
|
+
which is what makes the card's headline typo a compile error.
|
|
1980
|
+
|
|
1981
|
+
### Patch Changes
|
|
1982
|
+
|
|
1983
|
+
- 5edc0c5: `object-gantt` / `object-map` / `object-calendar` no longer drop a sort entry that omits `order`.
|
|
1984
|
+
|
|
1985
|
+
The three blocks each inlined a byte-identical private copy of the `sort` →
|
|
1986
|
+
`$orderby` conversion. That copy required BOTH `field` and `order` on an array
|
|
1987
|
+
entry and silently skipped any entry missing one, so a stored view sorting by
|
|
1988
|
+
`[{ field: 'amount' }]` reached the wire with no ordering at all — the authored
|
|
1989
|
+
sort key was lost, not applied. The same copy already treated the STRING
|
|
1990
|
+
spelling `"amount"` as ascending, so this was an inconsistency between two
|
|
1991
|
+
spellings of one thing rather than deliberate strictness.
|
|
1992
|
+
|
|
1993
|
+
All three now import the shared `convertSortToQueryParams` sink from
|
|
1994
|
+
`@object-ui/core` (introduced by objectstack#7137, already used by
|
|
1995
|
+
`object-timeline` and `record:line_items`), and the private copies are gone —
|
|
1996
|
+
the sink is the repo's only definition. Two behavior changes come with it, both
|
|
1997
|
+
of which make the blocks more faithful to what is already declared rather than
|
|
1998
|
+
more tolerant:
|
|
1999
|
+
|
|
2000
|
+
- An array entry that omits `order` now orders ASCENDING instead of vanishing.
|
|
2001
|
+
That is what `QueryParams.$orderby`'s own member shape
|
|
2002
|
+
(`{ field: string; order?: 'asc' | 'desc' }`) says, and what
|
|
2003
|
+
`@object-ui/data-objectstack`'s `serializeOrderBy` already did with a missing
|
|
2004
|
+
direction.
|
|
2005
|
+
- When nothing orderable was authored, the query now carries no `$orderby` at
|
|
2006
|
+
all instead of an empty object. `{}` is truthy and meant "no ordering" only by
|
|
2007
|
+
accident of the adapter's serializer.
|
|
2008
|
+
|
|
2009
|
+
Reachability, so the size of this is not overstated: `SortConfig.order` and
|
|
2010
|
+
`ElementDataSourceSort.order` are REQUIRED in objectui's own types, so a typed
|
|
2011
|
+
caller could never author the dropped shape. The affected surface is untyped
|
|
2012
|
+
stored view metadata (`ElementSavedView` is a loose record by design) — which is
|
|
2013
|
+
exactly where an order-less entry can arrive today.
|
|
2014
|
+
- 25819c4: A map view now fits its camera to the records it queried, so a view with data never first-paints an empty viewport.
|
|
2015
|
+
|
|
2016
|
+
The initial camera was never derived from the data. The zoom came from
|
|
2017
|
+
`getMapConfig`'s default branch — the branch reached precisely when the author
|
|
2018
|
+
declared nothing — which synthesized `zoom: 10` at the origin, and the fabricated
|
|
2019
|
+
value was indistinguishable from a declared one at the read site. An unconfigured
|
|
2020
|
+
object list view of continent-wide records therefore opened on a ~30km-wide
|
|
2021
|
+
viewport centred on the set's midpoint: no markers anywhere on screen, the
|
|
2022
|
+
records reachable only by zooming out and panning by hand (objectui#4941, seen on
|
|
2023
|
+
the showcase `task` map view, whose ten seeded US-city locations span ~4000km).
|
|
2024
|
+
|
|
2025
|
+
The camera is now the marker set's bounding box, handed to MapLibre as
|
|
2026
|
+
`initialViewState.bounds` so the fit happens against the real container size,
|
|
2027
|
+
with padding and a city-scale zoom ceiling (a single record, or several at one
|
|
2028
|
+
address, fits a zero-width box — unbounded, that answers with a rooftop view of a
|
|
2029
|
+
style whose tiles stop far short of it).
|
|
2030
|
+
|
|
2031
|
+
The box is measured along the **shortest arc** containing every marker, not
|
|
2032
|
+
between the naive longitude extremes. Read as a line rather than a circle, two
|
|
2033
|
+
records two degrees apart across the antimeridian (179 and -179) describe a
|
|
2034
|
+
358-degree box whose centre is their antipode; MapLibre then places the markers in
|
|
2035
|
+
whichever copy of the world is nearest their previous screen position, which is
|
|
2036
|
+
how a fitted-looking camera ends up showing empty ocean with the records sitting
|
|
2037
|
+
on a neighbouring copy.
|
|
2038
|
+
|
|
2039
|
+
Unchanged on purpose: record coordinates are not rescued. The platform's
|
|
2040
|
+
`location` value bounds longitude to [-180, 180], so an out-of-range coordinate is
|
|
2041
|
+
a producer-side defect — such records keep being rejected and counted in the
|
|
2042
|
+
view's "invalid coordinates" notice, and the normalization above is camera
|
|
2043
|
+
arithmetic over already-valid values. No new configuration key was added either:
|
|
2044
|
+
the documented `zoom` / `center` pair of the `map` block is still the only camera
|
|
2045
|
+
declaration, it still wins outright, and declaring one half keeps the other
|
|
2046
|
+
derived (`zoom` alone applies at the records' centre; `center` alone at a
|
|
2047
|
+
continental zoom). An empty result set is not fitted — it opens on the whole
|
|
2048
|
+
world rather than a zoom-10 patch of sea.
|
|
2049
|
+
- 072085d: A map node's top-level `style` is inline CSS again, not a MapLibre style URL.
|
|
2050
|
+
|
|
2051
|
+
`ObjectMap.getMapConfig` resolved the map style from three spellings with the
|
|
2052
|
+
top-level `style` FIRST — `schema.style || schema.mapStyle || schema.map?.style`
|
|
2053
|
+
— but `style` is `BaseSchema.style`, a record of inline CSS properties that
|
|
2054
|
+
every schema node may legally carry. Writing the base face's own
|
|
2055
|
+
`style: { height: '400px' }` on a map node therefore handed that object to
|
|
2056
|
+
MapGL's `mapStyle` prop: it never passed the config `safeParse` (which only ever
|
|
2057
|
+
looked at `schema.map`), so there was no validation and no diagnostic either.
|
|
2058
|
+
|
|
2059
|
+
`@object-ui/types` had already named the map's key `mapStyle` — explicitly "not
|
|
2060
|
+
`style`, to avoid colliding with `BaseSchema.style`" — so the consumer was
|
|
2061
|
+
reading, at top priority, the very name the declaration went out of its way to
|
|
2062
|
+
avoid. The declaration is now what is enforced: the map style comes from
|
|
2063
|
+
`mapStyle` on the schema or `style` inside the declared `map` block, and a
|
|
2064
|
+
top-level `style` is not consumed as a map style in any shape.
|
|
2065
|
+
|
|
2066
|
+
Behaviour change, stated because it is one: a map configured through a top-level
|
|
2067
|
+
`style` URL now renders with the default public demo tiles. That spelling was
|
|
2068
|
+
never documented (the README teaches `map.style`) and no metadata in this repo
|
|
2069
|
+
used it, but it was runtime-reachable one way — `ObjectView` / `ListView`
|
|
2070
|
+
flatten `options.map`'s CONTENTS to the top level, so a view authored with
|
|
2071
|
+
`map: { style: '<url>' }` arrived here as a top-level string. That shape is not
|
|
2072
|
+
spec-authorable (`@objectstack/spec`'s list-view schemas are strict and declare
|
|
2073
|
+
no `map` block at all, so such a view fails validation outright), and it now
|
|
2074
|
+
gets a dev warning naming both surviving spellings rather than silently painting
|
|
2075
|
+
the demo tiles. The object form gets no warning: legal base-face authoring, and
|
|
2076
|
+
dropping it is the fix.
|
|
2077
|
+
- 687bc0c: Fix two pieces of `ObjectMap` state that stopped tracking their source after mount
|
|
2078
|
+
(objectui#5003):
|
|
2079
|
+
|
|
2080
|
+
- **`data` prop threading**: the fetch effect preferred records passed via `props.data`,
|
|
2081
|
+
but `data` was read off the `rest` spread and was not one of the effect's dependencies.
|
|
2082
|
+
A host rendering `<ObjectMap data={[]} .../>` while its own query is in flight, then
|
|
2083
|
+
re-rendering with the resolved rows, kept showing the empty map — the prop changed, the
|
|
2084
|
+
effect never re-ran to notice. `data` is now a declared prop (`data: dataProp`), tracked
|
|
2085
|
+
directly in the effect's dependency array; the whole `rest` object is intentionally
|
|
2086
|
+
**not** added there (it is a fresh object every render, which would refetch on every
|
|
2087
|
+
render instead).
|
|
2088
|
+
- **Clustering zoom seed**: `currentZoom` — what `clusterMarkers` uses for its grid cell
|
|
2089
|
+
size — was seeded with a nominal `mapConfig.zoom || 3` and updated only by `onZoom`.
|
|
2090
|
+
MapLibre applies the initial camera (including a `bounds` fit) via its constructor,
|
|
2091
|
+
before react-map-gl attaches React's event handlers, so no `onZoom` ever fired for that
|
|
2092
|
+
first camera — the seed stayed nominal until the user's first zoom. It is now also
|
|
2093
|
+
seeded from `onLoad`, which fires once the initial camera has settled, so clustering at
|
|
2094
|
+
first paint reflects the camera MapLibre actually applied.
|
|
2095
|
+
|
|
2096
|
+
Both were dormant on the console path (never exercised in the example apps) — see the
|
|
2097
|
+
issue for why — so this ships with dedicated tests exercising the prop-update path and
|
|
2098
|
+
the pre-`onZoom` clustering state directly.
|
|
2099
|
+
- 084155e: Fix the two remaining `object/api/value` claims that objectui#5019 (PR #5162) left
|
|
2100
|
+
behind — its dispatch was scoped to only the "API Provider" section of
|
|
2101
|
+
`content/docs/plugins/plugin-map.mdx`, so the same false claim survived in the Features
|
|
2102
|
+
list and in the `ObjectMap.tsx` file-header JSDoc:
|
|
2103
|
+
|
|
2104
|
+
- `content/docs/plugins/plugin-map.mdx:24` (Features list): "Works seamlessly with
|
|
2105
|
+
object/api/value data providers" → "Works seamlessly with object/value data providers".
|
|
2106
|
+
- `packages/plugin-map/src/ObjectMap.tsx:20` (file-header JSDoc): "Works with
|
|
2107
|
+
object/api/value data providers" → "Works with object/value data providers".
|
|
2108
|
+
|
|
2109
|
+
`provider: 'api'` still hits `console.warn('API provider not yet implemented for
|
|
2110
|
+
ObjectMap')` and returns an empty record set (`ObjectMap.tsx:584`); `endpoint`/`method`
|
|
2111
|
+
have no read point in the package. Implementing the `api` provider is capability
|
|
2112
|
+
expansion and is explicitly out of scope here, same as it was for #5019.
|
|
2113
|
+
|
|
2114
|
+
No runtime behaviour changes — a source comment and a docs line only.
|
|
2115
|
+
- Updated dependencies [88085e3]
|
|
2116
|
+
- Updated dependencies [516663d]
|
|
2117
|
+
- Updated dependencies [460c4d0]
|
|
2118
|
+
- Updated dependencies [0ae27f7]
|
|
2119
|
+
- Updated dependencies [2533ec5]
|
|
2120
|
+
- Updated dependencies [78c0f9a]
|
|
2121
|
+
- Updated dependencies [bbe8b86]
|
|
2122
|
+
- Updated dependencies [8477be5]
|
|
2123
|
+
- Updated dependencies [279fb13]
|
|
2124
|
+
- Updated dependencies [2e82ab2]
|
|
2125
|
+
- Updated dependencies [ad07b65]
|
|
2126
|
+
- Updated dependencies [41f498b]
|
|
2127
|
+
- Updated dependencies [e1d4251]
|
|
2128
|
+
- Updated dependencies [40d3a33]
|
|
2129
|
+
- Updated dependencies [8b9dc62]
|
|
2130
|
+
- Updated dependencies [1184192]
|
|
2131
|
+
- Updated dependencies [a2a9747]
|
|
2132
|
+
- Updated dependencies [a1609a6]
|
|
2133
|
+
- Updated dependencies [53f23bc]
|
|
2134
|
+
- Updated dependencies [c4533dc]
|
|
2135
|
+
- Updated dependencies [be60815]
|
|
2136
|
+
- Updated dependencies [37f6844]
|
|
2137
|
+
- Updated dependencies [93de4f6]
|
|
2138
|
+
- Updated dependencies [2b50261]
|
|
2139
|
+
- Updated dependencies [384f30d]
|
|
2140
|
+
- Updated dependencies [ac600e5]
|
|
2141
|
+
- Updated dependencies [97fba31]
|
|
2142
|
+
- Updated dependencies [232f61a]
|
|
2143
|
+
- Updated dependencies [d374caf]
|
|
2144
|
+
- Updated dependencies [5673576]
|
|
2145
|
+
- Updated dependencies [c1ef923]
|
|
2146
|
+
- Updated dependencies [911ceaa]
|
|
2147
|
+
- Updated dependencies [98eab36]
|
|
2148
|
+
- Updated dependencies [af5e292]
|
|
2149
|
+
- Updated dependencies [3fbbea1]
|
|
2150
|
+
- Updated dependencies [7f96b10]
|
|
2151
|
+
- Updated dependencies [167ec42]
|
|
2152
|
+
- Updated dependencies [616a2a5]
|
|
2153
|
+
- Updated dependencies [0046d8f]
|
|
2154
|
+
- Updated dependencies [f1d4748]
|
|
2155
|
+
- Updated dependencies [b1119ec]
|
|
2156
|
+
- Updated dependencies [9f23d2b]
|
|
2157
|
+
- Updated dependencies [578e025]
|
|
2158
|
+
- Updated dependencies [af025ee]
|
|
2159
|
+
- Updated dependencies [598c89a]
|
|
2160
|
+
- Updated dependencies [4a0bd17]
|
|
2161
|
+
- Updated dependencies [b8b9af4]
|
|
2162
|
+
- Updated dependencies [31676be]
|
|
2163
|
+
- Updated dependencies [8c0d52e]
|
|
2164
|
+
- Updated dependencies [aff10e2]
|
|
2165
|
+
- Updated dependencies [70a774b]
|
|
2166
|
+
- Updated dependencies [9ce096f]
|
|
2167
|
+
- Updated dependencies [e05db88]
|
|
2168
|
+
- Updated dependencies [7458a41]
|
|
2169
|
+
- Updated dependencies [5ffcc14]
|
|
2170
|
+
- Updated dependencies [d971e51]
|
|
2171
|
+
- Updated dependencies [97abb24]
|
|
2172
|
+
- Updated dependencies [deb157a]
|
|
2173
|
+
- Updated dependencies [d2ce342]
|
|
2174
|
+
- Updated dependencies [9695da7]
|
|
2175
|
+
- Updated dependencies [75444e3]
|
|
2176
|
+
- Updated dependencies [58b8346]
|
|
2177
|
+
- Updated dependencies [2d0bd16]
|
|
2178
|
+
- Updated dependencies [dad51e5]
|
|
2179
|
+
- Updated dependencies [1c9c342]
|
|
2180
|
+
- Updated dependencies [787c738]
|
|
2181
|
+
- Updated dependencies [8396656]
|
|
2182
|
+
- Updated dependencies [dbbd38a]
|
|
2183
|
+
- Updated dependencies [93fe362]
|
|
2184
|
+
- Updated dependencies [dfc6975]
|
|
2185
|
+
- Updated dependencies [3cf4de0]
|
|
2186
|
+
- Updated dependencies [c9dc811]
|
|
2187
|
+
- Updated dependencies [144ef9b]
|
|
2188
|
+
- Updated dependencies [138ab04]
|
|
2189
|
+
- Updated dependencies [a0b9e91]
|
|
2190
|
+
- Updated dependencies [99bd015]
|
|
2191
|
+
- @object-ui/types@17.6.0
|
|
2192
|
+
- @object-ui/react@17.6.0
|
|
2193
|
+
- @object-ui/components@17.6.0
|
|
2194
|
+
- @object-ui/core@17.6.0
|
|
2195
|
+
|
|
3
2196
|
## 17.5.0
|
|
4
2197
|
|
|
5
2198
|
### Patch Changes
|