@pitcher/js-api 1.29.0 → 1.31.0

package/lib/components/masterCanvases/CMasterCanvasesManagement.use.d.ts

@@ -0,0 +1,86 @@
+import { CanvasRetrieve } from '../../../types/openapi';
+/**
+ * PIT-7488 — row actions on a master pitchdeck, from the signed-off prototype's `…` menu.
+ *
+ * Same vocabulary as the pitchdeck tab, minus `use-as-master` (a master cannot become one) and
+ * plus `share` (sharing a master with colleagues, which ordinary decks do not do).
+ */
+export type MasterCanvasAction = 'view' | 'edit' | 'open-new-tab' | 'freeze' | 'share' | 'duplicate' | 'delete';
+/** Dialogs the master tab owns. `create-from-master` belongs to the create flow (block 4). */
+export type MasterCanvasDialog = {
+    type: 'share';
+    canvasId: CanvasRetrieve['id'];
+} | {
+    type: 'duplicate';
+    canvasId: CanvasRetrieve['id'];
+} | {
+    type: 'confirm-delete';
+    canvasId: CanvasRetrieve['id'];
+};
+/** Actions the host performs directly — no confirmation step. */
+export type MasterCanvasPassthroughAction = Exclude<MasterCanvasAction, 'share' | 'duplicate' | 'delete'>;
+/**
+ * What a row action resolves to. Splitting these two apart is the point of this module: the
+ * prototype's `onRowAction` switch conflates "open a dialog" with "do the thing", and the two
+ * have completely different owners in production — dialogs are local state, whereas view / edit /
+ * download / freeze are host callbacks that already exist on the pitchdeck tab.
+ */
+export type MasterCanvasActionResolution = {
+    kind: 'dialog';
+    dialog: MasterCanvasDialog;
+} | {
+    kind: 'passthrough';
+    action: MasterCanvasPassthroughAction;
+};
+export declare function resolveMasterCanvasAction(action: MasterCanvasAction, canvasId: CanvasRetrieve['id']): MasterCanvasActionResolution;
+/**
+ * Dialog state for the master tab.
+ *
+ * This is the ONLY part of the PoC reducer that survives contact with production: its list
+ * mutations (create / duplicate / delete / share) all rewrote an in-memory array, whereas here
+ * the list comes from the host's `fetcher` and a mutation is a request plus a refetch — machinery
+ * `CSavedCanvasesManagement` already owns. So this deliberately holds no rows.
+ */
+export declare function useMasterCanvasDialogs(): {
+    dialog: import('vue').Ref<{
+        type: "share";
+        canvasId: CanvasRetrieve["id"];
+    } | {
+        type: "duplicate";
+        canvasId: CanvasRetrieve["id"];
+    } | {
+        type: "confirm-delete";
+        canvasId: CanvasRetrieve["id"];
+    } | null, MasterCanvasDialog | {
+        type: "share";
+        canvasId: CanvasRetrieve["id"];
+    } | {
+        type: "duplicate";
+        canvasId: CanvasRetrieve["id"];
+    } | {
+        type: "confirm-delete";
+        canvasId: CanvasRetrieve["id"];
+    } | null>;
+    openDialog: (next: MasterCanvasDialog) => void;
+    closeDialog: () => void;
+    handleAction: (action: MasterCanvasAction, canvasId: CanvasRetrieve["id"]) => MasterCanvasPassthroughAction | null;
+};
+export interface ShouldOfferUseToCreateOptions {
+    /** The permission/settings gate the pitchdeck cell also applies. */
+    canUseToCreate: boolean;
+}
+/**
+ * Whether a master's row may offer "Use to create pitchdeck" (PIT-7488 QA Q12).
+ *
+ * The `!isDraft` term is GONE as of PIT-8360, along with the Ready column that was the only control
+ * able to clear the flag. Keeping it would have stranded two populations for good: every new master
+ * (created as a Draft until this change) and every master already created as one — hidden from the
+ * row action here and filtered out of the creation picker, with nothing left to flip.
+ *
+ * So a master is offerable whenever the caller may create from one. Masters no longer carry a
+ * meaningful draft state; `is_draft` survives on the model because every canvas has it, not because
+ * anything on this tab means anything by it.
+ *
+ * Hidden rather than disabled, matching how this cell already treats an unavailable lead action.
+ */
+export declare function shouldOfferUseToCreate(opts: ShouldOfferUseToCreateOptions): boolean;

