@opencxh/domain 1.219.0 → 1.222.0

package/dist/entities/activity/catalog.d.ts

@@ -99,6 +99,23 @@ export declare function channelKindOf(type: string): ActivityChannelKind | undef
 export declare function isMessageShape(shape: ActivityShape | undefined): boolean;
 /** See {@link isMessageShape}. For the built-in types. */
 export declare function isMessageType(type: string): boolean;
+/**
+ * Does an answer of this kind fold into the list under the message it answers, instead of
+ * taking its own place in the timeline?
+ *
+ * Only notes. A mail carrying a `parentId` is still a message that was really sent, at a real
+ * moment, and burying it under the thing it answered would take it out of the chronology the
+ * rest of the conversation is read in — and out of view entirely while the thread is folded.
+ * An internal note has no such life of its own: it exists *about* that message.
+ *
+ * Keyed on the shape, so the rule has exactly one definition and an app-declared note kind
+ * behaves the same — see {@link ActivityTypeRegistry.nestsUnderParent}. `parentId` itself stays
+ * set on every reply regardless: it is a true fact about the row, and mail threading, the
+ * provider `In-Reply-To` and the reply notification all read it.
+ */
+export declare function isNoteShape(shape: ActivityShape | undefined): boolean;
+/** See {@link isNoteShape}. For the built-in types. */
+export declare function nestsUnderParent(type: string): boolean;
 /** Can a human reply to it? Not to notes — those go nowhere. */
 export declare function isReplyableType(type: string): boolean;
 /**

package/dist/entities/activity/resolve.d.ts

@@ -70,6 +70,8 @@ export declare class ActivityTypeRegistry {
      * {@link ResolvedActivityType}.
      */
     isMessage(type: string): boolean;
+    /** Folds into the list under the message it answers. See {@link isNoteShape}. */
+    nestsUnderParent(type: string): boolean;
     /** Can a person reply to this? Notes cannot — those go nowhere. */
     isReplyable(type: string): boolean;
     /** Readable content for a model: messages, notes and transcripts. */

package/dist/entities/activity/types.d.ts

@@ -1,6 +1,7 @@
 import { ActingIdentity } from '../../platform/identity';
 import { TranscriptSegment } from '../../platform/media';
 import { AIMessageInput, AIMessageOutput } from '../ai-message/types';
+import { ReactionSummary } from '../reaction/types';
 export type CallStatus = "new" | "connecting" | "ringing" | "connected" | "held" | "ended" | "failed";
 export type CallDirection = "inbound" | "outbound";
 export type CallType = "audio" | "video" | "data" | "screen-share";
@@ -34,6 +35,14 @@ export interface BaseActivity {
         contactId?: string;
     };
     direction: "inbound" | "outbound" | "internal" | "none";
+    /**
+     * The activity this one answers, if any — the in-app thread, one level deep.
+     *
+     * Not `EmailPayload.threadId`: that is the provider's own conversation id and groups a whole
+     * mail thread. This points at one activity, and an internal note can hang off a customer's
+     * mail with it. A reply to a reply stores the *top* parent, so the feed never nests twice.
+     */
+    parentId?: string;
     externalIds?: string[];
     attachments?: Attachment[];
     /**
@@ -42,6 +51,14 @@ export interface BaseActivity {
      * indicator while true.
      */
     pending?: boolean;
+    /**
+     * The emoji on this message, as the list and get routes project them.
+     *
+     * Read-only and **never stored on the activity row**: reactions are their own rows, keyed
+     * by (resource, actor, emoji), so two people reacting at once cannot race on one column.
+     * The server joins them on in one bulk query per page; a writer that sets this is ignored.
+     */
+    reactions?: ReactionSummary[];
     /** Epoch ms — matches the DB model and Interaction.createdAt. */
     createdAt?: number;
     updatedAt?: number;

package/dist/entities/reaction/index.d.ts

@@ -0,0 +1 @@
+export * from './types';

package/dist/entities/reaction/summarize.test.d.ts

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

package/dist/entities/reaction/types.d.ts

