@remit/api-openapi-types 0.0.42 → 0.0.43

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.42",
+  "version": "0.0.43",
   "type": "module",
   "main": "types.d.ts",
   "types": "types.d.ts",

package/types.d.ts

@@ -261,6 +261,18 @@ distinguishable from a network failure without parsing prose.
      * Manual bulk label action (issue #26) — apply or remove a label on a `just these` selection. Never sets `appliedByFilterId`: that field is reserved for filter-driven applies (RFC 034 Decision 3.3).
      */
     export type LabelAction = "Apply" | "Remove";
+    /**
+     * What has become of a suggestion. `Pending` is the only state that asks a person for anything; every other value is a decision already taken, and nothing but an explicit act moves a suggestion out of `Pending`.
+     */
+    export type CalendarSuggestionState = "Pending" | "Accepted" | "Declined" | "Tentative" | "Dismissed" | "Superseded";
+    /**
+     * The iTIP method a scheduling message carries (RFC 5546 3.2), read from the VCALENDAR's METHOD property. It says what the sender is asking for, which is not derivable from the VEVENT: a cancellation and an invitation differ by this property alone.
+     */
+    export type CalendarInviteMethod = "Request" | "Reply" | "Cancel" | "Counter" | "Publish" | "None";
+    /**
+     * Where in a message a suggestion was read from. It is what a card says to explain itself, and it is what separates a suggestion carrying real iCalendar from one inferred out of prose.
+     */
+    export type CalendarSuggestionSource = "IcalendarPart" | "IcalendarAttachment" | "TextHeuristic";
     /**
      * System message flags defined in RFC 9051 Section 2.3.2 - MUST be supported by all servers
      */
@@ -4844,6 +4856,198 @@ either way and cannot tell which it received.
        */
       reason: string;
     }
