@arbidocs/blocks 0.5.41 → 0.5.43

package/dist/connection/people/ConnectedPeopleMultiSelect.d.ts

@@ -0,0 +1,40 @@
+/** The shared people source bound to RecipientPicker’s field layout, including typed addresses. */
+import { ReactNode } from 'react';
+import { type UserResponse } from '@arbidocs/react';
+/** Selected user - either an ARBI user or just an email (someone to invite) */
+export interface PeopleSelection {
+    id: string;
+    email: string;
+    user?: UserResponse;
+}
+export interface ConnectedPeopleMultiSelectProps {
+    /** Also offer your own agents (where an agent is a valid target). */
+    includeAgents?: boolean;
+    /** Currently selected users */
+    selectedUsers: PeopleSelection[];
+    /** Callback when selection changes */
+    onSelectionChange: (users: PeopleSelection[]) => void;
+    /** Allow adding users by email (not among the search results) */
+    allowEmailEntry?: boolean;
+    /** Emails to exclude from selection (e.g., current workspace members) */
+    excludeEmails?: string[];
+    /** Emails to LABEL (not exclude) as already belonging to some group — e.g.
+     *  existing workspace members when picking who to share a resource with,
+     *  where re-selecting a member is valid (unlike excludeEmails). */
+    memberEmails?: string[];
+    /** Show contact toggle next to selected users */
+    showContactToggle?: boolean;
+    /** Show presence indicators */
+    showPresence?: boolean;
+    /** Placeholder text for empty state */
+    placeholder?: string;
+    /** Empty state message when no users available */
+    emptyMessage?: string;
+    /** Optional slot rendered right-aligned on the same row as the + button (when users selected) */
+    actionSlot?: ReactNode;
+    /** Optional content rendered inside each selected chip, between the identity
+     *  and the remove button — lets a caller show per-recipient role/status
+     *  without this component knowing anything about roles. */
+    renderChipExtra?: (selected: PeopleSelection) => ReactNode;
+}
+export declare function ConnectedPeopleMultiSelect({ includeAgents, selectedUsers, onSelectionChange, allowEmailEntry, excludeEmails, memberEmails, showContactToggle, showPresence, placeholder, emptyMessage, actionSlot, renderChipExtra, }: ConnectedPeopleMultiSelectProps): import("react").JSX.Element;

package/dist/connection/people/index.d.ts

@@ -0,0 +1 @@
+export { ConnectedPeopleMultiSelect, type ConnectedPeopleMultiSelectProps, type PeopleSelection, } from './ConnectedPeopleMultiSelect';

package/dist/connection/people/invitation-message.d.ts

@@ -0,0 +1,2 @@
+/** The same invitation consequence for workspace membership and a resource share. */
+export declare function invitationMessage(emails: readonly string[], workspaceWord?: string): string;

package/dist/connection/sharing/ConnectedShareDialog.d.ts

@@ -0,0 +1,7 @@
+import type { ShareRequest } from '../../provider/dialog-registry';
+export interface ConnectedShareDialogProps {
+    request: ShareRequest | null;
+    onClose: () => void;
+}
+/** Share one document or conversation through the same workspace-membership permission flow. */
+export declare function ConnectedShareDialog({ request, onClose }: ConnectedShareDialogProps): import("react").JSX.Element;

package/dist/connection/sharing/ResourceShareForm.d.ts

@@ -0,0 +1,24 @@
+import type { ShareRequest } from '../../provider/dialog-registry';
+interface ResourceShareFormProps extends ShareRequest {
+    onDone: () => void;
+    disabled?: boolean;
+}
+/**
+ * Share a document/conversation by email — pick from contacts already on the
+ * platform (or already invited) or type a new email, same picker as
+ * AddWorkspaceUser. Unlike adding workspace members, an existing member is
+ * still a valid target (they just get notified, no role change), so members
+ * aren't excluded from the list here — they're labeled instead, both in the
+ * picker and on their chip, so it's clear who's already in and who's being
+ * invited.
+ *
+ * This is deliberately a variant of the workspace-invite flow, not a
+ * narrower one: the binary permission model (private-to-owner vs
+ * shared-with-workspace) means adding anyone here who isn't already a member
+ * invites them into the whole workspace, and sharing a private resource
+ * makes it visible to that whole workspace, not just the people picked below.
+ * Both consequences are surfaced inline (copy + toggle) instead of as
+ * after-the-fact confirm popups.
+ */
+export declare function ResourceShareForm({ resourceType, resourceExtId, workspaceExtId, resourceName, isPrivate, onDone, disabled, }: ResourceShareFormProps): import("react").JSX.Element;
+export {};

package/dist/connection/sharing/index.d.ts

@@ -0,0 +1 @@
+export { ConnectedShareDialog, type ConnectedShareDialogProps } from './ConnectedShareDialog';

package/dist/connection/sharing/useShareResource.d.ts

@@ -0,0 +1,44 @@
+/**
+ * useShareResource Hook
+ *
+ * Sharing a document/conversation by email is a variant of the existing
+ * add-user-to-workspace flow (same endpoint, same required role for new
+ * members, same confirm_invite two-phase gate for unregistered emails) — see
+ * useWorkspaceMembership.handleShareWorkspace, which this mirrors. The one thing
+ * layered on top is a second, resource-specific confirmation: sharing a
+ * private resource makes it visible to the whole workspace, not just the
+ * recipients. The modal now surfaces that consequence as an inline toggle
+ * (defaulted on for a private resource) BEFORE submit, so `shareWithWorkspace`
+ * is normally already decided by the time this runs — the old
+ * yes/no confirm prompt for it only fires as a defensive fallback if the
+ * backend still reports the resource needs confirming (e.g. someone else
+ * changed its visibility between modal-open and submit).
+ *
+ * The backend's add-users endpoint takes a single role for the whole batch of
+ * emails in one call — it has no per-email role. To let the modal assign
+ * different roles to different recipients without a backend change, entries
+ * are grouped by role client-side and submitted as one call per distinct
+ * role group.
+ */
+import type { WorkspaceRole } from '@arbidocs/react';
+interface UseShareResourceParams {
+    workspaceExtId: string;
+    resourceType: 'document' | 'conversation';
+    resourceExtId: string;
+    resourceName?: string;
+    /** Emails already in the workspace. The backend's add-users endpoint
+     *  never returns an already-a-member recipient in its response (it
+     *  notifies them and moves on) — so without this, every already-a-member
+     *  email looks identical to a genuinely-unregistered one and wrongly
+     *  triggers the "isn't on the platform yet, invite them?" prompt. */
+    memberEmails?: string[];
+}
+export interface ShareEntry {
+    email: string;
+    role: WorkspaceRole;
+}
+export declare function useShareResource({ workspaceExtId, resourceType, resourceExtId, resourceName, memberEmails, }: UseShareResourceParams): {
+    shareResource: (entries: ShareEntry[], shareWithWorkspace: boolean) => Promise<"shared" | "cancelled" | "error">;
+    isSharing: boolean;
+};
+export {};

package/dist/connection/tips/useContextualHints.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Shared hints visibility: the account's saved show_hints preference, with an optional
+ * session-only override for guided actions. An explicit saved choice clears the override.
+ * Consumers gate on settingsLoaded so hints do not flash before the saved choice arrives.
+ */
+export declare function useContextualHints(): {
+    showHints: boolean;
+    settingsLoaded: boolean;
+    isDeveloper: boolean;
+    setShowHints: (value: boolean) => void;
+    setShowHintsPersisted: (value: boolean) => void;
+    dismissHints: () => void;
+};