package/lib/components/masterCanvases/CMasterCanvasesManagement.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/CMasterCanvasesPendingShareCell.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/CMasterCanvasesSharedWithCell.use.d.ts

@@ -0,0 +1,39 @@
+import { MiniUser } from '../../../types/openapi';
+/**
+ * PIT-7488 — display logic for the master pitchdeck "Shared with" cell.
+ *
+ * Kept out of the SFC so the capping/label rules are unit-testable: the cell itself is then a
+ * thin renderer over this result.
+ *
+ * The list is `Collaboration['user']` (a `MiniUser`) — block 5 is what will actually populate it.
+ */
+/** Avatars rendered before collapsing the rest into a "+N" bubble. From the prototype. */
+export declare const MAX_SHARED_WITH_AVATARS = 3;
+export interface SharedWithSummary {
+    /** Users to render an avatar for, capped at `max`. */
+    shown: MiniUser[];
+    /** How many users the cap hid. `0` when everyone fits. */
+    overflow: number;
+    /** Compact text beside the avatar stack. */
+    label: string;
+    /** Every name, for the hover tooltip and the aria-label. */
+    allNames: string;
+}
+/**
+ * Names in list order, blank-name users resolved to their email (SSO users frequently have no
+ * populated name — PIT-5973), and users with neither dropped rather than rendered as an
+ * empty comma.
+ */
+export declare function sharedWithNames(users: MiniUser[]): string[];
+/**
+ * The compact label beside the avatar stack: every shown name, then "+N" for the rest.
+ *
+ * Note the prototype (`next-core/src/app/examples/master-pitchdeck-ng/components/
+ * SharedWithCell.tsx`) contradicts itself — its comment promises "first two names + +N" while
+ * its code joins all three *shown* names. We follow the code. The label truncates in a narrow
+ * column, which is accepted: the tooltip always carries the full list.
+ *
+ * `names` is already email-resolved and blank-filtered; `overflow` is how many the cap hid.
+ */
+export declare function buildSharedWithLabel(names: string[], overflow: number): string;
+export declare function summarizeSharedWith(users: MiniUser[], max?: number): SharedWithSummary;

package/lib/components/masterCanvases/CMasterCanvasesSharedWithCell.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/createFromMaster.use.d.ts

