talon_one 2.1.1 → 2.2.0

data/lib/talon_one/models/webhook.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/lib/talon_one/models/webhook_activation_log_entry.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/lib/talon_one/models/webhook_log_entry.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/lib/talon_one/version.rb

@@ -6,10 +6,10 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
 module TalonOne
-  VERSION = '2.1.1'
+  VERSION = '2.2.0'
 end

data/spec/api/integration_api_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -90,6 +90,7 @@ describe 'IntegrationApi' do
   # @option opts [Boolean] :profile optional flag to decide if you would like customer profile information in the response
   # @option opts [Boolean] :referrals optional flag to decide if you would like referral information in the response
   # @option opts [Boolean] :coupons optional flag to decide if you would like coupon information in the response
+  # @option opts [Boolean] :loyalty optional flag to decide if you would like loyalty information in the response
   # @return [CustomerInventory]
   describe 'get_customer_inventory test' do
     it 'should work' do
@@ -123,8 +124,8 @@ describe 'IntegrationApi' do
   end
 
   # unit tests for update_customer_profile
-  # Update a Customer Profile
-  # Update (or create) a [Customer Profile][]. This profile information can then be matched and/or updated by campaign [Rules][].  The `integrationId` may be any identifier that will remain stable for the customer. For example, you might use a database ID, an email, or a phone number as the `integrationId`. It is vital that this ID **not** change over time, so **don't** use any identifier that the customer can update themselves. E.g. if your application allows a customer to update their e-mail address, you should instead use a database ID.  Updating a customer profile will return a response with the full integration state. This includes the current state of the customer profile, the customer session, the event that was recorded, and an array of effects that took place.  [Customer Profile]: /Getting-Started/entities#customer-profile [Rules]: /Getting-Started/entities#campaigns-rulesets-and-coupons 
+  # Update a Customer Profile V1
+  # ⚠️ Deprecation Notice: Support for requests to this endpoint will end on 15.07.2021. We will not remove the endpoint, and it will still be accessible for you to use. For new features support, please migrate to [API V2.0](/Getting-Started/APIV2).  Update (or create) a [Customer Profile][]. This profile information can then be matched and/or updated by campaign [Rules][].  The `integrationId` may be any identifier that will remain stable for the customer. For example, you might use a database ID, an email, or a phone number as the `integrationId`. It is vital that this ID **not** change over time, so **don't** use any identifier that the customer can update themselves. E.g. if your application allows a customer to update their e-mail address, you should instead use a database ID.  Updating a customer profile will return a response with the full integration state. This includes the current state of the customer profile, the customer session, the event that was recorded, and an array of effects that took place.  [Customer Profile]: /Getting-Started/entities#customer-profile [Rules]: /Getting-Started/entities#campaigns-rulesets-and-coupons 
   # @param integration_id The custom identifier for this profile, must be unique within the account.
   # @param body 
   # @param [Hash] opts the optional parameters
@@ -136,22 +137,49 @@ describe 'IntegrationApi' do
     end
   end
 
+  # unit tests for update_customer_profile_audiences
+  # Update a Customer Profile Audiences
+  # Update one ore multiple Customer Profiles with the specified Audiences 
+  # @param body 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'update_customer_profile_audiences test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
   # unit tests for update_customer_profile_v2
   # Update a Customer Profile
-  # Update (or create) a [Customer Profile][].   The `integrationId` may be any identifier that will remain stable for the customer. For example, you might use a database ID, an email, or a phone number as the `integrationId`. It is vital that this ID **not** change over time, so **don't** use any identifier that the customer can update themselves. E.g. if your application allows a customer to update their e-mail address, you should instead use a database ID.  [Customer Profile]: /Getting-Started/entities#customer-profile 
-  # @param customer_profile_id The custom identifier for this profile, must be unique within the account.
+  # Update (or create) a [Customer Profile][].  The `integrationId` may be any identifier that will remain stable for the customer. For example, you might use a database ID, an email, or a phone number as the `integrationId`. It is vital that this ID **not** change over time, so **don't** use any identifier that the customer can update themselves. E.g. if your application allows a customer to update their e-mail address, you should instead use a database ID.  [Customer Profile]: /Getting-Started/entities#customer-profile 
+  # @param integration_id The custom identifier for this profile, must be unique within the account.
   # @param body 
   # @param [Hash] opts the optional parameters
-  # @return [CustomerProfileUpdate]
+  # @option opts [Boolean] :run_rule_engine Flag to indicate whether to run the rule engine (Defaults to false).
+  # @option opts [Boolean] :dry Flag to indicate whether to skip persisting the changes or not (Will not persist if set to 'true'. Only used when 'runRuleEngine' is set to 'true').
+  # @return [IntegrationStateV2]
   describe 'update_customer_profile_v2 test' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
