@object-ui/data-objectstack 6.2.3 → 7.1.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 CHANGED
@@ -1,5 +1,149 @@
1
1
  # @object-ui/data-objectstack
2
2
 
3
+ ## 7.1.0
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies [677f7ed]
8
+ - Updated dependencies [08c47da]
9
+ - Updated dependencies [a71be60]
10
+ - Updated dependencies [cb03bc3]
11
+ - @object-ui/types@7.1.0
12
+ - @object-ui/core@7.1.0
13
+
14
+ ## 7.0.0
15
+
16
+ ### Minor Changes
17
+
18
+ - 30ee761: feat(studio): surface pending drafts on the package detail (ADR-0033)
19
+
20
+ After an AI builds an app, its objects/views land as drafts bound to the app package — but Studio's active-only browsers hid them, so the package looked empty and there was no obvious way to find what to review/publish.
21
+
22
+ - `MetadataClient.listDrafts({ packageId?, type? })` calls the new `GET /api/v1/meta/_drafts` endpoint, returning pending draft headers (with `packageId`).
23
+ - The package detail sheet (PackagesPage) now shows a **Pending changes** section listing each drafted item, each linking to the existing per-item review/diff (`?review=1`) so the user can publish it. A just-built app package is no longer shown as empty.
24
+
25
+ - 053c948: feat: ADR-0047 — interface pages, visualization switcher, and Airtable-parity filters
26
+
27
+ End-user interface/list pages reach full rendering and authoring parity:
28
+
29
+ - **Spec tabs + visualization switcher** — `ObjectView` now forwards
30
+ `viewDef.tabs` (stored/served but never rendered) and `viewDef.appearance`
31
+ (`allowedVisualizations` whitelist), turning on the dormant `ViewSwitcher` when
32
+ more than one type is whitelisted; effective options = author whitelist ∩
33
+ capability-resolvable types (kanban needs `groupBy`, calendar a date field, …).
34
+ `ListView` accepts the canonical `ViewFilterRule[]` tab-filter shape.
35
+ - **User filters** — render only when `userFilters` is explicitly configured;
36
+ selections (dropdown values + active tab) mirror into `uf_*` URL params and
37
+ restore on load, so filtered lists survive reload and are shareable.
38
+ - **Toolbar polish** — the visualization switcher becomes a compact right-side
39
+ "Grid ▾" dropdown inside the tool cluster (no extra row); filter tabs and
40
+ dropdown filters are mutually exclusive.
41
+ - **Studio authoring** — a usable, schema-driven interface-page inspector
42
+ (collapsible sections honoured, array-of-enum → multi-select, a None/Tabs/
43
+ Dropdown `filter-mode` selector where None maps to ABSENCE of `userFilters`),
44
+ and the Design/Preview tabs render the live list via `InterfaceListPage`
45
+ (including a non-empty grid when the source view is hollow).
46
+
47
+ - 5332639: feat(app-shell): render full object forms (incl. master-detail) in screen-flow wizard steps
48
+
49
+ `FlowRunner` now renders an `object-form` screen step: when the paused screen
50
+ carries `kind: 'object-form'`, it mounts the real `<ObjectForm>` for the named
51
+ object (auto-routing to `MasterDetailForm` for inline child collections),
52
+ prefilled from the step's `defaults`. The form persists itself (atomic
53
+ master-detail batch), then resumes the run with the saved record id bound to the
54
+ step's `idVariable`. `dataSource`/`objects` are threaded through all three
55
+ `FlowRunner` mount points.
56
+
57
+ Also fixes three pre-existing bugs this surfaced (each affects normal forms too):
58
+
59
+ - **plugin-form**: `ObjectForm` now forwards `initialValues`/`initialData` when
60
+ routing to `MasterDetailForm`, so prefilled header values are no longer
61
+ dropped on master-detail create forms.
62
+ - **fields**: `PercentField` treated values as `0–1` fractions (`value × 100`),
63
+ so a `0–100` field (e.g. `probability` default `50`) rendered as `5000%` —
64
+ exceeding `max=100`, which makes HTML5 constraint validation mark the field
65
+ `:invalid` and silently block the whole form's submit. It now treats a field
66
+ declaring `max > 1` as the `0–100` whole-number convention, matching the
67
+ read-side formatter.
68
+ - **data-objectstack**: `ObjectStackAdapter.batchTransaction` now sends
69
+ `credentials: 'include'`, so master-detail batch saves authenticate under the
70
+ console's cookie session (previously every batch save 401'd).
71
+
72
+ - d16566f: Atomic master-detail create via the cross-object transactional batch endpoint (ObjectStack #1604).
73
+
74
+ When the server exposes the transactional batch endpoint, a NEW parent record and its child line items are now persisted in ONE server transaction — commit all or roll back all — instead of the previous client-orchestrated "create parent → create children → best-effort cleanup on failure" sequence.
75
+
76
+ **`@object-ui/data-objectstack` — `ObjectStackAdapter.batchTransaction(operations)`**
77
+
78
+ - New method posting `{ operations }` to `POST /api/v1/batch`. Operations run in one server transaction. A field value of `{ $ref: <earlier op index> }` resolves to that op's generated id, so a child can reference its parent created earlier in the same batch (master-detail FK). Throws `ObjectStackError('BATCH_ERROR')` on a non-2xx response.
79
+
80
+ **`@object-ui/plugin-form`**
81
+
82
+ - `MasterDetailForm` now detects `dataSource.batchTransaction` and, on a NEW parent, builds one atomic batch (parent at index 0, each child FK set to `{ $ref: 0 }`) via the new pure helper `buildMasterDetailBatch`. Client-side total rollups are merged into the parent payload before the batch. Edit mode and adapters without `batchTransaction` keep the existing client-orchestrated path.
83
+ - `ObjectForm` gained a `submitHandler` hook: when supplied, the form validates and hands the collected values to the host instead of calling `dataSource.create` / `dataSource.update`. `MasterDetailForm` uses it to own the atomic parent+children write while the parent fields are still rendered by `ObjectForm`.
84
+
85
+ **`@object-ui/types`**
86
+
87
+ - `ObjectFormSchema.submitHandler?: (values) => any | Promise<any>` — typed override for host-owned persistence.
88
+
89
+ Pairs with the framework-side ambient-transaction fix (ObjectQL `AsyncLocalStorage` transaction propagation) and the `/api/v1/batch` endpoint added in `@objectstack/rest`.
90
+
91
+ ### Patch Changes
92
+
93
+ - b99d9bd: ADR-0048: package-scope the Studio metadata editor read. Two installed packages
94
+ may ship metadata with the same `type`/`name`; the editor now resolves the right
95
+ one instead of first-match.
96
+
97
+ - `MetadataClient`: `layered()` and `getDraft()` accept `{ packageId }`, and
98
+ `get()` emits the `package` query param (→ server prefer-local, `?package=`).
99
+ - `ResourceListPage`: each item's edit link carries its owning package
100
+ (`?package=<row._packageId>`), so even the unscoped "all" list disambiguates;
101
+ falls back to the workspace suffix for runtime/overlay-only rows.
102
+ - `ResourceEditPage`: reads `?package=` and scopes the layered + draft read to
103
+ that package. (The route's `:appName` is the Studio app, not the edited item's
104
+ owner, so the scope must come from the URL, not the active app.)
105
+
106
+ - a58c6b8: fix(datasource): exclude form-family views from `listViews()`
107
+
108
+ `OBJECTSTACKDataSource.listViews(objectName)` feeds the object list-view
109
+ switcher (`ObjectView` → `ViewTabBar`), but returned **every** view bound to
110
+ the object — including form-family ones. With the backend now exposing each
111
+ view as an independent **ViewItem** carrying a `viewKind` discriminant
112
+ (ADR-0017, "Object has-many View"), a form view such as `crm_activity.default`
113
+ (expanded from `formViews.default`) leaked in as a spurious switcher tab and,
114
+ when opened, fell back to the default grid.
115
+
116
+ `listViews()` now filters out `viewKind` `form`/`detail` items so only
117
+ list-family views reach the switcher. Bare view specs without a `viewKind`
118
+ (legacy artifacts and user-saved views) are still treated as list views.
119
+
120
+ - Updated dependencies [5976ba3]
121
+ - Updated dependencies [eaccefd]
122
+ - Updated dependencies [f7f325d]
123
+ - Updated dependencies [c12986e]
124
+ - Updated dependencies [71d7ce0]
125
+ - Updated dependencies [053c948]
126
+ - Updated dependencies [ddbe4a2]
127
+ - Updated dependencies [2d47e94]
128
+ - Updated dependencies [9049bbe]
129
+ - Updated dependencies [cb2fdb1]
130
+ - Updated dependencies [c3749eb]
131
+ - Updated dependencies [6cfa330]
132
+ - Updated dependencies [ad8ade6]
133
+ - Updated dependencies [d54346c]
134
+ - Updated dependencies [3870c20]
135
+ - Updated dependencies [b88c560]
136
+ - Updated dependencies [d16566f]
137
+ - Updated dependencies [1394e34]
138
+ - Updated dependencies [300d755]
139
+ - Updated dependencies [4eb9cb6]
140
+ - Updated dependencies [7c239fd]
141
+ - Updated dependencies [858ad94]
142
+ - Updated dependencies [2270239]
143
+ - Updated dependencies [8d1195d]
144
+ - @object-ui/core@7.0.0
145
+ - @object-ui/types@7.0.0
146
+
3
147
  ## 6.2.3
4
148
 
5
149
  ### Patch Changes