@@ -0,0 +1,255 @@
+import { CanvasCreateRequest, CanvasRetrieve } from '../../../types/openapi';
+/**
+ * Metadata for a MASTER created from an existing canvas ("Use as master").
+ *
+ * Strips the source deck's own bookkeeping — the async-download record, so the new master does not
+ * offer a download of the SOURCE rendered before it became a master, and `frozen_until`, so a
+ * brand-new master is not born read-only.
+ *
+ * Deliberately KEEPS `pitcher.completion_wizard`, which is what separates this from
+ * `buildChildMetadata`. A master is a finished source: block 3 lets the wizard state survive into
+ * `context` (`buildMasterContext` prunes identity only), so pruning the `metadata` twin here would
+ * desynchronise the two and make the list's Progress column disagree with the wizard itself.
+ * Reusing `buildChildMetadata` would have been the intuitive fix and the wrong one.
+ */
+export declare function buildMasterMetadata(sourceMetadata?: CanvasRetrieve['metadata'] | null): Record<string, unknown> | undefined;
+/**
+ * The create payload for "Use as master pitchdeck" (PIT-7488 block 3).
+ *
+ * Mirror image of `buildCreateFromMasterPayload`, and it lives beside it for the same reason
+ * `buildMasterMetadata` does: the two directions must be read together or they drift.
+ *
+ * **`owned_by_id` is absent, and that absence is the contract (PIT-8362).** Django declares the
+ * field `default=CreateOnlyDefault(CurrentUserDefault())`, so omitting it is precisely what makes
+ * the master belong to whoever promoted the deck — the only owner "My Master Pitchdecks" can
+ * meaningfully show, since it is a personal, RESTRICTED, owner-scoped tab that the promote flow
+ * navigates to on success. Sending the SOURCE deck's owner instead (block 3's original rule,
+ * reverted here) put a colleague's master in the promoter's tab, and `CanvasOwnedByFieldValidator`
+ * 400s that transfer outright for anyone but an org/instance admin. Do not reintroduce the field.
+ *
+ * The rest mirrors the source deck, minus what a master must not inherit:
+ * - `account: null` + `access_type: RESTRICTED` — masters are account-less internal sources rather
+ *   than shared content (`resolve_account` nulls the account server-side anyway).
+ * - `context` — identity is stripped so every deck built from this master renders the PRESENTING
+ *   rep in `{{user.name}}`, not the promoter. See `buildMasterContext`.
+ * - `metadata` — drops the source's async-download record (its Actions cell would otherwise offer a
+ *   completed download of the deck as it was BEFORE becoming a master) and `pitcher.frozen_until`
+ *   (a brand-new master born read-only). Deliberately NOT `buildChildMetadata`: that also drops the
+ *   completion wizard, which a master keeps, and `buildMasterContext` keeps its `context` twin —
+ *   the two must agree.
+ *
+ * - `is_draft: false` — forced, NOT inherited (PIT-8360). Masters have no draft state since the
+ *   Ready column was dropped from the master tab (validation item #44), so nothing can clear the
+ *   flag afterwards: a deck promoted while still a draft would produce a permanently-draft master.
+ *   This keeps the promote path agreeing with the other three master-creation paths in
+ *   `MasterCanvasesView`, which force it too, rather than leaving `is_draft` set on masters with
+ *   nothing that sets it FOR them, waiting to bite whoever next writes a filter against it.
+ */
+export declare function buildMasterFromCanvasPayload(opts: {
+    source: CanvasRetrieve;
+    name: string;
+}): Omit<CanvasCreateRequest, 'instance_id'>;
+/**
+ * Drops the SOURCE's completion-wizard progress from a context that is otherwise copied verbatim.
+ *
+ * For the plain Duplicate action, which — unlike create-from-master — legitimately keeps the
+ * source's identity: the copy belongs to the same person, for the same account, so stripping
+ * `user`/`account` there would blank a deck the rep expects to be a faithful duplicate. The wizard
+ * state is different: `isCompletionWizardShowing` is `wizardSteps.length > 0 &&
+ * !context.pitcher.completion_wizard.completed`, so inheriting `completed: true` makes the copy
+ * open straight into the editor with the wizard silently skipped.
+ *
+ * Returns `undefined` when nothing survives, so the payload omits the field rather than writing an
+ * empty object over the server's default.
+ */
+export declare function withoutWizardState(context?: CanvasRetrieve['context'] | null): Record<string, unknown> | undefined;
+/**
+ * Context for a DUPLICATE (PIT-7488, peer review round 2).
+ *
+ * A pitchdeck copy strips the wizard state outright — see `withoutWizardState`. A MASTER copy cannot
+ * do either extreme:
+ *
+ * - Stripping it outright makes the copy look un-run, so the wizard reopens as a fresh `create`
+ *   seeded from the ADMIN GROUP CONFIG and completing it writes that seed over the curated slides
+ *   the rep just duplicated.
+ * - Keeping it verbatim inherits `completed: true`, which is the switch `isCompletionWizardShowing`
+ *   reads — the copy then opens straight into the editor and never offers the wizard at all, while
+ *   its Progress chip (from `metadata`) still says In progress. That desync is the whole reason
+ *   `withoutWizardState` exists.
+ *
+ * So a master copy is re-marked as what it actually is: a deck that HAS been through the wizard but
+ * is not finished. `react_saved` is exactly that state — `resolveWizardFlow` reads it as `edit` (so
+ * the copy restores its OWN content), while `completed` stays falsy so the wizard still shows and
+ * the chip still reads In progress, agreeing with `buildChildMetadata`.
+ *
+ * The marker is added only when the source carries a RESTORABLE artifact — see
+ * `hasRestorableArtifact`, which is the sole gate on this path because the edit flow has no
+ * downstream `fromArtifact` check. A master with nothing to restore must not claim `react_saved`, or
+ * the edit flow restores from an artifact that is not there and reopens the empty-`edit` bug (Q9).
+ * `initial_section_list_data` is dropped either way, so the copy re-seeds its candidate baseline
+ * from its own content rather than re-offering slides the source deliberately dropped.
+ */
+export declare function buildDuplicateContext(context?: CanvasRetrieve['context'] | null, opts?: {
+    isMaster?: boolean;
+}): Record<string, unknown> | undefined;
+/**
+ * Freezing a master says "this source is locked", not "every deck built from it is locked" — and a
+ * brand new deck the rep cannot edit is unusable.
+ */
+export declare function buildChildMetadata(masterMetadata?: CanvasRetrieve['metadata'] | null): Record<string, unknown> | undefined;
+/**
+ * The child's context: the master's configuration plus this session's identity.
+ *
+ * Identity is **stripped and re-added** rather than merged over, and that is the load-bearing
+ * detail. `getDefaultCrmShape` runs its result through `removeEmptyValues`, so on a non-CRM org
+ * (or with no live call) it emits no `account` and no `meeting` at all — a plain merge would then
+ * leave whatever the master carried, which is the wrong customer's name on the new deck. Stripping
+ * first means the child's identity keys can only ever come from the current session.
+ *
+ * It cannot rely on block 3 having cleaned the master either: `buildMasterContext` runs once, at
+ * creation, and opening a master in the builder afterwards deep-merges live `Account` /
+ * `salesforce_data` / `pitcher_data` back into its context. Every master is therefore re-poisonable
+ * between creation and use, and this is the last gate before a customer sees the result.
+ *
+ * `accountName` overrides whatever the CRM shape resolved because `getDefaultCrmShape` prefers the
+ * LIVE call's selected account (`call.selectedAccount.Name ?? accountName`). The account chosen in
+ * the dialog is the deck's account, so a rep prepping a deck for Beta during a call with Acme must
+ * not get Acme's name interpolated into it.
+ *
+ * The wizard artifact's OWN identity goes too (`withoutWizardIdentity`): the top-level key list
+ * never reached `wizard.subtitle`, so the promoter's customer rode onto the child's cover slide via
+ * `{{wizard.subtitle.label}}` (PIT-8399). Masters are re-poisonable after creation, so this pass
+ * has to run here as well as in `buildMasterContext`.
+ *
+ * The master's wizard PROGRESS is replaced rather than merely dropped (`pitcher.completion_wizard`,
+ * see `WIZARD_STATE_PITCHER_KEY`). Dropping it is what lets the completion wizard run on the new
+ * deck — on a `enable_react_completion_wizard` instance, the `pitchdeck-wizard-ng` app — but a deck
+ * with NO wizard state at all also reads as never-curated, and the wizard's create flow then
+ * reseeds its agenda from the ADMIN GROUP CONFIG, silently dropping every custom agenda point the
+ * master carried (PIT-8399, the reported defect). So the progress is reset to the one fact that
+ * survives: `from_master`, which says "this deck's content was copied from a curated source, so its
+ * own artifact is the authoritative agenda". `resolveWizardAgendaSource` reads it.
+ *
+ * `from_master` deliberately sets NONE of `completed` / `edited` / `react_saved`, so
+ * `resolveWizardFlow` still answers `'create'`: the deck really is being created, the editor still
+ * says so, and identity stays with the create flow rather than being restored off the master. That
+ * is what separates this from `buildDuplicateContext`, which marks a master COPY `react_saved` and
+ * accepts the `'edit'` flow because a duplicate legitimately IS the source. Do not unify the two.
+ *
+ * **Knock-on the marker's PRESENCE has** (review): `App.vue` computes
+ * `hasWizardState: isCompletionWizardEnabled || !!context.pitcher.completion_wizard` as a
+ * deliberate proxy for the window before the app roster loads, so a from-master deck now satisfies
+ * it from creation onward where it previously had no such key. With
+ * `enable_edit_opens_completion_wizard` on, `isWizardOwnedEditSurface` therefore holds the surface
+ * for such a deck immediately — correct whenever the deck has wizard steps, which is every normal
+ * case, and the marker is only written when the master carried an artifact, which means the wizard
+ * had already run on it. The sharp edge is a deck with an artifact and ZERO steps (its SectionList
+ * node deleted in the raw builder after the wizard ran): it is demoted out of edit mode with no
+ * wizard to open. That edge PREDATES this change — every deck that has ever run the wizard carries
+ * the same key — and this only adds one more way to reach it, so it is accepted rather than worked
+ * around here. Do not "optimise" the marker away on the assumption it is inert.
+ *
+ * Written only when the copied context actually still CARRIES an artifact (`context.wizard`) — not
+ * when the master merely had wizard PROGRESS. Those two come apart in both directions and both are
+ * wrong: `ensureWizardInitialized` writes `pitcher.completion_wizard` when the wizard OPENS, so a
+ * master whose wizard was opened and cancelled has progress and no artifact (5 such masters live on
+ * test-eu), while a master with an artifact and no progress key would be left unfixed. Claiming an
+ * artifact that is not there reopens the empty-`edit` bug from the other side (PIT-7488 QA Q9): the
+ * restore finds no skeletons and parks every ref on one unnamed point.
+ *
+ * Returns `undefined` rather than `{}` so the create payload omits the field instead of writing an
+ * empty object over the server's default.
+ */
+export declare function buildContextFromMaster(opts: {
+    masterContext?: CanvasRetrieve['context'] | null;
+    /** `getDefaultCrmShape({ accountName, myUser })` — passed in because it needs Vue injection. */
+    crmShape?: Record<string, unknown> | null;
+    /** The account chosen in the dialog, already privacy-mode-adjusted (blank name = store no name). */
+    account?: {
+        id: string;
+        name?: string;
+    } | null;
+}): Record<string, unknown> | undefined;
+/**
+ * The create payload for a pitchdeck built from a master.
+ *
+ * `is_master: false` is spelled out rather than left to the spread: the fetched master carries
+ * `is_master: true`, and the flow also runs FROM the master tab, whose own `creator` exists to make
+ * masters. The child is an ordinary deck — it appears on the Pitchdecks tab, it has an account, and
+ * it is the thing the rep presents.
+ *
+ * `is_draft: false` matches the platform's other rep-facing creation flows (the create wizard posts
+ * `is_draft: false`). Inheriting the master's flag would silently mark customer-facing decks as
+ * drafts whenever the master was left in draft — a master's own status is bookkeeping for a source
+ * artifact and says nothing about the deck made from it.
+ *
+ * `access_type` is deliberately absent: it rides along from the master via the spread, and the host
+ * `creator` forces the value it wants (RESTRICTED for rep-created decks).
+ */
+export declare function buildCreateFromMasterPayload(opts: {
+    master: CanvasRetrieve;
+    name: string;
+    /** Already privacy-mode-adjusted by the caller (`enable_crm_privacy_mode` blanks the name). */
+    account?: {
+        id: string;
+        name?: string;
+    } | null;
+    crmShape?: Record<string, unknown> | null;
+}): Omit<CanvasCreateRequest, 'instance_id'>;
+/**
+ * Whether the dialog must collect an account before it can create.
+ *
+ * Follows the platform setting rather than the prototype's always-required Account field: on a
+ * non-CRM org there are no accounts to offer, so requiring one would make the whole feature
+ * unreachable. Same rule the create modal and the duplicate flow already apply.
+ */
+export declare function shouldRequireAccountOnCreateFromMaster(opts: {
+    isCRM?: boolean;
+    requireAccountOnCanvasCreation?: boolean;
+}): boolean;
+type MasterOption = Pick<CanvasRetrieve, 'id' | 'name'>;
+/**
+ * Guarantees the master a row action was fired from is in the offered list.
+ *
+ * Since PIT-8360 dropped the picker's `is_draft: false` fetch filter the two lists agree, so this is
+ * now a guard rather than the everyday path: it still covers a master created or renamed after the
+ * list was fetched, and the `fetchAll` truncation at `MAX_FETCH_LIMIT`. Without it the rep could
+ * click a master's "Use to create pitchdeck" and land in a picker that neither preselects nor offers
+ * it. Sibling of `buildMasterPickerOptions`, which applies the same rule to the Vue dialog's option
+ * shape.
+ */
+export declare function withPreselectedMaster<T extends {
+    id: string;
+}>(masters: T[], preselected?: T | null): T[];
+/**
+ * Options for the dialog's master picker.
+ *
+ * The picker lists every master since PIT-8360 dropped the fetch's `is_draft: false` filter — with
+ * the master tab's Ready column gone, nothing can clear the flag, so filtering would permanently
+ * hide masters already stored as drafts.
+ *
+ * **No draft marker on the labels** (PR review). It used to suffix "(Draft)", which was already
+ * unreachable — the fetch narrows to `id,name,tags,modified_at`, so every option arrived with
+ * `is_draft === undefined`. Restoring it via the `fields` list would have been the wrong repair:
+ * masters have no draft state to advertise any more, and a badge on a subset of them describes a
+ * distinction nothing in the product can act on. Dropping it also removes the hook a future reader
+ * would most likely rebuild a filter around.
+ *
+ * The preselected master is still injected — see `withPreselectedMaster` for the cases that still
+ * reaches.
+ */
+export declare function buildMasterPickerOptions(opts: {
+    masters: MasterOption[];
+    preselected?: MasterOption | null;
+}): {
+    label: string;
+    value: string;
+}[];
+/** Guards the submit button. A blank name would create a nameless row in the rep's own list. */
+export declare function canSubmitCreateFromMaster(opts: {
+    name?: string | null;
+    masterId?: string | null;
+    isAccountRequired?: boolean;
+    accountId?: string | null;
+}): boolean;
+export {};

