@trii/types 2.10.743 → 2.10.744

package/dist/Tickets/SelfService.d.ts

@@ -1,8 +1,9 @@
 import { ChannelType } from "../Common/Channels/ChannelType";
-import { ITicketAuditedEntity, ITicketProperty, TicketPriority } from "./Common";
+import { ITicketAuditedEntity, ITicketProperty, TicketPriority, TicketPropertyValue } from "./Common";
 import { ITicketMessageReference } from "./Conversation";
 import type { ITicketCursorResponse } from "./Api";
 import type { ITicketAttachmentUploadSession } from "./AdvancedApi";
+import type { ITicketFieldOption, ITicketFieldValidation, ITicketObjectField, TicketFieldType } from "./Fields";
 export declare enum TicketPortalAuthenticationMode {
     PUBLIC = "PUBLIC",
     OPTIONAL = "OPTIONAL",
@@ -509,6 +510,76 @@ export interface ISubmitTicketRequestDto {
     formSubmissionId: string;
     idempotencyKey: string;
 }
+/** Just enough of the category to render a grouped catalog: a heading, its order,
+ *  and the id the portal has to send back in ICreateCustomerTicketDto. */
+export interface ICustomerRequestTypeCategoryView {
+    id: string;
+    name: string;
+    description?: string;
+    order: number;
+}
+/**
+ * One entry of the portal's catalog.
+ *
+ * A customer-safe projection of ITicketRequestType, built as an allowlist rather
+ * than by removing keys: the agent shape carries defaultAssignedGroupId (which
+ * internal group handles what), workflowId, slaPolicyId, audiencePolicyId,
+ * fieldDefinitionIds, layoutIds and the createdBy/updatedBy uuids of agents,
+ * none of which belong on a public surface.
+ *
+ * `formId` / `formVersion` travel because the portal renders the form.
+ * `defaultPriority` is a hint for preselection; the create endpoint applies its
+ * own default regardless.
+ */
+export interface ICustomerRequestTypeView {
+    id: string;
+    name: string;
+    description?: string;
+    icon?: string;
+    formId: string;
+    formVersion?: number;
+    defaultPriority?: TicketPriority;
+    category: ICustomerRequestTypeCategoryView;
+}
+/**
+ * One field of the portal's create form.
+ *
+ * Allowlist over ITicketFieldDefinition: classification, maskingStrategy,
+ * containsPii, readRoleIds, writeRoleIds, retentionPolicyId, conditions and the
+ * scope arrays stay server-side. `validation`, `options` and `objectFields` do
+ * travel — without them the portal cannot render a select or give the customer
+ * feedback before a round trip that ends in a 422.
+ *
+ * `required` is the EFFECTIVE value for the creation context, not the field's
+ * own flag: it already folds in requiredForStatusIds for the initial status and
+ * any condition that makes the field mandatory.
+ */
+export interface ICustomerFormFieldView {
+    nameKey: string;
+    label: string;
+    description?: string;
+    placeholder?: string;
+    type: TicketFieldType;
+    required: boolean;
+    defaultValue?: TicketPropertyValue;
+    options?: ITicketFieldOption[];
+    objectFields?: ITicketObjectField[];
+    validation?: ITicketFieldValidation;
+}
+/**
+ * What the portal renders so a customer can fill in `properties` on
+ * ICreateCustomerTicketDto.
+ *
+ * NO LAYOUT, unlike the agent form schema: layouts are selected by roleIds and a
+ * contact has no role, so "the effective layout for a customer" is not a
+ * question the layout model can answer. Presentation belongs to the portal; this
+ * answers membership, obligation and shape.
+ */
+export interface ICustomerFormSchemaView {
+    requestTypeId: string;
+    categoryId: string;
+    fields: ICustomerFormFieldView[];
+}
 /**
  * One file the portal declares BEFORE any byte exists in storage.
  *

package/package.json

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