+  # unit tests for update_customer_profiles_v2
+  # Update multiple Customer Profiles
+  # Update (or create) up to 1000 [Customer Profiles][] in 1 request.  The `integrationId` may be any identifier that will remain stable for the customer. For example, you might use a database ID, an email, or a phone number as the `integrationId`. It is vital that this ID **not** change over time, so **don't** use any identifier that the customer can update themselves. E.g. if your application allows a customer to update their e-mail address, you should instead use a database ID.  [Customer Profiles]: /Getting-Started/entities#customer-profile 
+  # @param body 
+  # @param [Hash] opts the optional parameters
+  # @option opts [String] :silent If set to 'yes', response will be an empty 204, otherwise a list of the IntegrationStateV2  generated.
+  # @return [MultipleCustomerProfileIntegrationResponseV2]
+  describe 'update_customer_profiles_v2 test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
   # unit tests for update_customer_session
-  # Update a Customer Session
-  # Update (or create) a [Customer Session][]. For example, the items in a customers cart are part of a session.  The Talon.One platform supports multiple simultaneous sessions for the same profile, so if you have multiple ways of accessing the same application you have the option of either tracking multiple independent sessions or using the same session across all of them. You should share sessions when application access points share other state, such as the users cart. If two points of access to the application have independent state (e.g. a user can have different items in their cart across the two) they should use independent customer session ID's.  The `profileId` parameter in the request body should correspond to an `integrationId` for a customer profile, to track an anonymous session use the empty string (`\"\"`) as the `profileId`. Note that you do **not** need to create a customer profile first: if the specified profile does not yet exist, an empty profile will be created automatically.  Updating a customer profile will return a response with the full integration state. This includes the current state of the customer profile, the customer session, the event that was recorded, and an array of effects that took place.  The currency for the session and the cart items in the session is the same as that of the application with which the session is associated.  [Customer Session]: /Getting-Started/entities#customer-session 
+  # Update a Customer Session V1
+  # ⚠️ Deprecation Notice: Support for requests to this endpoint will end on 15.07.2021. We will not remove the endpoint, and it will still be accessible for you to use. For new features support, please migrate to [API V2.0](/Getting-Started/APIV2).  Update (or create) a [Customer Session][]. For example, the items in a customers cart are part of a session.  The Talon.One platform supports multiple simultaneous sessions for the same profile, so if you have multiple ways of accessing the same application you have the option of either tracking multiple independent sessions or using the same session across all of them. You should share sessions when application access points share other state, such as the users cart. If two points of access to the application have independent state (e.g. a user can have different items in their cart across the two) they should use independent customer session ID's.  The `profileId` parameter in the request body should correspond to an `integrationId` for a customer profile, to track an anonymous session use the empty string (`\"\"`) as the `profileId`. Note that you do **not** need to create a customer profile first: if the specified profile does not yet exist, an empty profile will be created automatically.  Updating a customer profile will return a response with the full integration state. This includes the current state of the customer profile, the customer session, the event that was recorded, and an array of effects that took place.  The currency for the session and the cart items in the session is the same as that of the application with which the session is associated.  [Customer Session]: /Getting-Started/entities#customer-session 
   # @param customer_session_id The custom identifier for this session, must be unique within the account.
   # @param body 
   # @param [Hash] opts the optional parameters

data/spec/api/management_api_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -378,6 +378,10 @@ describe 'ManagementApi' do
   # List Application Customers
   # @param application_id 
   # @param [Hash] opts the optional parameters
+  # @option opts [String] :integration_id Filter results performing an exact matching against the profile integration identifier.
+  # @option opts [Integer] :page_size The number of items to include in this response. When omitted, the maximum value of 1000 will be used.
+  # @option opts [Integer] :skip Skips the given number of items when paging through large result sets.
+  # @option opts [Boolean] :with_total_result_size When this flag is set, the result will include the total size of the result, across all pages. This might decrease performance on large data sets. With this flag set to true, hasMore will be be true whenever there is a next page. totalResultSize will always be zero. With this flag set to false, hasMore will always be set to false. totalResultSize will contain the total number of results for this query. 
   # @return [InlineResponse20012]
   describe 'get_application_customers test' do
     it 'should work' do
@@ -485,10 +489,11 @@ describe 'ManagementApi' do
   # @option opts [String] :sort The field by which results should be sorted. Sorting defaults to ascending order, prefix the field name with `-` to sort in descending order.
   # @option opts [String] :profile Profile integration ID filter for sessions. Must be exact match.
   # @option opts [String] :state Filter by sessions with this state. Must be exact match.
+  # @option opts [DateTime] :created_before Only return events created before this date
+  # @option opts [DateTime] :created_after Only return events created after this date
   # @option opts [String] :coupon Filter by sessions with this coupon. Must be exact match.
   # @option opts [String] :referral Filter by sessions with this referral. Must be exact match.
   # @option opts [String] :integration_id Filter by sessions with this integrationId. Must be exact match.
