@metabase/client 0.1.0 → 0.1.1

package/CHANGELOG.md

@@ -2,6 +2,27 @@
 
 Notable changes to `@metabase/client`.
 
+## 0.1.1
+
+- `DashboardCreateInput` holds only the fields `POST /api/dashboard` reads, so a layout passed to `dashboard.create` fails to compile; send it as a `DashboardLayoutInput` through `dashboard.update`. At run time `dashboard.create` drops any other key before the request, as the server does, and refuses a blank `name`, as the server does.
+- `DashboardLayoutInput` and `DatabaseUpdateInput` are on the barrel.
+- `@metabase/client/json-pointer` exports `unescapeJsonPointerSegment`, the inverse of `escapeJsonPointerSegment`.
+- `@metabase/client/version/input-gates` exports the input gates recorded on feature-gated body fields, with `gateTriggered` and `inputGatesOf`, and `featureAvailability` says which servers hold a feature.
+- `dataAction.update` refuses a `collection_id` before the request on a server without `dataActionCollections`, which would drop it unread.
+- `dashboard.get` and `dashboard.update` read a dashboard holding a text, heading or other dashcard bound to no card. The server answers a stub `card` such as `{ query_average_duration: null, download_perms: "none" }` for such a dashcard, which 0.1.0 refused; it reads as `null`, and `dashboardDetailSchema` on the dashboard subpath is the reader.
+- A transform's Python `source-tables` entry reads without `database_id` or `schema`, as the server stores an entry whose table or database is gone. `TransformSourceTableEntry` is the stored entry, and `TransformSourceTableEntryInput`, on the barrel, is the entry the create, update and Python test-run bodies take, as strict as before.
+- Every transform read on Metabase 59 accepts a Python transform, whose `source-tables` that server keys by alias. `transformRowSchema` and `transformDetailSchema` read it as the list later servers answer, taking each alias from its key; an entry naming its table by id alone reads `database_id`, `schema` and `table` as `null`, and one whose table that server could not find reads `table_id` as `null` too. `transformSourceTablesAsList` is the feature.
+- The dependency readers accept the action nodes Metabase 65 adds: `DependencyType` and `DependencyUsageType` take `"action"`, and `DependencyEntityData.type` takes an action's `"implicit"` or `"query"`. `dependency.graph`, `dependency.dependents` and `dependency.broken` explain an older server's refusal of an action as the entity through `actionDependencyGraph`.
+- `notification.get`, and the `update`, `archive` and `send` that read through it, refuse a dashboard subscription with the "not a question alert" `ConfigError` instead of a shape error on its payload. `AnyNotification` is the reader: a question alert in full, any other type read no further than `id` and `payload_type`. `CARD_PAYLOAD_TYPE` has the literal type `"notification/card"`.
+- `CurrentUser.email` is any string, so `user.current` reads an account whose address Metabase accepts and a stricter email check refuses, such as one with `!` or `/` in the local part or a digit or one-letter top-level domain.
+- `transform.create`, `transform.update` and `transformPython.testRun` send a Python source's tables keyed by alias to Metabase 58 and 59, which read no list: a transform entry as its reference less `alias`, which 59 reads and 58, taking only table ids, refuses, or as the bare table id when it names its table by id alone, and a test-run entry as its table id. `TransformSourceTableEntryInput` also takes that id-only entry, `{ alias, table_id }` with `database_id`, `schema` and `table` absent or `null`, so a transform read from 59 updates back unchanged. `pythonTestRun` holds from 58 on a server licensed for Python transforms.
+- `SetupInput.user.email` is any string, so `setup.create` hands Metabase an address it accepts and a stricter email check refuses, and the server judges it.
+- `collection.itemPages` walks the `trash` alias on every server. No Metabase routes `/api/collection/trash/items`, so the walk reads the trash collection's id from `GET /api/collection/trash` first and pages its items by that id.
+- `search.query` and `collection.itemPages` explain an older server's 400 for a `models` value it does not take as the feature it lacks: `measure` in search through `measures`, `transform` through `transforms`, `exploration` through the new `explorations`, and among collection items `measure` through the new `collectionItemMeasures`.
+- `collection.itemPages` applies `pinned_state` on Metabase 64 and later, which read it as `pinned-state` and drop the spelling 58 through 63 read.
+- `TransformJobUpdateInput.active` records that it needs `transformJobActivation`; a server before 61 drops it unread and still answers the job as active.
+- `LibraryPublishTablesInput.collection_id` records that only a server with `tablePublishTargetCollection` (62+) reads it; an older one publishes into its one Library data collection. It is sent on every server.
+
 ## 0.1.0
 
 The first published release: the whole surface.