+    /**
+     * An event a message offers, waiting on a person (issue #1033).
+
+A suggestion is not a calendar entry and never becomes one on its own. It is
+derived from a message, lives beside it, and belongs to no collection: it has
+no etag, no sync sequence, and a DAV client never sees one. Nothing reaches a
+calendar until someone presses the button, which is what separates this
+entity from `CalendarObject` — the two are distinct models rather than one
+model with a kind field, because everything that makes a stored resource a
+resource is exactly what a suggestion does not have.
+
+`suggestionId` is derived from `(messageId, bodyPartId, icalUid)`, so a
+re-sync of the same message converges on the one row it wrote the first time
+instead of stacking a fresh card on the message every pass.
+
+Revisions are a chain, not an edit. A later message carrying the same
+`icalUid` with a higher `SEQUENCE` leaves the earlier suggestion in place as
+`Superseded` and writes a new `Pending` one, so the message the older card
+came from still has its card and the user can see which revision they are
+being asked about. `METHOD:CANCEL` is a suggestion of its own for the same
+reason: withdrawing an event the user accepted is a change to their calendar,
+and no message may make that change without them.
+     */
+    export interface CalendarSuggestion {
+      /**
+       * Primary identifier, derived from messageId + bodyPartId + icalUid
+       */
+      suggestionId: UUID;
+      /**
+       * Owning account configuration
+       */
+      accountConfigId: UUID;
+      /**
+       * Message this suggestion was read out of. The card is offered beside this message and nowhere else.
+       */
+      messageId: UUID;
+      /**
+       * MIME part the iCalendar bytes came from. Part of the identity, so two invitations in one message stay two suggestions rather than overwriting each other.
+       */
+      bodyPartId: UUID;
+      /**
+       * The VEVENT's UID property (RFC 5545 3.8.4.7). What ties a revision, a cancellation and the original invitation together across three separate messages.
+       */
+      icalUid: String512;
+      /**
+       * The VEVENT's SEQUENCE property (RFC 5545 3.8.7.4) — the organizer's revision counter. A later message carrying the same `icalUid` with a higher value supersedes this one. `0` when the event declares none, which is the RFC default.
+       */
+      sequence: number;
+      /**
+       * The iTIP method the VCALENDAR declared. `None` when it declared no METHOD.
+       */
+      method: CalendarInviteMethod;
+      /**
+       * Where in the message this was read from
+       */
+      source: CalendarSuggestionSource;
+      /**
+       * What has become of this suggestion. Only `Pending` asks the user for anything.
+       */
+      state: CalendarSuggestionState;
+      /**
+       * Projection of the VEVENT's SUMMARY. `""` when the event carries none.
+       */
+      summary: String512;
+      /**
+       * Projection of the VEVENT's DTSTART as an ISO 8601 date-time with zone offset — a business date, not an epoch instant. An all-day event carries midnight in the event's own zone.
+       */
+      dtStart: String64;
+      /**
+       * Projection of the VEVENT's effective end as an ISO 8601 date-time with zone offset, resolved from DTEND or from DTSTART + DURATION. An event with neither ends when it starts (RFC 5545 3.6.1).
+       */
+      dtEnd: String64;
+      /**
+       * Whether DTSTART is a DATE rather than a DATE-TIME (RFC 5545 3.3.4) — an all-day or multi-day event, whose end is exclusive.
+       */
+      allDay: boolean;
+      /**
+       * Projection of the VEVENT's LOCATION. `""` when the event carries none.
+       */
+      location: String512;
+      /**
+       * Mail address of the VEVENT's ORGANIZER, without the `mailto:` scheme. `""` when the event names none — which is what a `PUBLISH` typically looks like, and why dismissing with `muteSender` mutes the message's sender rather than this field.
+       */
+      organizer: String256;
+      /**
+       * How the DTSTART above was placed on the clock. `Ambiguous` means the invitation named a zone nothing could resolve, so the time shown may be hours out — a card says so rather than presenting a guess as a fact.
+       */
+      zoneCertainty: ZoneCertainty;
+      /**
+       * The VCALENDAR text as it arrived in the message, byte for byte — CANONICAL when present. Accepting builds the stored resource out of these bytes, so an X- property nobody modelled survives into the calendar. `""` for a `TextHeuristic` suggestion, which was read out of prose and has no iCalendar behind it.
+       */
+      icalData: string;
+      /**
+       * The `CalendarObject` that accepting this suggestion wrote. `""` until it is accepted — the named absent state, never a missing attribute — and the resource's id afterwards, so the card can link to the event it produced.
+       */
+      acceptedCalendarObjectId: string;
+      createdAt: number;
+      updatedAt: number;
+    }
+    /**
+     * A suggestion as the API returns it. The raw `icalData` is not surfaced: a client renders the projected fields, and the bytes exist so that accepting can write them into a calendar unchanged.
+     */
+    export interface CalendarSuggestionResponse {
+      /**
+       * Primary identifier, derived from messageId + bodyPartId + icalUid
+       */
+      suggestionId: UUID;
+      /**
+       * Owning account configuration
+       */
+      accountConfigId: UUID;
+      /**
+       * Message this suggestion was read out of. The card is offered beside this message and nowhere else.
+       */
+      messageId: UUID;
+      /**
+       * MIME part the iCalendar bytes came from. Part of the identity, so two invitations in one message stay two suggestions rather than overwriting each other.
+       */
+      bodyPartId: UUID;
+      /**
+       * The VEVENT's UID property (RFC 5545 3.8.4.7). What ties a revision, a cancellation and the original invitation together across three separate messages.
+       */
+      icalUid: String512;
+      /**
+       * The VEVENT's SEQUENCE property (RFC 5545 3.8.7.4) — the organizer's revision counter. A later message carrying the same `icalUid` with a higher value supersedes this one. `0` when the event declares none, which is the RFC default.
+       */
+      sequence: number;
+      /**
+       * The iTIP method the VCALENDAR declared. `None` when it declared no METHOD.
+       */
+      method: CalendarInviteMethod;
+      /**
+       * Where in the message this was read from
+       */
+      source: CalendarSuggestionSource;
+      /**
+       * What has become of this suggestion. Only `Pending` asks the user for anything.
+       */
+      state: CalendarSuggestionState;
+      /**
+       * Projection of the VEVENT's SUMMARY. `""` when the event carries none.
+       */
+      summary: String512;
+      /**
+       * Projection of the VEVENT's DTSTART as an ISO 8601 date-time with zone offset — a business date, not an epoch instant. An all-day event carries midnight in the event's own zone.
+       */
+      dtStart: String64;
+      /**
+       * Projection of the VEVENT's effective end as an ISO 8601 date-time with zone offset, resolved from DTEND or from DTSTART + DURATION. An event with neither ends when it starts (RFC 5545 3.6.1).
+       */
+      dtEnd: String64;
+      /**
+       * Whether DTSTART is a DATE rather than a DATE-TIME (RFC 5545 3.3.4) — an all-day or multi-day event, whose end is exclusive.
+       */
+      allDay: boolean;
+      /**
+       * Projection of the VEVENT's LOCATION. `""` when the event carries none.
+       */
+      location: String512;
+      /**
+       * Mail address of the VEVENT's ORGANIZER, without the `mailto:` scheme. `""` when the event names none — which is what a `PUBLISH` typically looks like, and why dismissing with `muteSender` mutes the message's sender rather than this field.
+       */
+      organizer: String256;
+      /**
+       * How the DTSTART above was placed on the clock. `Ambiguous` means the invitation named a zone nothing could resolve, so the time shown may be hours out — a card says so rather than presenting a guess as a fact.
+       */
+      zoneCertainty: ZoneCertainty;
+      /**
+       * The `CalendarObject` that accepting this suggestion wrote. `""` until it is accepted — the named absent state, never a missing attribute — and the resource's id afterwards, so the card can link to the event it produced.
+       */
+      acceptedCalendarObjectId: string;
+      createdAt: number;
+      updatedAt: number;
+    }
+    /**
+     * Body of `POST /calendar-suggestions/{suggestionId}/accept`. Names the collection the event is written into; there is no default, because filing someone else's invitation into a calendar the user did not pick is a decision the server does not get to make.
+     */
+    export interface AcceptCalendarSuggestionInput {
+      /**
+       * Collection the accepted event is written into.
+       */
+      calendarId: UUID;
+    }
+    /**
+     * Body of `POST /calendar-suggestions/{suggestionId}/dismiss`.
+     */
+    export interface DismissCalendarSuggestionInput {
+      /**
+       * Also stop offering invitations from this message's sender, by writing a standing `Filter` rule. `false` dismisses this one card and nothing else.
+       */
+      muteSender: boolean;
+    }
     /**
      * Junction table linking envelope addresses to normalized addresses. Stores per-message display name since it may vary.
      */
