@checkstack/frontend-api 0.5.2 → 0.6.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,77 @@
1
1
  # @checkstack/frontend-api
2
2
 
3
+ ## 0.6.0
4
+
5
+ ### Minor Changes
6
+
7
+ - e2d6f25: feat(automation): connection picker for integration actions + restore Integrations menu
8
+
9
+ Connection-backed automation actions (Jira, Teams, Webex) now render a
10
+ working connection picker plus cascading provider dropdowns in the
11
+ visual editor, and the Integrations entry is back in the user menu.
12
+
13
+ **Contract.** `ActionDefinition` gained an optional
14
+ `connectionProviderId` (and it is surfaced on `ActionInfoSchema` and
15
+ mapped in the `listActions` router). It carries the integration
16
+ provider's fully-qualified id, derived from the provider plugin's own
17
+ `pluginMetadata.pluginId` (never a hardcoded string), so the editor
18
+ knows which provider backs an action's dropdowns and it matches the
19
+ `qualifiedId` the integration provider registry assigns.
20
+
21
+ **Providers.** Jira, Teams and Webex each export
22
+ `*_PROVIDER_LOCAL_ID` / `*_PROVIDER_QUALIFIED_ID`, register their
23
+ provider with the local id, and add a `CONNECTION_OPTIONS`
24
+ (`"connectionOptions"`) resolver name. Their `post_message` /
25
+ issue actions set `connectionProviderId` and expose `connectionId`
26
+ as an `x-options-resolver` dropdown instead of a hidden field.
27
+
28
+ **Frontend bridge.** A new `useConnectionOptionResolvers` hook
29
+ (`@checkstack/automation-frontend`, which now depends on
30
+ `@checkstack/integration-common`) turns an action's
31
+ `x-options-resolver` schema fields into live data: the
32
+ `connectionOptions` resolver lists the provider's connections via
33
+ `listConnections`, and every other resolver name is forwarded to
34
+ `getConnectionOptions` for the selected `connectionId`, passing the
35
+ live form values as `context` for dependent fields. `ProviderActionBody`
36
+ now passes this map to `DynamicForm` (it was previously missing
37
+ entirely, so connection-backed actions had no working dropdowns).
38
+
39
+ **frontend-api.** `usePluginClient` procedures now also expose a typed
40
+ imperative `.call(input)` alongside `.useQuery` / `.useMutation`, for
41
+ async callbacks that cannot host a hook (such as a `DynamicForm`
42
+ options resolver). Additive, non-breaking.
43
+
44
+ **Integrations menu.** Re-added `IntegrationMenuItem` and a new
45
+ `IntegrationsLandingPage`, wired into `integration-frontend` as a list
46
+ route and a `UserMenuItemsSlot` entry under the "Configuration" group.
47
+
48
+ **Action card polish.** The action editor's secondary metadata (id,
49
+ description, failure behaviour) is now grouped into one quiet settings
50
+ panel with consistent small uppercase "eyebrow" labels, so the action's
51
+ own configuration stays the focal point. The raw failure checkbox was
52
+ replaced with the standard `Checkbox` control, and the provider action
53
+ picker / configuration sections gained consistent section headers and a
54
+ divider. The per-step "type" dropdown was removed: an action's kind is
55
+ fixed at creation, so changing it now means adding a new step and
56
+ deleting the old one (avoids the surprising full-config reset that
57
+ switching kinds used to trigger).
58
+
59
+ **Add-step picker.** Adding a step now opens a Home-Assistant-style
60
+ dialog where the operator decides the step type up front: an "Actions"
61
+ tab lists the registered provider actions grouped by category
62
+ (searchable; picking one presets the step's `action`), and a "Blocks"
63
+ tab lists the structural building blocks (choose / parallel / repeat /
64
+ etc.). Because the concrete action is chosen here, the in-card action
65
+ switcher was removed - a step's action is fixed once created. Composite
66
+ blocks now start with an empty child list (filled via the nested
67
+ add-step picker) instead of seeding an unconfigurable empty action.
68
+
69
+ ### Patch Changes
70
+
71
+ - Updated dependencies [6d52276]
72
+ - @checkstack/common@0.12.0
73
+ - @checkstack/signal-common@0.2.5
74
+
3
75
  ## 0.5.2
4
76
 
5
77
  ### Patch Changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@checkstack/frontend-api",
3
- "version": "0.5.2",
3
+ "version": "0.6.0",
4
4
  "license": "Elastic-2.0",
5
5
  "type": "module",
6
6
  "main": "./src/index.ts",
@@ -13,8 +13,8 @@
13
13
  "react": "^18.0.0"
14
14
  },
15
15
  "dependencies": {
16
- "@checkstack/common": "0.10.0",
17
- "@checkstack/signal-common": "0.2.3",
16
+ "@checkstack/common": "0.11.0",
17
+ "@checkstack/signal-common": "0.2.4",
18
18
  "@orpc/client": "^1.13.14",
19
19
  "@orpc/contract": "^1.13.14",
20
20
  "@orpc/react-query": "1.13.4",
@@ -26,7 +26,7 @@
26
26
  "@types/react": "^18.0.0",
27
27
  "typescript": "^5.0.0",
28
28
  "@checkstack/tsconfig": "0.0.7",
29
- "@checkstack/scripts": "0.3.2"
29
+ "@checkstack/scripts": "0.3.3"
30
30
  },
31
31
  "checkstack": {
32
32
  "type": "tooling"
@@ -89,6 +89,12 @@ interface QueryProcedure<TInput, TOutput> {
89
89
  input?: TInput,
90
90
  options?: Omit<UseQueryOptions<TOutput, Error>, "queryKey" | "queryFn">,
91
91
  ) => UseQueryResult<TOutput, Error>;
92
+ /**
93
+ * Imperative one-shot call, outside React Query. Use inside async
94
+ * callbacks that can't host a hook (e.g. a DynamicForm options
95
+ * resolver). Prefer `useQuery` for anything rendered.
96
+ */
97
+ call: (input: TInput) => Promise<TOutput>;
92
98
  }
93
99
 
94
100
  /**
@@ -107,6 +113,12 @@ interface MutationProcedure<TInput, TOutput> {
107
113
  "mutationFn" | "mutationKey"
108
114
  >,
109
115
  ) => UseMutationResult<TOutput, Error, TInput, TContext>;
116
+ /**
117
+ * Imperative one-shot call, outside React Query. Use inside async
118
+ * callbacks that can't host a hook (e.g. a DynamicForm options
119
+ * resolver). Prefer `useMutation` for anything tied to UI lifecycle.
120
+ */
121
+ call: (input: TInput) => Promise<TOutput>;
110
122
  }
111
123
 
112
124
  /**
@@ -355,6 +367,7 @@ function createProcedureHook<TInput, TOutput>(
355
367
  const { onSuccess: _, ...restOptions } = options ?? {};
356
368
  return useMutation({ ...mutationOpts, ...restOptions });
357
369
  },
370
+ call: (input) => proc.call(input),
358
371
  };
359
372
  }
360
373
 
@@ -367,5 +380,6 @@ function createProcedureHook<TInput, TOutput>(
367
380
  // Spread caller options AFTER to ensure they take precedence (e.g., enabled: false)
368
381
  return useQuery({ ...queryOpts, ...options });
369
382
  },
383
+ call: (input) => proc.call(input),
370
384
  };
371
385
  }