@wix/events 1.0.334 → 1.0.335

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/events",
-  "version": "1.0.334",
+  "version": "1.0.335",
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",
     "access": "public"
@@ -24,7 +24,7 @@
     "@wix/events_categories": "1.0.49",
     "@wix/events_forms": "1.0.52",
     "@wix/events_guests": "1.0.76",
-    "@wix/events_notifications": "1.0.39",
+    "@wix/events_notifications": "1.0.40",
     "@wix/events_orders": "1.0.58",
     "@wix/events_policies": "1.0.47",
     "@wix/events_ricos": "1.0.14",
@@ -61,5 +61,5 @@
       "fqdn": ""
     }
   },
-  "falconPackageHash": "18bdc9328302789b15a219b8c371ead1bfd0c6d8fdf7ac93f132254a"
+  "falconPackageHash": "80af07a9e1b93628da4c5521c3c047a1646cf0be1dd49a42b2f27523"
 }

package/type-bundles/context.bundle.d.ts

@@ -2443,6 +2443,76 @@ interface RsvpUpdated$1 {
     /** Notifications silenced for this domain event. */
     silent?: boolean | null;
 }
+interface DomainEvent$8 extends DomainEventBodyOneOf$8 {
+    createdEvent?: EntityCreatedEvent$8;
+    updatedEvent?: EntityUpdatedEvent$8;
+    deletedEvent?: EntityDeletedEvent$8;
+    actionEvent?: ActionEvent$8;
+    /**
+     * Unique event ID.
+     * Allows clients to ignore duplicate webhooks.
+     */
+    _id?: string;
+    /**
+     * Assumes actions are also always typed to an entity_type
+     * Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction
+     */
+    entityFqdn?: string;
+    /**
+     * This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
+     * This is although the created/updated/deleted notion is duplication of the oneof types
+     * 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 defining the order of updates to the underlying entity.
+     * For example, given that some entity was updated at 16:00 and than again at 16:01,
+     * it is guaranteed that the sequence number of the second update is strictly higher than the first.
+     * As the consumer, you can use this value to ensure that you handle messages in the correct order.
+     * To do so, you will need to persist this number on your end, and compare the sequence number from the
+     * message against the one you have stored. Given that the stored number is higher, you should ignore the message.
+     */
+    entityEventSequence?: string | null;
+}
+/** @oneof */
+interface DomainEventBodyOneOf$8 {
+    createdEvent?: EntityCreatedEvent$8;
+    updatedEvent?: EntityUpdatedEvent$8;
+    deletedEvent?: EntityDeletedEvent$8;
+    actionEvent?: ActionEvent$8;
+}
+interface EntityCreatedEvent$8 {
+    entity?: string;
+}
+interface RestoreInfo$8 {
+    deletedDate?: Date | null;
+}
+interface EntityUpdatedEvent$8 {
+    /**
+     * 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.
+     */
+    currentEntity?: string;
+}
+interface EntityDeletedEvent$8 {
+    /** Entity that was deleted */
+    deletedEntity?: string | null;
+}
+interface ActionEvent$8 {
+    body?: string;
+}
 interface EventUpdated$3 {
     /** Event update timestamp in ISO UTC format. */
     timestamp?: Date | null;
@@ -3704,76 +3774,6 @@ interface OrderPaid$1 {
     /** Invoice. */
     invoice?: Invoice$1;
 }
-interface DomainEvent$8 extends DomainEventBodyOneOf$8 {
-    createdEvent?: EntityCreatedEvent$8;
-    updatedEvent?: EntityUpdatedEvent$8;
-    deletedEvent?: EntityDeletedEvent$8;
-    actionEvent?: ActionEvent$8;
-    /**
-     * Unique event ID.
-     * Allows clients to ignore duplicate webhooks.
-     */
-    _id?: string;
-    /**
-     * Assumes actions are also always typed to an entity_type
-     * Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction
-     */
-    entityFqdn?: string;
-    /**
-     * This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
-     * This is although the created/updated/deleted notion is duplication of the oneof types
-     * 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 defining the order of updates to the underlying entity.
-     * For example, given that some entity was updated at 16:00 and than again at 16:01,
-     * it is guaranteed that the sequence number of the second update is strictly higher than the first.
-     * As the consumer, you can use this value to ensure that you handle messages in the correct order.
-     * To do so, you will need to persist this number on your end, and compare the sequence number from the
-     * message against the one you have stored. Given that the stored number is higher, you should ignore the message.
-     */
-    entityEventSequence?: string | null;
-}
-/** @oneof */
-interface DomainEventBodyOneOf$8 {
-    createdEvent?: EntityCreatedEvent$8;
-    updatedEvent?: EntityUpdatedEvent$8;
-    deletedEvent?: EntityDeletedEvent$8;
-    actionEvent?: ActionEvent$8;
-}
-interface EntityCreatedEvent$8 {
-    entity?: string;
-}
-interface RestoreInfo$8 {
-    deletedDate?: Date | null;
-}
-interface EntityUpdatedEvent$8 {
-    /**
-     * 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.
-     */
-    currentEntity?: string;
-}
-interface EntityDeletedEvent$8 {
-    /** Entity that was deleted */
-    deletedEntity?: string | null;
-}
-interface ActionEvent$8 {
-    body?: string;
-}
 interface TicketPdfResolved {
     /** Optional order number */
     orderNumber?: string | null;

package/type-bundles/index.bundle.d.ts

@@ -2443,6 +2443,76 @@ interface RsvpUpdated$1 {
     /** Notifications silenced for this domain event. */
     silent?: boolean | null;
 }
+interface DomainEvent$8 extends DomainEventBodyOneOf$8 {
+    createdEvent?: EntityCreatedEvent$8;
+    updatedEvent?: EntityUpdatedEvent$8;
+    deletedEvent?: EntityDeletedEvent$8;
+    actionEvent?: ActionEvent$8;
+    /**
+     * Unique event ID.
+     * Allows clients to ignore duplicate webhooks.
+     */
+    _id?: string;
+    /**
+     * Assumes actions are also always typed to an entity_type
+     * Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction
+     */
+    entityFqdn?: string;
+    /**
+     * This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
+     * This is although the created/updated/deleted notion is duplication of the oneof types
+     * 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 defining the order of updates to the underlying entity.
+     * For example, given that some entity was updated at 16:00 and than again at 16:01,
+     * it is guaranteed that the sequence number of the second update is strictly higher than the first.
+     * As the consumer, you can use this value to ensure that you handle messages in the correct order.
+     * To do so, you will need to persist this number on your end, and compare the sequence number from the
+     * message against the one you have stored. Given that the stored number is higher, you should ignore the message.
+     */
+    entityEventSequence?: string | null;
+}
+/** @oneof */
+interface DomainEventBodyOneOf$8 {
+    createdEvent?: EntityCreatedEvent$8;
+    updatedEvent?: EntityUpdatedEvent$8;
+    deletedEvent?: EntityDeletedEvent$8;
+    actionEvent?: ActionEvent$8;
+}
+interface EntityCreatedEvent$8 {
+    entity?: string;
+}
+interface RestoreInfo$8 {
+    deletedDate?: Date | null;
+}
+interface EntityUpdatedEvent$8 {
+    /**
+     * 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.
+     */
+    currentEntity?: string;
+}
+interface EntityDeletedEvent$8 {
+    /** Entity that was deleted */
+    deletedEntity?: string | null;
+}
+interface ActionEvent$8 {
+    body?: string;
+}
 interface EventUpdated$3 {
     /** Event update timestamp in ISO UTC format. */
     timestamp?: Date | null;
@@ -3704,76 +3774,6 @@ interface OrderPaid$1 {
     /** Invoice. */
     invoice?: Invoice$1;
 }
-interface DomainEvent$8 extends DomainEventBodyOneOf$8 {
-    createdEvent?: EntityCreatedEvent$8;
-    updatedEvent?: EntityUpdatedEvent$8;
-    deletedEvent?: EntityDeletedEvent$8;
-    actionEvent?: ActionEvent$8;
-    /**
-     * Unique event ID.
-     * Allows clients to ignore duplicate webhooks.
-     */
-    _id?: string;
-    /**
-     * Assumes actions are also always typed to an entity_type
-     * Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction
-     */
-    entityFqdn?: string;
-    /**
-     * This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
-     * This is although the created/updated/deleted notion is duplication of the oneof types
-     * 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 defining the order of updates to the underlying entity.
-     * For example, given that some entity was updated at 16:00 and than again at 16:01,
-     * it is guaranteed that the sequence number of the second update is strictly higher than the first.
-     * As the consumer, you can use this value to ensure that you handle messages in the correct order.
-     * To do so, you will need to persist this number on your end, and compare the sequence number from the
-     * message against the one you have stored. Given that the stored number is higher, you should ignore the message.
-     */
-    entityEventSequence?: string | null;
-}
-/** @oneof */
-interface DomainEventBodyOneOf$8 {
-    createdEvent?: EntityCreatedEvent$8;
-    updatedEvent?: EntityUpdatedEvent$8;
-    deletedEvent?: EntityDeletedEvent$8;
-    actionEvent?: ActionEvent$8;
-}
-interface EntityCreatedEvent$8 {
-    entity?: string;
-}
-interface RestoreInfo$8 {
-    deletedDate?: Date | null;
-}
-interface EntityUpdatedEvent$8 {
-    /**
-     * 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.
-     */
-    currentEntity?: string;
-}
-interface EntityDeletedEvent$8 {
-    /** Entity that was deleted */
-    deletedEntity?: string | null;
-}
-interface ActionEvent$8 {
-    body?: string;
-}
 interface TicketPdfResolved {
     /** Optional order number */
     orderNumber?: string | null;