@@ -0,0 +1,73 @@
+/**
+ * Who reacted.
+ *
+ * Not a bare `userId`, and not `MutationAuthor`: a reaction can come from outside the
+ * organisation. A Teams chat is synced with the customer in it, and their 👍 has to land
+ * somewhere — as a `contact`, with the name the provider gave. Mirrors `BaseActivity.author`,
+ * which already carries that same four-way distinction.
+ *
+ * `id` is the user id, the app name, or the provider's id for a contact; absent for `system`.
+ */
+export interface ReactionActor {
+    type: "user" | "contact" | "app" | "system";
+    id?: string;
+    /** Shown on hover. Kept on the row because an external reactor has no record to look up. */
+    name?: string;
+}
+/**
+ * One emoji, put on one resource, by one actor.
+ *
+ * Addressed by (resourceType, resourceId) — the same `ResourceRef` shape read-state and the
+ * attribute store use — so an activity, a work comment, a file or a knowledge article all
+ * reuse this without the store learning what any of them are.
+ *
+ * A row per (resource, actor, emoji), never an array on the resource: two people reacting at
+ * the same moment would otherwise race on one column, and the unique index makes both the
+ * toggle and a re-sync from a provider idempotent.
+ */
+export interface Reaction {
+    id: string;
+    organizationId: string;
+    resourceType: string;
+    resourceId: string;
+    actor: ReactionActor;
+    /**
+     * The literal character, e.g. `"👍"` — never a shortcode and never a provider's name for it.
+     * One vocabulary means no mapping table in the core; the six legacy Teams names are
+     * translated at the edge, in the app that speaks to Graph.
+     */
+    emoji: string;
+    createdAt?: number;
+}
+/** One chip: an emoji, how many put it there, and who — for the hover. */
+export interface ReactionSummary {
+    emoji: string;
+    count: number;
+    actors: ReactionActor[];
+}
+/** `POST /reaction/:type/:id` body. `on` absent means "flip whatever it is now". */
+export interface ToggleReactionRequest {
+    emoji: string;
+    on?: boolean;
+    /**
+     * Who to record it for, instead of the caller.
+     *
+     * **Honoured for an app-to-app caller only**, and ignored outright for a user — otherwise
+     * anyone could put an emoji on a message in a colleague's name. It exists for provider
+     * sync: a reaction pulled out of Teams belongs to the person who left it there, not to the
+     * app that carried it across.
+     */
+    actor?: ReactionActor;
+}
+/** Reactions per resource id, as the list endpoints hand them to a feed. */
+export type ReactionsByResource = Record<string, ReactionSummary[]>;
+/**
+ * Rows to chips.
+ *
+ * Most-used first so the chip that carries the most agreement sits nearest the message, with
+ * ties broken by which emoji appeared first — a stable order, so a chip does not jump when
+ * someone else reacts. Pure: this is the one piece of the feature worth a test.
+ */
+export declare function summarizeReactions(rows: Reaction[]): ReactionSummary[];
+/** Did this user put this emoji there? The chip's own state, asked without a second query. */
+export declare function hasReacted(summary: ReactionSummary, userId: string | undefined): boolean;

package/dist/entities/work/activity.d.ts

@@ -1,3 +1,4 @@
+import { ReactionSummary } from '../reaction/types';
 import { WorkStatusCategory } from './types';
 /**
  * The activity feed under a work item.
@@ -36,6 +37,8 @@ export interface WorkActivity {
      * "the customer answered" and would wake every waiting assignment on the item.
      */
     direction: "internal";
+    /** The activity this one answers — same one-level thread as comms' `BaseActivity.parentId`. */
+    parentId?: string;
     /** `html` is the composer's markup for a comment; `text` stays the plain reading of it. */
     payload: {
         text?: string;
@@ -46,6 +49,12 @@ export interface WorkActivity {
         toStatus?: string;
         toCategory?: WorkStatusCategory;
     };
+    /**
+     * The emoji on this comment, as the list route projects them. Read-only and never stored
+     * on the row — see `BaseActivity.reactions`, which this mirrors, and the generic store in
+     * the communication app that both read from.
+     */
+    reactions?: ReactionSummary[];
     createdAt?: number;
     updatedAt?: number;
 }

package/dist/entities/work/keys.d.ts

@@ -10,8 +10,17 @@ import { WorkItem, WorkProject } from './types';
 /** The scope kinds `apps/work` claims through `/provider/scope/describe`. */
 export declare const WORK_ITEM_SCOPE_KIND = "work_item";
 export declare const WORK_PROJECT_SCOPE_KIND = "work_project";
+/**
+ * A row in an item's feed, addressable on its own.
+ *
+ * Claimed so the generic stores can hang something off a single comment — reactions today,
+ * whatever is resource-agnostic tomorrow. It inherits its item's access exactly the way
+ * comms' `activity:` inherits its conversation's: a comment is not a second boundary.
+ */
+export declare const WORK_ACTIVITY_SCOPE_KIND = "work_activity";
 export declare function workItemScopeKey(itemId: string): string;
 export declare function workProjectScopeKey(projectId: string): string;
+export declare function workActivityScopeKey(activityId: string): string;
 /**
  * The human key: `SAL-142`, or `SAL-142-1` for a subitem.
  *