package/lib/components/masterCanvases/createFromMaster.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterCanvasDocuments.use.d.ts

@@ -0,0 +1,56 @@
+/**
+ * PIT-7488 block 7 — pure logic behind the Documents column.
+ *
+ * Display only. The decision of WHICH masters to render lives server-side, in next-core's
+ * `selectCanvasIdsNeedingRender`: the bulk read already computes `is_stale` in SQL, so keeping the
+ * policy next to it avoids two copies of the same rule drifting apart in two languages.
+ *
+ * Kept free of Vue so the state machine is testable on its own.
+ */
+/**
+ * Mirrors next-core's `MasterDocumentsState`. Duplicated deliberately — next-core types are not
+ * published to canvas-ui, and canvas-ui must not import from next-core.
+ */
+export interface MasterDocumentsState {
+    status: 'pending' | 'rendering' | 'ready' | 'failed';
+    pdf_url: string | null;
+    pptx_url: string | null;
+    rendered_at: string | null;
+    is_stale: boolean;
+    attempts: number;
+    error: string | null;
+}
+export type DocumentsCellState = 
+/** No documents row at all — this master has never been rendered. */
+'none'
+/** A render is queued or running. */
+ | 'rendering'
+/** Current documents are available. */
+ | 'ready'
+/** Documents are available but out of date; a fresh render is coming. */
+ | 'ready_refreshing'
+/** The last render failed. */
+ | 'failed';
+/**
+ * Must match next-core's `MAX_RENDER_ATTEMPTS`. A client offering a fourth retry would render a
+ * button the server refuses to act on.
+ */
+export declare const MAX_RENDER_ATTEMPTS = 3;
+/**
+ * Maps a documents row onto what the cell should show.
+ *
+ * The `ready` + stale case deliberately keeps the existing links rather than reverting to a spinner:
+ * a slightly out-of-date document a rep can open beats a dead control. Only a genuinely absent
+ * artifact shows progress.
+ */
+export declare function resolveDocumentsCellState(state: MasterDocumentsState | undefined | null): DocumentsCellState;
+/**
+ * Whether to offer Retry. Only for a failed row, and only while the server would still act on it.
+ */
+export declare function canRetryDocuments(state: MasterDocumentsState | undefined | null): boolean;
+/**
+ * Whether the cell has anything openable. Drives the disabled state of each link independently —
+ * the two artifacts have different lifetimes (the PPTX object expires days before the PDF's URL
+ * mapping does), so one can be present while the other is not.
+ */
+export declare function hasOpenableDocument(state: MasterDocumentsState | undefined | null, format: 'pdf' | 'pptx'): boolean;