package/README.md

@@ -433,11 +433,13 @@ Unless the caller passes `metadata` from `tryDiscoverMetadata`, which makes the
 
 `Features` is a record of named booleans over `FEATURE_RULES`, the one table that relates a behaviour to the majors and token feature it needs (`FeatureRule`: `{ since, until?, tokenFeature? }`); `evaluateFeatures(major, tokenFeatures)` evaluates it for a `RuleMajor` (a release major, or `"development"` for a build ahead of every release), `FEATURE_NAMES` lists the keys, and `isFeatureName` narrows a string to one. Names describe behaviour (`transformTargetTableId`, `libraryChildrenCarryType`), never a version. Consumers branch on a feature, never on a major — `features.ts` is the only module that compares one.
 
-`METHOD_REQUIREMENTS` names, per client method (`"transform.get"`, `"gitSync.branches"` — the `MethodKey` as the method is reached on the client), the features it needs, strictest first; `methodRequirements(key)` reads one entry, `METHOD_KEYS` lists the keys, and `isMethodKey` narrows a string to one. When a gated method's request fails the way a server rejects what it lacks (a 402 premium refusal, an unrouted 404, or a 400 on a value outside an older enum or a body an older route reads in another shape), the client probes the server and throws a `CapabilityError` when that profile lacks a feature the method needs — a version gate reads `This operation requires Metabase v59+ (this server is v0.58.0). Upgrade Metabase to use it.`, a token gate `This operation requires the 'remote_sync' premium feature (not enabled on this server).` — and the error's `developerDetail` is a `RequirementFailure` carrying `reason`, `detail`, `feature`, `since`, `tokenFeature` and `serverVersion` — a Zod schema as well as a type (with `RequirementReason` for its `reason` enum), so a consumer that reports the refusal in its own output can describe it. A server that turns out to have every feature failed for another reason, and its own error stands. A 400 is also an ordinary validation failure, so it stands as the server's own `HttpError` when its field errors (`fieldErrors`, `specificFieldErrors`) name a field the missing parameter feature does not gate: a `mb.table.update` carrying a tier-named `data_layer` to a server that speaks medallions, alongside another field that server rejects, throws that field's rejection rather than the tier floor. A 400 that names no field, or one from a server lacking a feature the method itself needs, is the refusal. A method that needs nothing never consults the server; a newer release or a development build is placed past the newest known major, so only a token can explain a refusal there. `checkFeatures(features, profile)` is the check itself, over any feature list (`methodRequirements(key)` gives a method's), answering the first feature the profile lacks, and `featureFailures(features, profile)` answers every one, `featureGap(profile, feature)` says which half of a rule the profile fails (`FeatureGap`: `{ kind: "version" }` or `{ kind: "token", tokenFeature }`), and `ruleGap` is the same question asked of a bare rule. A consumer that describes what a server can do — gating a test lane, or filtering prose by the server it targets — reads the same check.
+`METHOD_REQUIREMENTS` names, per client method (`"transform.get"`, `"gitSync.branches"` — the `MethodKey` as the method is reached on the client), the features it needs, strictest first; `methodRequirements(key)` reads one entry, `METHOD_KEYS` lists the keys, and `isMethodKey` narrows a string to one. When a gated method's request fails the way a server rejects what it lacks (a 402 premium refusal, an unrouted 404, or a 400 on a value outside an older enum or a body an older route reads in another shape), the client probes the server and throws a `CapabilityError` when that profile lacks a feature the method needs — a version gate reads `This operation requires Metabase v59+ (this server is v0.58.0). Upgrade Metabase to use it.`, a token gate `This operation requires the 'remote_sync' premium feature (not enabled on this server).` — and the error's `developerDetail` is a `RequirementFailure` carrying `reason`, `detail`, `feature`, `since`, `tokenFeature` and `serverVersion` — a Zod schema as well as a type (with `RequirementReason` for its `reason` enum), so a consumer that reports the refusal in its own output can describe it. A server that turns out to have every feature failed for another reason, and its own error stands. A 400 is also an ordinary validation failure, so it stands as the server's own `HttpError` when its field errors (`fieldErrors`, `specificFieldErrors`) name a field the missing parameter feature does not gate: a `mb.table.update` carrying a tier-named `data_layer` to a server that speaks medallions, alongside another field that server rejects, throws that field's rejection rather than the tier floor. A 400 that names no field, or one from a server lacking a feature the method itself needs, is the refusal. A method that needs nothing never consults the server; a newer release or a development build is placed past the newest known major, so only a token can explain a refusal there. `checkFeatures(features, profile)` is the check itself, over any feature list (`methodRequirements(key)` gives a method's), answering the first feature the profile lacks, and `featureFailures(features, profile)` answers every one, `featureGap(profile, feature)` says which half of a rule the profile fails (`FeatureGap`: `{ kind: "version" }` or `{ kind: "token", tokenFeature }`), and `ruleGap` is the same question asked of a bare rule. `featureAvailability(feature)` says which servers hold a feature, from its rule: `v64+`, or `token dashboard_subscription_filters` when every supported server meets the version floor. A consumer that describes what a server can do — gating a test lane, or filtering prose by the server it targets — reads the same check.
 
-A resource whose wire shape differs between generations exports from its `@metabase/client/domain/<r>` module, beside the canonical schema, a reader that picks the exact schema for a `Features` and converts forward: `transformDetailSchema(features)` and `transformRowSchema(features)` read a `Transform` (the older generations' hydrated `table` on the detail endpoint, and no link on the rest, become `target_table_id`), `fieldDetailSchema(features)` reads a `FieldDetail`, which is a `FieldWithDataSensitivity` (its `data_sensitivity` `null` for an unlabelled field) on a generation with the label and a plain `Field` without the key elsewhere, told apart by `hasDataSensitivity`, `fieldRemappedValueSchema(features, sameField)` reads a `FieldRemappedValue` from the first cells of a row a generation pads with display columns, `transformJobSchema(features)` reads a `TransformJob` whose `active` is `null` on a generation that cannot switch jobs off, `transformJobRunResultSchema(features)` reads a `TransformJobRunResult` (`{ message, started, run_id }` — a stub id is `started: null, run_id: null`, the request accepted and the outcome unsaid; a numeric or null id is `started: id !== null, run_id: id`), and `libraryWireSchema(features)` with `toLibrary(wire, listing)` reads a `Library` whose `LibraryChild` entries carry `type` from the wire where the generation sends it and `is_remote_synced` from the collection listing on every generation (`LibraryCollectionInfo`, `LibraryListing`). Each `null` in a canonical field means "this server cannot say". `ResponseShapeError.developerDetail.serverSkew` carries the profile's `skew`, and a `newer-than-known` server is named as such in the message's lead line.
+Some input fields take a value only some servers accept. `@metabase/client/version/input-gates` records each such field on the input schema that holds it, in a registry of the client's own rather than Zod's global one. `inputGatesOf(schema)` answers the `InputGate` entries recorded on a property node, or `null` when every server takes all its values. A gate names a `feature`, an `effect` (`"needs"`: the server must hold the feature; `"supersededBy"`: a server holding it reads the value as something else; `"droppedBy"`: a server holding it drops the value unread), and the `when` that triggers it (`GateTrigger`: the field `present`, one of `values`, or a `nonEmpty` array). `gateTriggered(gate, value)` says whether a value passed for the field triggers the gate. A `droppedBy` gate is a note and nothing enforces it: `TABLE_FROM_DEFINITION_GATE` on `table_id` of `MeasureCreateInput` and `SegmentCreateInput`, which a server holding `tableFromDefinition` drops, and every server is sent because one without the feature requires it. The domain modules export every other gate as a const the resource enforces it by: `DATA_SENSITIVITY_GATE` on `FieldUpdateInput.data_sensitivity`, `DATA_LAYER_TIER_GATE` and `DATA_LAYER_MEDALLION_GATE` on `TableUpdateInput.data_layer`, `DATA_AUTHORITY_WITHDRAWAL_GATE` on `data_authority` of `TableUpdateInput` and `TableBulkEditInput`, `DATA_ACTION_COLLECTION_GATE` on `DataActionUpdateInput.collection_id`, `SUBSCRIPTION_FILTERS_GATE` on `parameters` of `PulseCreateInput` and `PulseUpdateInput`, and `REVISION_ENTITY_GATES` (`measure`, `transform`, `transform-test`) on `RevisionRevertInput.entity`. A server lacking the feature is refused or explained the way its method's own requirement is.
 
-Types: `ServerInfo`, `ServerProfile`, `ServerVersion`, `ReleaseVersion`, `DevelopmentBuild`, `Skew`, `Edition`, `FeatureName`, `FeatureRule`, `RuleMajor`, `Features`, `FeatureGap`, `VersionGap`, `TokenGap`, `MethodKey`, `RequirementFailure`, `RequirementReason`.
+A resource whose wire shape differs between generations exports from its `@metabase/client/domain/<r>` module, beside the canonical schema, a reader that picks the exact schema for a `Features` and converts forward: `transformDetailSchema(features)` and `transformRowSchema(features)` read a `Transform` (the older generations' hydrated `table` on the detail endpoint, and no link on the rest, become `target_table_id`, and a Python source's `source-tables` keyed by alias becomes the list of `TransformSourceTableEntry`, whose `database_id`, `schema` and `table` are `null` for a table named by id alone; `transform.create`, `transform.update` and `transformPython.testRun` send the list back keyed by alias to such a server, `transformSourceBody(source, features)` and `pythonTestRunBody(params, features)` being the writers), `fieldDetailSchema(features)` reads a `FieldDetail`, which is a `FieldWithDataSensitivity` (its `data_sensitivity` `null` for an unlabelled field) on a generation with the label and a plain `Field` without the key elsewhere, told apart by `hasDataSensitivity`, `fieldRemappedValueSchema(features, sameField)` reads a `FieldRemappedValue` from the first cells of a row a generation pads with display columns, `transformJobSchema(features)` reads a `TransformJob` whose `active` is `null` on a generation that cannot switch jobs off, `transformJobRunResultSchema(features)` reads a `TransformJobRunResult` (`{ message, started, run_id }` — a stub id is `started: null, run_id: null`, the request accepted and the outcome unsaid; a numeric or null id is `started: id !== null, run_id: id`), and `libraryWireSchema(features)` with `toLibrary(wire, listing)` reads a `Library` whose `LibraryChild` entries carry `type` from the wire where the generation sends it and `is_remote_synced` from the collection listing on every generation (`LibraryCollectionInfo`, `LibraryListing`). Each `null` in a canonical field means "this server cannot say". `ResponseShapeError.developerDetail.serverSkew` carries the profile's `skew`, and a `newer-than-known` server is named as such in the message's lead line.
+
+Types: `ServerInfo`, `ServerProfile`, `ServerVersion`, `ReleaseVersion`, `DevelopmentBuild`, `Skew`, `Edition`, `FeatureName`, `FeatureRule`, `RuleMajor`, `Features`, `FeatureGap`, `VersionGap`, `TokenGap`, `MethodKey`, `RequirementFailure`, `RequirementReason`, `InputGate`, `GateEffect`, `GateTrigger`, `PresentTrigger`, `ValuesTrigger`, `NonEmptyTrigger`.
 
 ### Resource schemas
 
@@ -472,7 +474,7 @@ dependency graph's `DependencyFindingError`, the entity relationship diagram's `
 Request bodies (`<Resource>CreateInput`, `<Resource>UpdateInput`, and `MetricDefinition`, the expression
 over metric and measure leaves that `metric.query` and `metric.breakoutValues` run) and the domain vocabulary enums
 (`FieldBaseType`, `SearchModel`, `CollectionItemModel`, …) live in the same modules and are reached
-at `@metabase/client/domain/<resource>`.
+at `@metabase/client/domain/<resource>`. `DashboardCreateInput` holds only the fields `POST /api/dashboard` reads and refuses any other key, so a dashboard's layout (`dashcards`, `tabs`) is a `DashboardLayoutInput`, sent through `dashboard.update` once the dashboard exists.
 
 ### Utilities
 

package/dist/api-key-DJeN1-7G.d.ts

@@ -0,0 +1,46 @@
+import { z } from "zod";
+//#region src/domain/api-key.d.ts
+declare const ApiKey: z.ZodObject<{
+  id: z.ZodNumber;
+  name: z.ZodString;
+  masked_key: z.ZodString;
+  group: z.ZodObject<{
+    id: z.ZodNumber;
+    name: z.ZodString;
+  }, z.core.$loose>;
+  created_at: z.ZodString;
+  updated_at: z.ZodString;
+}, z.core.$loose>;
+type ApiKey = z.infer<typeof ApiKey>;
+declare const ApiKeyCompact: z.ZodObject<{
+  id: z.ZodNumber;
+  name: z.ZodString;
+  masked_key: z.ZodString;
+}, z.core.$strip>;
+type ApiKeyCompact = z.infer<typeof ApiKeyCompact>;
+declare const CreatedApiKey: z.ZodObject<{
+  id: z.ZodNumber;
+  name: z.ZodString;
+  masked_key: z.ZodString;
+  group: z.ZodObject<{
+    id: z.ZodNumber;
+    name: z.ZodString;
+  }, z.core.$loose>;
+  created_at: z.ZodString;
+  updated_at: z.ZodString;
+  unmasked_key: z.ZodString;
+}, z.core.$loose>;
+type CreatedApiKey = z.infer<typeof CreatedApiKey>;
+declare const CreatedApiKeyCompact: z.ZodObject<{
+  id: z.ZodNumber;
+  name: z.ZodString;
+  unmasked_key: z.ZodString;
+}, z.core.$strip>;
+type CreatedApiKeyCompact = z.infer<typeof CreatedApiKeyCompact>;
+declare const ApiKeyCreateInput: z.ZodObject<{
+  name: z.ZodString;
+  group_id: z.ZodNumber;
+}, z.core.$strict>;
+type ApiKeyCreateInput = z.infer<typeof ApiKeyCreateInput>;
+//#endregion
+export { CreatedApiKeyCompact as a, CreatedApiKey as i, ApiKeyCompact as n, ApiKeyCreateInput as r, ApiKey as t };

package/dist/{card-B6merEUN.d.ts → card-BxBzr5Uj.d.ts}

@@ -2,14 +2,14 @@ import { z } from "zod";
 //#region src/domain/card.d.ts
 declare const CardType: z.ZodEnum<{
   metric: "metric";
-  question: "question";
   model: "model";
+  question: "question";
 }>;
 type CardType = z.infer<typeof CardType>;
 declare const CardListFilter: z.ZodEnum<{
+  archived: "archived";
   database: "database";
   table: "table";
-  archived: "archived";
   all: "all";
   mine: "mine";
   bookmarked: "bookmarked";
@@ -279,8 +279,8 @@ declare const Card: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodEnum<{
     metric: "metric";
-    question: "question";
     model: "model";
+    question: "question";
   }>;
   display: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
@@ -321,8 +321,8 @@ declare const CardDetail: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodEnum<{
     metric: "metric";
-    question: "question";
     model: "model";
+    question: "question";
   }>;
   display: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
@@ -699,16 +699,16 @@ type CardDetail = z.infer<typeof CardDetail>;
 declare const CardCompact: z.ZodObject<{
   type: z.ZodEnum<{
     metric: "metric";
-    question: "question";
     model: "model";
+    question: "question";
   }>;
-  name: z.ZodString;
-  database_id: z.ZodNullable<z.ZodNumber>;
   id: z.ZodNumber;
-  collection_id: z.ZodNullable<z.ZodNumber>;
+  name: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
   archived: z.ZodBoolean;
+  collection_id: z.ZodNullable<z.ZodNumber>;
   display: z.ZodString;
+  database_id: z.ZodNullable<z.ZodNumber>;
   dashboard_id: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
 }, z.core.$strip>;
 type CardCompact = z.infer<typeof CardCompact>;
@@ -716,8 +716,8 @@ declare const CardCreateInput: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodOptional<z.ZodNullable<z.ZodEnum<{
     metric: "metric";
-    question: "question";
     model: "model";
+    question: "question";
   }>>>;
   dataset_query: z.ZodObject<{}, z.core.$loose>;
   display: z.ZodString;
@@ -827,8 +827,8 @@ declare const CardUpdateInput: z.ZodObject<{
   name: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   type: z.ZodOptional<z.ZodNullable<z.ZodEnum<{
     metric: "metric";
-    question: "question";
     model: "model";
+    question: "question";
   }>>>;
   dataset_query: z.ZodOptional<z.ZodObject<{}, z.core.$loose>>;
   display: z.ZodOptional<z.ZodNullable<z.ZodString>>;
@@ -838,8 +838,8 @@ declare const CardUpdateInput: z.ZodObject<{
   enable_embedding: z.ZodOptional<z.ZodNullable<z.ZodBoolean>>;
   embedding_type: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   embedding_params: z.ZodOptional<z.ZodNullable<z.ZodRecord<z.ZodString, z.ZodEnum<{
-    disabled: "disabled";
     enabled: "enabled";
+    disabled: "disabled";
     locked: "locked";
   }>>>>;
   collection_id: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;

package/dist/{card-BZx4NSr-.d.ts → card-DN0sLkCG.d.ts}

@@ -1,8 +1,8 @@
-import { a as CardListFilter, i as CardDetail, l as CardUpdateInput, o as CardQueryResult, r as CardCreateInput, t as Card } from "./card-B6merEUN.js";
-import { r as QueryMetadata } from "./dataset-C6lX1-cr.js";
-import { n as ExportFormat } from "./query-Xsin530u.js";
-import { f as RequestOptions, h as Transport } from "./transport-E0ZaPNWJ.js";
+import { f as RequestOptions, h as Transport } from "./transport-BsXqRujn.js";
 import { t as ListResult } from "./list-BT_bBm9Z.js";
+import { a as CardListFilter, i as CardDetail, l as CardUpdateInput, o as CardQueryResult, r as CardCreateInput, t as Card } from "./card-BxBzr5Uj.js";
+import { r as QueryMetadata } from "./dataset-BBNGPVec.js";
+import { n as ExportFormat } from "./query-Xsin530u.js";
 //#region src/resources/card.d.ts
 interface CardListParams {
   f?: CardListFilter | undefined;