@wix/auto_sdk_members_members 1.0.113 → 1.0.115

package/build/cjs/meta.d.ts

@@ -962,70 +962,6 @@ interface DeleteMemberAddressesResponse {
 }
 interface Empty {
 }
-interface DomainEvent extends DomainEventBodyOneOf {
-    createdEvent?: EntityCreatedEvent;
-    updatedEvent?: EntityUpdatedEvent;
-    deletedEvent?: EntityDeletedEvent;
-    actionEvent?: ActionEvent;
-    /** Event ID. With this ID you can easily spot duplicated events and ignore them. */
-    id?: string;
-    /**
-     * Fully Qualified Domain Name of an entity. This is a unique identifier assigned to the API main business entities.
-     * For example, `wix.stores.catalog.product`, `wix.bookings.session`, `wix.payments.transaction`.
-     */
-    entityFqdn?: string;
-    /**
-     * Event action name, placed at the top level to make it easier for users to dispatch messages.
-     * For example: `created`/`updated`/`deleted`/`started`/`completed`/`email_opened`.
-     */
-    slug?: string;
-    /** ID of the entity associated with the event. */
-    entityId?: string;
-    /** Event timestamp in [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) format and UTC time. For example, `2020-04-26T13:57:50.699Z`. */
-    eventTime?: Date | null;
-    /**
-     * Whether the event was triggered as a result of a privacy regulation application
-     * (for example, GDPR).
-     */
-    triggeredByAnonymizeRequest?: boolean | null;
-    /** If present, indicates the action that triggered the event. */
-    originatedFrom?: string | null;
-    /**
-     * A sequence number that indicates the order of updates to an entity. For example, if an entity was updated at 16:00 and then again at 16:01, the second update will always have a higher sequence number.
-     * You can use this number to make sure you're handling updates in the right order. Just save the latest sequence number on your end and compare it to the one in each new message. If the new message has an older (lower) number, you can safely ignore it.
-     */
-    entityEventSequence?: string | null;
-}
-/** @oneof */
-interface DomainEventBodyOneOf {
-    createdEvent?: EntityCreatedEvent;
-    updatedEvent?: EntityUpdatedEvent;
-    deletedEvent?: EntityDeletedEvent;
-    actionEvent?: ActionEvent;
-}
-interface EntityCreatedEvent {
-    entityAsJson?: string;
-    /** Indicates the event was triggered by a restore-from-trashbin operation for a previously deleted entity */
-    restoreInfo?: RestoreInfo;
-}
-interface RestoreInfo {
-    deletedDate?: Date | null;
-}
-interface EntityUpdatedEvent {
-    /**
-     * Since platformized APIs only expose PATCH and not PUT we can't assume that the fields sent from the client are the actual diff.
-     * This means that to generate a list of changed fields (as opposed to sent fields) one needs to traverse both objects.
-     * We don't want to impose this on all developers and so we leave this traversal to the notification recipients which need it.
-     */
-    currentEntityAsJson?: string;
-}
-interface EntityDeletedEvent {
-    /** Entity that was deleted. */
-    deletedEntityAsJson?: string | null;
-}
-interface ActionEvent {
-    bodyAsJson?: string;
-}
 interface MetaSiteSpecialEvent extends MetaSiteSpecialEventPayloadOneOf {
     /** Emitted on a meta site creation. */
     siteCreated?: SiteCreated;
@@ -1553,6 +1489,70 @@ interface MemberOwnershipTransferred {
     fromMember?: Member;
     toMember?: Member;
 }
+interface DomainEvent extends DomainEventBodyOneOf {
+    createdEvent?: EntityCreatedEvent;
+    updatedEvent?: EntityUpdatedEvent;
+    deletedEvent?: EntityDeletedEvent;
+    actionEvent?: ActionEvent;
+    /** Event ID. With this ID you can easily spot duplicated events and ignore them. */
+    id?: string;
+    /**
+     * Fully Qualified Domain Name of an entity. This is a unique identifier assigned to the API main business entities.
+     * For example, `wix.stores.catalog.product`, `wix.bookings.session`, `wix.payments.transaction`.
+     */
+    entityFqdn?: string;
+    /**
+     * Event action name, placed at the top level to make it easier for users to dispatch messages.
+     * For example: `created`/`updated`/`deleted`/`started`/`completed`/`email_opened`.
+     */
+    slug?: string;
+    /** ID of the entity associated with the event. */
+    entityId?: string;
+    /** Event timestamp in [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) format and UTC time. For example, `2020-04-26T13:57:50.699Z`. */
+    eventTime?: Date | null;
+    /**
+     * Whether the event was triggered as a result of a privacy regulation application
+     * (for example, GDPR).
+     */
+    triggeredByAnonymizeRequest?: boolean | null;
+    /** If present, indicates the action that triggered the event. */
+    originatedFrom?: string | null;
+    /**
+     * A sequence number that indicates the order of updates to an entity. For example, if an entity was updated at 16:00 and then again at 16:01, the second update will always have a higher sequence number.
+     * You can use this number to make sure you're handling updates in the right order. Just save the latest sequence number on your end and compare it to the one in each new message. If the new message has an older (lower) number, you can safely ignore it.
+     */
+    entityEventSequence?: string | null;
+}
+/** @oneof */
+interface DomainEventBodyOneOf {
+    createdEvent?: EntityCreatedEvent;
+    updatedEvent?: EntityUpdatedEvent;
+    deletedEvent?: EntityDeletedEvent;
+    actionEvent?: ActionEvent;
+}
+interface EntityCreatedEvent {
+    entityAsJson?: string;
+    /** Indicates the event was triggered by a restore-from-trashbin operation for a previously deleted entity */
+    restoreInfo?: RestoreInfo;
+}
+interface RestoreInfo {
+    deletedDate?: Date | null;
+}
+interface EntityUpdatedEvent {
+    /**
+     * Since platformized APIs only expose PATCH and not PUT we can't assume that the fields sent from the client are the actual diff.
+     * This means that to generate a list of changed fields (as opposed to sent fields) one needs to traverse both objects.
+     * We don't want to impose this on all developers and so we leave this traversal to the notification recipients which need it.
+     */
+    currentEntityAsJson?: string;
+}
+interface EntityDeletedEvent {
+    /** Entity that was deleted. */
+    deletedEntityAsJson?: string | null;
+}
+interface ActionEvent {
+    bodyAsJson?: string;
+}
 interface MemberIdChanged {
     /** @format GUID */
     fromId?: string;