package/lib/components/masterCanvases/masterCanvasDocuments.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterCanvasShares.use.d.ts

@@ -0,0 +1,103 @@
+import { MiniUser } from '../../../types/openapi';
+/** Exactly `Collaboration['user']` and the "Sent to" cell's prop element (PIT-8421; was "Shared with"). */
+export type MasterCanvasShareUser = MiniUser;
+/**
+ * PIT-7488 block 5 — may the current user CHANGE this master canvas (Edit / Delete / Freeze)?
+ *
+ * The owner, **or an instance admin/editor**. That second arm mirrors Django's write gate
+ * exactly — `CanvasPermission.has_object_permission` returns True for
+ * `is_instance_admin or is_instance_editor or obj.is_owner(user)` — and it matters because the
+ * master list is not "only mine" for those roles: admins and editors route through
+ * `filter_by_admin_access`, so they see every master in the instance. Gating on ownership alone
+ * made the UI STRICTER than the API and silently removed Edit/Delete/Freeze from every master an
+ * admin did not personally own.
+ *
+ * A share recipient never reaches this gate on the SENDER's master: accepting an invitation mints
+ * a copy they own, so they meet the ownership arm on their own row and the sender's original is
+ * not in their list at all. That is why ng-rest-api#1688's read gates were reverted (#1689) —
+ * under invitation semantics there is no "viewing someone else's master" state to widen for.
+ *
+ * Fails closed, and deliberately not a bare `ownerId === myUserId`: that returns true when both
+ * are `undefined`, which would hand a recipient full control of any master whose owner failed to
+ * serialise.
+ */
+export declare function canManageMasterCanvas(opts: {
+    ownerId?: number | null;
+    myUserId?: number | null;
+    isAdminOrEditor?: boolean;
+}): boolean;
+/**
+ * PIT-7488 block 5 — may the current user SHARE this master canvas?
+ *
+ * The owner ONLY — deliberately narrower than `canManageMasterCanvas`. The next-core route is
+ * owner-gated (`master.ownedById !== user.id` → 403), so offering "Share with" to an admin on
+ * someone else's master would surface an action the API refuses. Sharing is the owner's call
+ * about their own material, not a moderation capability.
+ */
+export declare function canShareMasterCanvas(opts: {
+    ownerId?: number | null;
+    myUserId?: number | null;
+}): boolean;
+/**
+ * Per-user outcome of a send, mirroring next-core's `InvitationResult`.
+ *
+ * `already_invited` is benign (the UNIQUE key makes a repeat a no-op); `not_a_member` means the
+ * picker offered someone the server then refused, which the sender needs told.
+ */
+export type MasterShareInvitationStatus = 'invited' | 'already_invited' | 'not_a_member' | 'self';
+export interface MasterShareInvitationResult {
+    user_id: number;
+    status: MasterShareInvitationStatus;
+}
+/** One pending invitation, as the recipient's list renders it. */
+export interface PendingMasterShare {
+    share_id: number;
+    canvas_id: string;
+    canvas_name: string;
+    instance_id: string;
+    shared_by: MiniUser;
+    created_at: string;
+}
+export declare function pendingRowId(shareId: number): string;
+export declare function isPendingRowId(id?: string | number | null): boolean;
+/**
+ * The share id behind a pending row id, or `null` if it is not one.
+ *
+ * Digits only, deliberately: `Number('')` is `0` and `Number.isInteger(0)` is true, so a bare
+ * `'pending:'` used to parse to share id 0 — and `Number` also accepts whitespace, `0x` and
+ * exponent forms. Share ids are a positive `serial`, so anything else is a bug upstream and must
+ * read as "not a pending row" rather than as row 0.
+ */
+export declare function pendingShareIdFromRowId(id?: string | number | null): number | null;
+/**
+ * Shapes a pending invitation as a table row.
+ *
+ * `owned_by` carries the SHARER, which is what lets the existing Owner column render "who sent
+ * this" with no special-casing — for an invitation the only person worth naming is the sender.
+ * `is_master` keeps it consistent with the tab it appears on; every other canvas field is left
+ * absent so the remaining cells render empty rather than inventing state the invitation has not
+ * got (no tags, no progress, no modified date, no ready/draft status).
+ */
+export interface PendingMasterShareRow {
+    id: string;
+    name: string;
+    owned_by: MiniUser;
+    is_master: true;
+    created_at: string;
+    modified_at: string;
+    __pendingShare: PendingMasterShare;
+}
+export declare function toPendingRow(share: PendingMasterShare): PendingMasterShareRow;
+/**
+ * Pending invitations first, then the user's own masters.
+ *
+ * Prepended rather than sorted in: an invitation is an inbox item needing a decision, and the
+ * table's sort applies to the fetched page — a pending row sorted by `modified_at` would sink
+ * below the fold on a rep with many masters and never be seen.
+ *
+ * Returns the list unchanged when there is nothing pending, so the non-master variants and the
+ * common case allocate nothing.
+ */
+export declare function mergePendingRows<T extends {
+    id: string;
+}>(rows: T[], pending: PendingMasterShare[]): (T | PendingMasterShareRow)[];

package/lib/components/masterCanvases/masterCanvasShares.use.spec.d.ts

@@ -0,0 +1 @@
+export {};