@@ -6279,6 +6483,54 @@ declare namespace Paths {
       export type $200 = void;
     }
   }
+  namespace ListCalendarSuggestions {
+    export interface QueryParameters {
+      state: Components.Schemas.CalendarSuggestionState;
+      continuationToken?: string;
+    }
+    namespace Responses {
+      export type $200 = void;
+      export type $400 = void;
+    }
+  }
+  namespace ListMessageCalendarSuggestions {
+    export interface PathParameters {
+      messageId: Components.Schemas.UUID;
+    }
+    namespace Responses {
+      export type $200 = void;
+      export type $400 = void;
+    }
+  }
+  namespace AcceptCalendarSuggestion {
+    export interface PathParameters {
+      suggestionId: Components.Schemas.UUID;
+    }
+    export type RequestBody = Components.Schemas.AcceptCalendarSuggestionInput;
+    namespace Responses {
+      export type $200 = void;
+      export type $400 = void;
+    }
+  }
+  namespace DeclineCalendarSuggestion {
+    export interface PathParameters {
+      suggestionId: Components.Schemas.UUID;
+    }
+    namespace Responses {
+      export type $200 = void;
+      export type $400 = void;
+    }
+  }
+  namespace DismissCalendarSuggestion {
+    export interface PathParameters {
+      suggestionId: Components.Schemas.UUID;
+    }
+    export type RequestBody = Components.Schemas.DismissCalendarSuggestionInput;
+    namespace Responses {
+      export type $200 = void;
+      export type $400 = void;
+    }
+  }
 }
 
 export interface OperationMethods {
@@ -6926,6 +7178,61 @@ Callers that omit `query` are unaffected: the INBOX (and starred) listings behav
     data?: Paths.NotSpam.RequestBody,
     config?: AxiosRequestConfig
   ): OperationResponse<Paths.NotSpam.Responses.$200>;