-  # @option opts [String] :customer_id Filter by integration ID of the customer for the session
   # @return [InlineResponse20016]
   describe 'get_application_sessions test' do
     it 'should work' do
@@ -592,6 +597,7 @@ describe 'ManagementApi' do
   # @option opts [String] :tags Filter results performing case-insensitive matching against the tags of the campaign. When used in conjunction with the \"name\" query parameter, a logical OR will be performed to search both tags and name for the provided values 
   # @option opts [DateTime] :created_before Filter results comparing the parameter value, expected to be an RFC3339 timestamp string, to the campaign creation timestamp.
   # @option opts [DateTime] :created_after Filter results comparing the parameter value, expected to be an RFC3339 timestamp string, to the campaign creation timestamp.
+  # @option opts [Integer] :campaign_group_id Filter results to campaigns owned by the specified campaign group ID.
   # @return [InlineResponse2002]
   describe 'get_campaigns test' do
     it 'should work' do
@@ -799,7 +805,6 @@ describe 'ManagementApi' do
 
   # unit tests for get_customer_profile
   # Get Customer Profile
-  # @param application_id 
   # @param customer_id 
   # @param [Hash] opts the optional parameters
   # @return [ApplicationCustomer]
@@ -915,6 +920,17 @@ describe 'ManagementApi' do
     end
   end
 
+  # unit tests for get_loyalty_statistics
+  # Get loyalty program statistics by loyalty program ID
+  # @param program_id 
+  # @param [Hash] opts the optional parameters
+  # @return [LoyaltyStatistics]
+  describe 'get_loyalty_statistics test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
   # unit tests for get_referrals
   # List Referrals (with total count)
   # @param application_id 

data/spec/api_client_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -156,7 +156,7 @@ describe TalonOne::ApiClient do
     end
 
     it 'fails for invalid collection format' do
-      expect{api_client.build_collection_param(param, :INVALID)}.to raise_error(RuntimeError, 'unknown collection format: :INVALID')
+      expect { api_client.build_collection_param(param, :INVALID) }.to raise_error(RuntimeError, 'unknown collection format: :INVALID')
     end
   end
 

data/spec/configuration_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/accept_coupon_effect_props_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/accept_referral_effect_props_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/access_log_entry_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/account_additional_cost_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/account_analytics_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -38,7 +38,13 @@ describe 'AccountAnalytics' do
     end
   end
 
-  describe 'test attribute "active_campaigns"' do
+  describe 'test attribute "live_applications"' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  describe 'test attribute "sandbox_applications"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
@@ -50,25 +56,31 @@ describe 'AccountAnalytics' do
     end
   end
 
-  describe 'test attribute "coupons"' do
+  describe 'test attribute "active_campaigns"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "active_coupons"' do
+  describe 'test attribute "live_active_campaigns"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "expired_coupons"' do
+  describe 'test attribute "coupons"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "custom_attributes"' do
+  describe 'test attribute "active_coupons"' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  describe 'test attribute "expired_coupons"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
@@ -92,6 +104,12 @@ describe 'AccountAnalytics' do
     end
   end
 
+  describe 'test attribute "active_rules"' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
   describe 'test attribute "users"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
@@ -104,19 +122,19 @@ describe 'AccountAnalytics' do
     end
   end
 
-  describe 'test attribute "webhooks"' do
+  describe 'test attribute "custom_attributes"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "loyalty_programs"' do
+  describe 'test attribute "webhooks"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "active_rules"' do
+  describe 'test attribute "loyalty_programs"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end

data/spec/models/account_entity_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/account_limits_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -62,37 +62,37 @@ describe 'AccountLimits' do
     end
   end
 
-  describe 'test attribute "live_loyalty_programs"' do
+  describe 'test attribute "active_rules"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "sandbox_loyalty_programs"' do
+  describe 'test attribute "live_loyalty_programs"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "webhooks"' do
+  describe 'test attribute "sandbox_loyalty_programs"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "users"' do
+  describe 'test attribute "webhooks"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "api_volume"' do
+  describe 'test attribute "users"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "active_rules"' do
+  describe 'test attribute "api_volume"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end

data/spec/models/account_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/add_free_item_effect_props_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 

data/spec/models/add_loyalty_points_effect_props_spec.rb

@@ -6,7 +6,7 @@
 The version of the OpenAPI document: 1.0.0
 
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 4.2.3
+OpenAPI Generator version: 4.3.1
 
 =end
 
@@ -62,7 +62,13 @@ describe 'AddLoyaltyPointsEffectProps' do
     end
   end
 
-  describe 'test attribute "expiry_condition"' do
+  describe 'test attribute "start_date"' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  describe 'test attribute "expiry_date"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end