@fusebase/fusebase-gate-sdk 2.3.12 → 2.3.13-sdk.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/dist/apis/AppEmbedTargetsApi.d.ts +1 -1
- package/dist/apis/AppEmbedTargetsApi.js +1 -1
- package/dist/types/app-embed-targets/app-embed-targets.d.ts +6 -0
- package/package.json +1 -1
- package/release-notes/2.3.13-sdk.0.md +9 -0
- package/release-notes/latest.md +4 -48
- package/release-notes/2.3.12.md +0 -53
|
@@ -11,7 +11,7 @@ export declare class AppEmbedTargetsApi {
|
|
|
11
11
|
constructor(client: Client);
|
|
12
12
|
/**
|
|
13
13
|
* List an app's portal embeds
|
|
14
|
-
* Returns the portal pages in the organization where the given app is embedded (as an app-feature brick). One entry per page, each with the portal name, page title,
|
|
14
|
+
* Returns the portal pages in the organization where the given app is embedded (as an app-feature brick or via a regular embed/iframe block pointing at the app host). One entry per page, each with the portal name, page title, a ready-to-use page URL, and a `kind` of 'app-feature' or 'iframe' (app-feature wins when a page has both). Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
|
|
15
15
|
*/
|
|
16
16
|
listAppPortalEmbeds(params: {
|
|
17
17
|
path: {
|
|
@@ -13,7 +13,7 @@ class AppEmbedTargetsApi {
|
|
|
13
13
|
}
|
|
14
14
|
/**
|
|
15
15
|
* List an app's portal embeds
|
|
16
|
-
* Returns the portal pages in the organization where the given app is embedded (as an app-feature brick). One entry per page, each with the portal name, page title,
|
|
16
|
+
* Returns the portal pages in the organization where the given app is embedded (as an app-feature brick or via a regular embed/iframe block pointing at the app host). One entry per page, each with the portal name, page title, a ready-to-use page URL, and a `kind` of 'app-feature' or 'iframe' (app-feature wins when a page has both). Org-scoped by design (per spec); workspace-level access enforcement is portal-service's responsibility. Requires portals.read access.
|
|
17
17
|
*/
|
|
18
18
|
async listAppPortalEmbeds(params) {
|
|
19
19
|
return this.client.request({
|
|
@@ -9,6 +9,12 @@ export interface AppPortalEmbedContract {
|
|
|
9
9
|
};
|
|
10
10
|
/** Ready-to-use URL of the portal page where the app is embedded. */
|
|
11
11
|
url: string;
|
|
12
|
+
/**
|
|
13
|
+
* How the app is embedded on the page: as a first-class `app-feature` brick or
|
|
14
|
+
* via a regular `embed` (iframe) block whose `contentUrl` points at the app
|
|
15
|
+
* host. When a page matches both, `app-feature` wins (brick precedence).
|
|
16
|
+
*/
|
|
17
|
+
kind: "app-feature" | "iframe";
|
|
12
18
|
}
|
|
13
19
|
export interface ListAppPortalEmbedsResponseContract {
|
|
14
20
|
/** One entry per portal page where the app is embedded. */
|
package/package.json
CHANGED
package/release-notes/latest.md
CHANGED
|
@@ -1,53 +1,9 @@
|
|
|
1
|
-
# Release Notes 2.3.
|
|
1
|
+
# Release Notes 2.3.13-sdk.0
|
|
2
2
|
|
|
3
3
|
- Current ref: `HEAD`
|
|
4
|
-
- Previous tag: `v2.3.
|
|
5
|
-
- Generated at: 2026-06-
|
|
4
|
+
- Previous tag: `v2.3.13-sdk.0`
|
|
5
|
+
- Generated at: 2026-06-29T09:25:21.413Z
|
|
6
6
|
|
|
7
7
|
## Included Drafts
|
|
8
8
|
|
|
9
|
-
-
|
|
10
|
-
|
|
11
|
-
## Summary
|
|
12
|
-
|
|
13
|
-
### Bulk invite users to a portal
|
|
14
|
-
|
|
15
|
-
Gate exposes `POST /:orgId/portals/:portalId/invite/bulk` (`bulkInviteToPortal`) to invite many users to a single portal in one request, replacing N sequential `inviteToPortal` calls. Invites run with bounded concurrency (default 5, max 5); the rest are queued. Portal discovery (`listPortals`/`getPortal`) runs once for the whole batch. An optional `background` mode returns immediately without blocking the caller.
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
## API / SDK Changes
|
|
19
|
-
|
|
20
|
-
### Bulk invite users to a portal
|
|
21
|
-
|
|
22
|
-
- Added `bulkInviteToPortal` operation and `PortalsApi.bulkInviteToPortal` SDK client method.
|
|
23
|
-
- Request: `invitations[]` (each item matches `inviteToPortal`: `email` required; optional `fullName`, `orgRole`, `workspaceRole`, `isFullAccess`), optional `concurrency` (1..5, default 5), optional `background` (default false).
|
|
24
|
-
- Response: `total`, `status` (`completed` | `processing`). For `completed`: `succeeded`, `failed`, `results[]` (`{ email, status, magicLink?, url?, userId?, error? }`). For `processing`: `accepted`.
|
|
25
|
-
- Per-invitation `orgRole`/`isFullAccess` semantics are identical to `inviteToPortal` (shared `invitePortalUser` helper).
|
|
26
|
-
- Permission: `portals.manage` with org-scoped authz (same as `inviteToPortal`).
|
|
27
|
-
- MCP: `bulkInviteToPortal` is MCP-visible under the `portals` prompt group; the prompt now documents batching, concurrency, background mode, and the client access-clarification rule.
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
## Consumer Impact
|
|
31
|
-
|
|
32
|
-
### Bulk invite users to a portal
|
|
33
|
-
|
|
34
|
-
- App agents inviting several clients can issue one call instead of N blocking sequential requests.
|
|
35
|
-
- Single `inviteToPortal` is unchanged; behavior and response shape are preserved.
|
|
36
|
-
- Failures are isolated per invitee in `completed` mode — a single bad invite does not fail the batch.
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
## Verification
|
|
40
|
-
|
|
41
|
-
### Bulk invite users to a portal
|
|
42
|
-
|
|
43
|
-
- `npm test -- tests/unit/portals-bulk-invite-controller.test.ts tests/unit/concurrency.test.ts tests/unit/portals-controller.test.ts`
|
|
44
|
-
- `npm run build`
|
|
45
|
-
- `npm run build:sdk`
|
|
46
|
-
- `npm run mcp:skills:generate` (validate blocked locally: `skills-ref` Python module unavailable in this environment)
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
## Follow-ups
|
|
50
|
-
|
|
51
|
-
### Bulk invite users to a portal
|
|
52
|
-
|
|
53
|
-
- Background mode is fire-and-forget within the request pod; if durable retry/observability is later required, move bulk processing to a worker/queue.
|
|
9
|
+
- None
|
package/release-notes/2.3.12.md
DELETED
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
# Release Notes 2.3.12
|
|
2
|
-
|
|
3
|
-
- Current ref: `HEAD`
|
|
4
|
-
- Previous tag: `v2.3.12`
|
|
5
|
-
- Generated at: 2026-06-29T08:59:27.274Z
|
|
6
|
-
|
|
7
|
-
## Included Drafts
|
|
8
|
-
|
|
9
|
-
- `docs/release-notes/2026-06-16-bulk-invite-to-portal.md` - Bulk invite users to a portal
|
|
10
|
-
|
|
11
|
-
## Summary
|
|
12
|
-
|
|
13
|
-
### Bulk invite users to a portal
|
|
14
|
-
|
|
15
|
-
Gate exposes `POST /:orgId/portals/:portalId/invite/bulk` (`bulkInviteToPortal`) to invite many users to a single portal in one request, replacing N sequential `inviteToPortal` calls. Invites run with bounded concurrency (default 5, max 5); the rest are queued. Portal discovery (`listPortals`/`getPortal`) runs once for the whole batch. An optional `background` mode returns immediately without blocking the caller.
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
## API / SDK Changes
|
|
19
|
-
|
|
20
|
-
### Bulk invite users to a portal
|
|
21
|
-
|
|
22
|
-
- Added `bulkInviteToPortal` operation and `PortalsApi.bulkInviteToPortal` SDK client method.
|
|
23
|
-
- Request: `invitations[]` (each item matches `inviteToPortal`: `email` required; optional `fullName`, `orgRole`, `workspaceRole`, `isFullAccess`), optional `concurrency` (1..5, default 5), optional `background` (default false).
|
|
24
|
-
- Response: `total`, `status` (`completed` | `processing`). For `completed`: `succeeded`, `failed`, `results[]` (`{ email, status, magicLink?, url?, userId?, error? }`). For `processing`: `accepted`.
|
|
25
|
-
- Per-invitation `orgRole`/`isFullAccess` semantics are identical to `inviteToPortal` (shared `invitePortalUser` helper).
|
|
26
|
-
- Permission: `portals.manage` with org-scoped authz (same as `inviteToPortal`).
|
|
27
|
-
- MCP: `bulkInviteToPortal` is MCP-visible under the `portals` prompt group; the prompt now documents batching, concurrency, background mode, and the client access-clarification rule.
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
## Consumer Impact
|
|
31
|
-
|
|
32
|
-
### Bulk invite users to a portal
|
|
33
|
-
|
|
34
|
-
- App agents inviting several clients can issue one call instead of N blocking sequential requests.
|
|
35
|
-
- Single `inviteToPortal` is unchanged; behavior and response shape are preserved.
|
|
36
|
-
- Failures are isolated per invitee in `completed` mode — a single bad invite does not fail the batch.
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
## Verification
|
|
40
|
-
|
|
41
|
-
### Bulk invite users to a portal
|
|
42
|
-
|
|
43
|
-
- `npm test -- tests/unit/portals-bulk-invite-controller.test.ts tests/unit/concurrency.test.ts tests/unit/portals-controller.test.ts`
|
|
44
|
-
- `npm run build`
|
|
45
|
-
- `npm run build:sdk`
|
|
46
|
-
- `npm run mcp:skills:generate` (validate blocked locally: `skills-ref` Python module unavailable in this environment)
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
## Follow-ups
|
|
50
|
-
|
|
51
|
-
### Bulk invite users to a portal
|
|
52
|
-
|
|
53
|
-
- Background mode is fire-and-forget within the request pod; if durable retry/observability is later required, move bulk processing to a worker/queue.
|