+  /**
+   * listCalendarSuggestions - List the caller's suggestions in one state, newest first. `Pending` is the set that is waiting on a person and the one a client normally asks for.
+   */
+  'listCalendarSuggestions'(
+    parameters?: Parameters<Paths.ListCalendarSuggestions.QueryParameters> | null,
+    data?: any,
+    config?: AxiosRequestConfig
+  ): OperationResponse<Paths.ListCalendarSuggestions.Responses.$200>;
+  /**
+   * listMessageCalendarSuggestions - Every suggestion read out of one message, in whatever state each has reached — a superseded revision included, so the card can say which revision replaced it.
+   */
+  'listMessageCalendarSuggestions'(
+    parameters?: Parameters<Paths.ListMessageCalendarSuggestions.PathParameters> | null,
+    data?: any,
+    config?: AxiosRequestConfig
+  ): OperationResponse<Paths.ListMessageCalendarSuggestions.Responses.$200>;
+  /**
+   * acceptCalendarSuggestion - Add the suggested event to a calendar. One transaction: a VCALENDAR is
+built from the invitation's own bytes, keeping its UID and SEQUENCE and
+marking the user `ATTENDEE;PARTSTAT=ACCEPTED`, and written through the
+same service function every other calendar write goes through — so a web
+edit and a native edit of that event cannot diverge. Accepting a `Cancel`
+suggestion writes `STATUS:CANCELLED` on the resource the same way.
+
+No reply is sent to the organizer. This endpoint sends no mail at all,
+and the card says so.
+
+Idempotent: accepting an already-accepted suggestion rewrites the same
+resource and returns the same suggestion, because both the resource id
+and the suggestion id are derived rather than minted.
+
+400 when the suggestion is not one that can be accepted — already
+declined, dismissed or superseded — or when its iCalendar will not parse.
+   */
+  'acceptCalendarSuggestion'(
+    parameters?: Parameters<Paths.AcceptCalendarSuggestion.PathParameters> | null,
+    data?: Paths.AcceptCalendarSuggestion.RequestBody,
+    config?: AxiosRequestConfig
+  ): OperationResponse<Paths.AcceptCalendarSuggestion.Responses.$200>;
+  /**
+   * declineCalendarSuggestion - Say no. Writes no calendar object and sends no reply to the organizer. Idempotent; 400 when the suggestion was already accepted, since a resource exists and declining would not remove it.
+   */
+  'declineCalendarSuggestion'(
+    parameters?: Parameters<Paths.DeclineCalendarSuggestion.PathParameters> | null,
+    data?: any,
+    config?: AxiosRequestConfig
+  ): OperationResponse<Paths.DeclineCalendarSuggestion.Responses.$200>;
+  /**
+   * dismissCalendarSuggestion - Wave the card away. Writes no calendar object. With `muteSender`, also writes a standing `Filter` rule on the message's sender so their invitations stop being offered. Idempotent; 400 when the suggestion was already accepted.
+   */
+  'dismissCalendarSuggestion'(
+    parameters?: Parameters<Paths.DismissCalendarSuggestion.PathParameters> | null,
+    data?: Paths.DismissCalendarSuggestion.RequestBody,
+    config?: AxiosRequestConfig
+  ): OperationResponse<Paths.DismissCalendarSuggestion.Responses.$200>;
 }
 
 export interface PathsDictionary {
@@ -7681,6 +7988,71 @@ Callers that omit `query` are unaffected: the INBOX (and starred) listings behav
       config?: AxiosRequestConfig
     ): OperationResponse<Paths.NotSpam.Responses.$200>;
   };
