@trii/types 2.10.740 → 2.10.743

package/dist/Common/Messages/Message.d.ts

@@ -1,3 +1,4 @@
+import { IEventType } from "../../Calendar/Event";
 import { IContactAddress } from "../../Contacts/contacts";
 import { UserInfo } from "../../Users/UserTrii";
 import { IChannelInfo } from "../Channels/Channel";
@@ -336,6 +337,16 @@ export interface MessageEvent {
     allDay: boolean;
     location?: string;
     details?: string;
+    /** Color del evento (`IEvent.color`), para que la tarjeta use el mismo del calendario. */
+    color?: string;
+    /** Tipo de evento (`IEvent.eventType`): nombre, color e ícono. Snapshot, como el resto. */
+    eventType?: IEventType;
+    /**
+     * Sólo en eventos recurrentes: la ocurrencia que se compartió
+     * (`IEvent.originalOccurrenceDate`). `eventId` identifica la serie, así que sin esto el deep
+     * link abre la serie y no el día compartido.
+     */
+    originalOccurrenceDate?: Date;
     /** Deep link al evento (`/a/calendar/Calendar?eventId=`). El front lo recalcula si falta. */
     link?: string;
 }

package/dist/Conversations/SocialWalls.d.ts

@@ -19,6 +19,8 @@ export interface Post {
     participants: UserInfo[];
     archived: boolean;
     assignment: ConversationAssignmentSnapshot;
+    /** Concurrencia optimista + idempotencia de comandos, igual que Conversation.version. */
+    version: number;
     createdAt: Date;
     updatedAt: Date;
 }

package/dist/Tickets/SelfService.d.ts

@@ -2,6 +2,7 @@ import { ChannelType } from "../Common/Channels/ChannelType";
 import { ITicketAuditedEntity, ITicketProperty, TicketPriority } from "./Common";
 import { ITicketMessageReference } from "./Conversation";
 import type { ITicketCursorResponse } from "./Api";
+import type { ITicketAttachmentUploadSession } from "./AdvancedApi";
 export declare enum TicketPortalAuthenticationMode {
     PUBLIC = "PUBLIC",
     OPTIONAL = "OPTIONAL",
@@ -508,6 +509,63 @@ export interface ISubmitTicketRequestDto {
     formSubmissionId: string;
     idempotencyKey: string;
 }
+/**
+ * One file the portal declares BEFORE any byte exists in storage.
+ *
+ * `sizeBytes` and `mimeType` are the client's DECLARATION and stay that way for
+ * the life of the attachment: tickets-api never sees the bytes (media-api owns
+ * storage), so there is nothing to compare them against.
+ */
+export interface ICreateCustomerTicketAttachmentDto {
+    fileName: string;
+    mimeType: string;
+    sizeBytes: number;
+    checksum?: string;
+}
+/**
+ * Direct ticket creation from a portal, without going through a request draft.
+ *
+ * What is ABSENT is the contract, not an oversight: there is no channelType,
+ * channelId, primaryConversationId, assigneeId, assigneeName, assignedGroupId,
+ * statusId, origin, tagIds or externalReferences. Routing, channel provenance
+ * and the internal taxonomy are decisions of the agent side; the server fills
+ * them in (origin WEB_FORM, the space's initial status, the routing defaults of
+ * the category and the request type).
+ */
+export interface ICreateCustomerTicketDto {
+    /** Mongo ObjectId of the contact opening the ticket. Row-level authorisation
+     *  of the whole customer surface: required, never defaulted. */
+    contactId: string;
+    title: string;
+    description?: string;
+    categoryId: string;
+    requestTypeId?: string;
+    /** Optional: a portal may or may not let the customer choose. Absent means the
+     *  server default (MEDIUM). */
+    priority?: TicketPriority;
+    properties?: ITicketProperty[];
+    /** Files the customer is about to upload. Declaring them here is what puts the
+     *  upload destinations inside the create transaction. */
+    attachments?: ICreateCustomerTicketAttachmentDto[];
+    /** REQUIRED, unlike ICreateTicketDto where it is optional: a portal submit is
+     *  the canonical double-click. `source` is NOT part of the contract - the
+     *  server derives it from the portal slug, so one portal's keys cannot collide
+     *  with another's. */
+    idempotencyKey: string;
+}
+/**
+ * The answer to a create, and the reason the flow is ordered ticket-first.
+ *
+ * `attachmentUploads` carries one session per declared attachment, in the order
+ * they were declared, each already bound to the new ticket. The portal uploads
+ * the bytes to `uploadUrl` and then completes each session. Until it does, the
+ * ticket has no attachments - the deliberate trade: no byte is ever uploaded for
+ * a ticket that failed to be created.
+ */
+export interface ICustomerTicketCreatedView {
+    ticket: ICustomerTicketView;
+    attachmentUploads: ITicketAttachmentUploadSession[];
+}
 export interface ICustomerTicketActionDto {
     expectedVersion: number;
     action: TicketCustomerAction;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trii/types",
-  "version": "2.10.740",
+  "version": "2.10.743",
   "description": "Types definitions for Trii projects - ",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",