+  ['/calendar-suggestions']: {
+    /**
+     * listCalendarSuggestions - List the caller's suggestions in one state, newest first. `Pending` is the set that is waiting on a person and the one a client normally asks for.
+     */
+    'get'(
+      parameters?: Parameters<Paths.ListCalendarSuggestions.QueryParameters> | null,
+      data?: any,
+      config?: AxiosRequestConfig
+    ): OperationResponse<Paths.ListCalendarSuggestions.Responses.$200>;
+  };
+  ['/messages/{messageId}/calendar-suggestions']: {
+    /**
+     * listMessageCalendarSuggestions - Every suggestion read out of one message, in whatever state each has reached — a superseded revision included, so the card can say which revision replaced it.
+     */
+    'get'(
+      parameters?: Parameters<Paths.ListMessageCalendarSuggestions.PathParameters> | null,
+      data?: any,
+      config?: AxiosRequestConfig
+    ): OperationResponse<Paths.ListMessageCalendarSuggestions.Responses.$200>;
+  };
+  ['/calendar-suggestions/{suggestionId}/accept']: {
+    /**
+     * acceptCalendarSuggestion - Add the suggested event to a calendar. One transaction: a VCALENDAR is
+built from the invitation's own bytes, keeping its UID and SEQUENCE and
+marking the user `ATTENDEE;PARTSTAT=ACCEPTED`, and written through the
+same service function every other calendar write goes through — so a web
+edit and a native edit of that event cannot diverge. Accepting a `Cancel`
+suggestion writes `STATUS:CANCELLED` on the resource the same way.
+
+No reply is sent to the organizer. This endpoint sends no mail at all,
+and the card says so.
+
+Idempotent: accepting an already-accepted suggestion rewrites the same
+resource and returns the same suggestion, because both the resource id
+and the suggestion id are derived rather than minted.
+
+400 when the suggestion is not one that can be accepted — already
+declined, dismissed or superseded — or when its iCalendar will not parse.
+     */
+    'post'(
+      parameters?: Parameters<Paths.AcceptCalendarSuggestion.PathParameters> | null,
+      data?: Paths.AcceptCalendarSuggestion.RequestBody,
+      config?: AxiosRequestConfig
+    ): OperationResponse<Paths.AcceptCalendarSuggestion.Responses.$200>;
+  };
+  ['/calendar-suggestions/{suggestionId}/decline']: {
+    /**
+     * declineCalendarSuggestion - Say no. Writes no calendar object and sends no reply to the organizer. Idempotent; 400 when the suggestion was already accepted, since a resource exists and declining would not remove it.
+     */
+    'post'(
+      parameters?: Parameters<Paths.DeclineCalendarSuggestion.PathParameters> | null,
+      data?: any,
+      config?: AxiosRequestConfig
+    ): OperationResponse<Paths.DeclineCalendarSuggestion.Responses.$200>;
+  };
+  ['/calendar-suggestions/{suggestionId}/dismiss']: {
+    /**
+     * dismissCalendarSuggestion - Wave the card away. Writes no calendar object. With `muteSender`, also writes a standing `Filter` rule on the message's sender so their invitations stop being offered. Idempotent; 400 when the suggestion was already accepted.
+     */
+    'post'(
+      parameters?: Parameters<Paths.DismissCalendarSuggestion.PathParameters> | null,
+      data?: Paths.DismissCalendarSuggestion.RequestBody,
+      config?: AxiosRequestConfig
+    ): OperationResponse<Paths.DismissCalendarSuggestion.Responses.$200>;
+  };
 }
 
 export type Client = OpenAPIClient<OperationMethods, PathsDictionary>;
@@ -7826,6 +8198,10 @@ export type CopyMessagesInput = Components.Schemas.CopyMessagesInput;
 export type UpdateMessageLabelsInput = Components.Schemas.UpdateMessageLabelsInput;
 export type SpamReportBulkResult = Components.Schemas.SpamReportBulkResult;
 export type SpamReportFailure = Components.Schemas.SpamReportFailure;
+export type CalendarSuggestion = Components.Schemas.CalendarSuggestion;
+export type CalendarSuggestionResponse = Components.Schemas.CalendarSuggestionResponse;
+export type AcceptCalendarSuggestionInput = Components.Schemas.AcceptCalendarSuggestionInput;
+export type DismissCalendarSuggestionInput = Components.Schemas.DismissCalendarSuggestionInput;
 export type EnvelopeAddress = Components.Schemas.EnvelopeAddress;
 export type ConfigImportUnresolvedRef = Components.Schemas.ConfigImportUnresolvedRef;
 export type ConfigImport = Components.Schemas.ConfigImport;
@@ -7909,6 +8285,9 @@ export type ContentDisposition = Components.Schemas.ContentDisposition;
 export type MultipartSubtype = Components.Schemas.MultipartSubtype;
 export type ReferenceType = Components.Schemas.ReferenceType;
 export type LabelAction = Components.Schemas.LabelAction;
+export type CalendarSuggestionState = Components.Schemas.CalendarSuggestionState;
+export type CalendarInviteMethod = Components.Schemas.CalendarInviteMethod;
+export type CalendarSuggestionSource = Components.Schemas.CalendarSuggestionSource;
 export type MessageSystemFlag = Components.Schemas.MessageSystemFlag;
 export type MessageKeywordFlag = Components.Schemas.MessageKeywordFlag;
 export type MailboxAttribute = Components.Schemas.MailboxAttribute;