google-api-client 0.30.0 → 0.30.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: bf5a7cb2ef2d472e53bed6ee06a6e030f115b3b1
-  data.tar.gz: f8bbe9824ba702e86b560275824d66cad2a3d03b
+  metadata.gz: 36e5383bf9ca48434646705363eb2795a8fe4334
+  data.tar.gz: ab48656ee4201bb14d0896be45d2af973afc99f5
 SHA512:
-  metadata.gz: f5448f8e27927d6a53432b04eaa50d827f3437c75c8e0abfa41c589278b9ee745e7b5bebb27f50543d63e384e274da0f92478839f4b41a251bd350f64dcf3758
-  data.tar.gz: 29ff63abaffb12c6e240448cc2655b1238876d8512849ac5f2a165679c6afe1f85a9be6718e6820a83c092572dbf94185765308c58668b50f3a48b6abee36306
+  metadata.gz: edb56a240b253b534970931c60fd5f0dba1efca502d8bb3a64c46b9a0aae011f8dabd470ab1e38bcff17904fd8f2a9023ebefd817e3d309203aa309ffa6f3f48
+  data.tar.gz: 00a6ba2003991be8da73871e007eaacfa163b2d4fdc1624804f20b580d5cb87dc461556d76eb5a4221ef8a6ece67d8ed6ab7400e1493ab1a8ed5383fe1f83d3b

data/CHANGELOG.md

@@ -1,3 +1,47 @@
+# 0.30.1
+* Backwards compatible changes:
+  * Updated `accesscontextmanager_v1`
+  * Updated `accesscontextmanager_v1beta`
+  * Updated `adexchangebuyer2_v2beta1`
+  * Updated `cloudidentity_v1`
+  * Updated `cloudidentity_v1beta1`
+  * Updated `cloudsearch_v1`
+  * Updated `commentanalyzer_v1alpha1`
+  * Updated `compute_alpha`
+  * Updated `compute_beta`
+  * Updated `compute_v1`
+  * Updated `container_v1beta1`
+  * Updated `containeranalysis_v1alpha1`
+  * Updated `containeranalysis_v1beta1`
+  * Updated `content_v2`
+  * Updated `content_v2_1`
+  * Updated `dialogflow_v2`
+  * Updated `dlp_v2`
+  * Updated `docs_v1`
+  * Updated `doubleclickbidmanager_v1`
+  * Updated `healthcare_v1alpha2`
+  * Updated `healthcare_v1beta1`
+  * Updated `jobs_v2`
+  * Updated `jobs_v3`
+  * Updated `logging_v2`
+  * Updated `ml_v1`
+  * Updated `monitoring_v3`
+  * Updated `redis_v1`
+  * Updated `redis_v1beta1`
+  * Updated `securitycenter_v1`
+  * Updated `securitycenter_v1beta1`
+  * Updated `serviceconsumermanagement_v1`
+  * Updated `servicenetworking_v1`
+  * Updated `servicenetworking_v1beta`
+  * Updated `serviceusage_v1`
+  * Updated `serviceusage_v1beta1`
+  * Updated `speech_v1p1beta1`
+  * Updated `streetviewpublish_v1`
+  * Updated `toolresults_v1beta3`
+  * Updated `vision_v1`
+  * Updated `vision_v1p1beta1`
+  * Updated `vision_v1p2beta1`
+
 # 0.30.0
 * Breaking changes:
   * Deleted `youtube_analytics_v1beta1`

data/generated/google/apis/accesscontextmanager_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/access-context-manager/docs/reference/rest/
     module AccesscontextmanagerV1
       VERSION = 'V1'
-      REVISION = '20190507'
+      REVISION = '20190529'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/accesscontextmanager_v1/classes.rb

@@ -446,43 +446,10 @@ module Google
       
         # The `Status` type defines a logical error model that is suitable for
         # different programming environments, including REST APIs and RPC APIs. It is
-        # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-        # - Simple to use and understand for most users
-        # - Flexible enough to meet unexpected needs
-        # # Overview
-        # The `Status` message contains three pieces of data: error code, error
-        # message, and error details. The error code should be an enum value of
-        # google.rpc.Code, but it may accept additional error codes if needed.  The
-        # error message should be a developer-facing English message that helps
-        # developers *understand* and *resolve* the error. If a localized user-facing
-        # error message is needed, put the localized message in the error details or
-        # localize it in the client. The optional error details may contain arbitrary
-        # information about the error. There is a predefined set of error detail types
-        # in the package `google.rpc` that can be used for common error conditions.
-        # # Language mapping
-        # The `Status` message is the logical representation of the error model, but it
-        # is not necessarily the actual wire format. When the `Status` message is
-        # exposed in different client libraries and different wire protocols, it can be
-        # mapped differently. For example, it will likely be mapped to some exceptions
-        # in Java, but more likely mapped to some error codes in C.
-        # # Other uses
-        # The error model and the `Status` message can be used in a variety of
-        # environments, either with or without APIs, to provide a
-        # consistent developer experience across different environments.
-        # Example uses of this error model include:
-        # - Partial errors. If a service needs to return partial errors to the client,
-        # it may embed the `Status` in the normal response to indicate the partial
-        # errors.
-        # - Workflow errors. A typical workflow has multiple steps. Each step may
-        # have a `Status` message for error reporting.
-        # - Batch operations. If a client uses batch request and batch response, the
-        # `Status` message should be used directly inside batch response, one for
-        # each error sub-response.
-        # - Asynchronous operations. If an API call embeds asynchronous operation
-        # results in its response, the status of those operations should be
-        # represented directly using the `Status` message.
-        # - Logging. If some API errors are stored in logs, the message `Status` could
-        # be used directly after any stripping needed for security/privacy reasons.
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+        # three pieces of data: error code, error message, and error details.
+        # You can find out more about this error model and how to work with it in the
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::AccesscontextmanagerV1::Status]
         attr_accessor :error
@@ -681,43 +648,10 @@ module Google
       
       # The `Status` type defines a logical error model that is suitable for
       # different programming environments, including REST APIs and RPC APIs. It is
-      # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-      # - Simple to use and understand for most users
-      # - Flexible enough to meet unexpected needs
-      # # Overview
-      # The `Status` message contains three pieces of data: error code, error
-      # message, and error details. The error code should be an enum value of
-      # google.rpc.Code, but it may accept additional error codes if needed.  The
-      # error message should be a developer-facing English message that helps
-      # developers *understand* and *resolve* the error. If a localized user-facing
-      # error message is needed, put the localized message in the error details or
-      # localize it in the client. The optional error details may contain arbitrary
-      # information about the error. There is a predefined set of error detail types
-      # in the package `google.rpc` that can be used for common error conditions.
-      # # Language mapping
-      # The `Status` message is the logical representation of the error model, but it
-      # is not necessarily the actual wire format. When the `Status` message is
-      # exposed in different client libraries and different wire protocols, it can be
-      # mapped differently. For example, it will likely be mapped to some exceptions
-      # in Java, but more likely mapped to some error codes in C.
-      # # Other uses
-      # The error model and the `Status` message can be used in a variety of
-      # environments, either with or without APIs, to provide a
-      # consistent developer experience across different environments.
-      # Example uses of this error model include:
-      # - Partial errors. If a service needs to return partial errors to the client,
-      # it may embed the `Status` in the normal response to indicate the partial
-      # errors.
-      # - Workflow errors. A typical workflow has multiple steps. Each step may
-      # have a `Status` message for error reporting.
-      # - Batch operations. If a client uses batch request and batch response, the
-      # `Status` message should be used directly inside batch response, one for
-      # each error sub-response.
-      # - Asynchronous operations. If an API call embeds asynchronous operation
-      # results in its response, the status of those operations should be
-      # represented directly using the `Status` message.
-      # - Logging. If some API errors are stored in logs, the message `Status` could
-      # be used directly after any stripping needed for security/privacy reasons.
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+      # three pieces of data: error code, error message, and error details.
+      # You can find out more about this error model and how to work with it in the
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
       class Status
         include Google::Apis::Core::Hashable
       

data/generated/google/apis/accesscontextmanager_v1beta.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/access-context-manager/docs/reference/rest/
     module AccesscontextmanagerV1beta
       VERSION = 'V1beta'
-      REVISION = '20190507'
+      REVISION = '20190529'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/accesscontextmanager_v1beta/classes.rb

@@ -389,43 +389,10 @@ module Google
       
         # The `Status` type defines a logical error model that is suitable for
         # different programming environments, including REST APIs and RPC APIs. It is
-        # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-        # - Simple to use and understand for most users
-        # - Flexible enough to meet unexpected needs
-        # # Overview
-        # The `Status` message contains three pieces of data: error code, error
-        # message, and error details. The error code should be an enum value of
-        # google.rpc.Code, but it may accept additional error codes if needed.  The
-        # error message should be a developer-facing English message that helps
-        # developers *understand* and *resolve* the error. If a localized user-facing
-        # error message is needed, put the localized message in the error details or
-        # localize it in the client. The optional error details may contain arbitrary
-        # information about the error. There is a predefined set of error detail types
-        # in the package `google.rpc` that can be used for common error conditions.
-        # # Language mapping
-        # The `Status` message is the logical representation of the error model, but it
-        # is not necessarily the actual wire format. When the `Status` message is
-        # exposed in different client libraries and different wire protocols, it can be
-        # mapped differently. For example, it will likely be mapped to some exceptions
-        # in Java, but more likely mapped to some error codes in C.
-        # # Other uses
-        # The error model and the `Status` message can be used in a variety of
-        # environments, either with or without APIs, to provide a
-        # consistent developer experience across different environments.
-        # Example uses of this error model include:
-        # - Partial errors. If a service needs to return partial errors to the client,
-        # it may embed the `Status` in the normal response to indicate the partial
-        # errors.
-        # - Workflow errors. A typical workflow has multiple steps. Each step may
-        # have a `Status` message for error reporting.
-        # - Batch operations. If a client uses batch request and batch response, the
-        # `Status` message should be used directly inside batch response, one for
-        # each error sub-response.
-        # - Asynchronous operations. If an API call embeds asynchronous operation
-        # results in its response, the status of those operations should be
-        # represented directly using the `Status` message.
-        # - Logging. If some API errors are stored in logs, the message `Status` could
-        # be used directly after any stripping needed for security/privacy reasons.
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+        # three pieces of data: error code, error message, and error details.
+        # You can find out more about this error model and how to work with it in the
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::AccesscontextmanagerV1beta::Status]
         attr_accessor :error
@@ -634,43 +601,10 @@ module Google
       
       # The `Status` type defines a logical error model that is suitable for
       # different programming environments, including REST APIs and RPC APIs. It is
-      # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-      # - Simple to use and understand for most users
-      # - Flexible enough to meet unexpected needs
-      # # Overview
-      # The `Status` message contains three pieces of data: error code, error
-      # message, and error details. The error code should be an enum value of
-      # google.rpc.Code, but it may accept additional error codes if needed.  The
-      # error message should be a developer-facing English message that helps
-      # developers *understand* and *resolve* the error. If a localized user-facing
-      # error message is needed, put the localized message in the error details or
-      # localize it in the client. The optional error details may contain arbitrary
-      # information about the error. There is a predefined set of error detail types
-      # in the package `google.rpc` that can be used for common error conditions.
-      # # Language mapping
-      # The `Status` message is the logical representation of the error model, but it
-      # is not necessarily the actual wire format. When the `Status` message is
-      # exposed in different client libraries and different wire protocols, it can be
-      # mapped differently. For example, it will likely be mapped to some exceptions
-      # in Java, but more likely mapped to some error codes in C.
-      # # Other uses
-      # The error model and the `Status` message can be used in a variety of
-      # environments, either with or without APIs, to provide a
-      # consistent developer experience across different environments.
-      # Example uses of this error model include:
-      # - Partial errors. If a service needs to return partial errors to the client,
-      # it may embed the `Status` in the normal response to indicate the partial
-      # errors.
-      # - Workflow errors. A typical workflow has multiple steps. Each step may
-      # have a `Status` message for error reporting.
-      # - Batch operations. If a client uses batch request and batch response, the
-      # `Status` message should be used directly inside batch response, one for
-      # each error sub-response.
-      # - Asynchronous operations. If an API call embeds asynchronous operation
-      # results in its response, the status of those operations should be
-      # represented directly using the `Status` message.
-      # - Logging. If some API errors are stored in logs, the message `Status` could
-      # be used directly after any stripping needed for security/privacy reasons.
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+      # three pieces of data: error code, error message, and error details.
+      # You can find out more about this error model and how to work with it in the
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
       class Status
         include Google::Apis::Core::Hashable
       

data/generated/google/apis/adexchangebuyer2_v2beta1.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://developers.google.com/authorized-buyers/apis/reference/rest/
     module Adexchangebuyer2V2beta1
       VERSION = 'V2beta1'
-      REVISION = '20190506'
+      REVISION = '20190529'
 
       # Manage your Ad Exchange buyer account configuration
       AUTH_ADEXCHANGE_BUYER = 'https://www.googleapis.com/auth/adexchange.buyer'

data/generated/google/apis/adexchangebuyer2_v2beta1/classes.rb

@@ -117,6 +117,50 @@ module Google
         end
       end
       
+      # Detected ad technology provider information.
+      class AdTechnologyProviders
+        include Google::Apis::Core::Hashable
+      
+        # The detected ad technology provider IDs for this creative.
+        # See https://storage.googleapis.com/adx-rtb-dictionaries/providers.csv for
+        # mapping of provider ID to provided name, a privacy policy URL, and a list
+        # of domains which can be attributed to the provider.
+        # If the creative contains provider IDs that are outside of those listed in
+        # the `BidRequest.adslot.consented_providers_settings.consented_providers`
+        # field on the (Google bid
+        # protocol)[https://developers.google.com/authorized-buyers/rtb/downloads/
+        # realtime-bidding-proto]
+        # and the
+        # `BidRequest.user.ext.consented_providers_settings.consented_providers`
+        # field on the (OpenRTB
+        # protocol)[https://developers.google.com/authorized-buyers/rtb/downloads/
+        # openrtb-adx-proto],
+        # and a bid is submitted with that creative for an impression that will
+        # serve to an EEA user, the bid will be filtered before the auction.
+        # Corresponds to the JSON property `detectedProviderIds`
+        # @return [Array<Fixnum>]
+        attr_accessor :detected_provider_ids
+      
+        # Whether the creative contains an unidentified ad technology provider.
+        # If true for a given creative, any bid submitted with that creative for an
+        # impression that will serve to an EEA user will be filtered before the
+        # auction.
+        # Corresponds to the JSON property `hasUnidentifiedProvider`
+        # @return [Boolean]
+        attr_accessor :has_unidentified_provider
+        alias_method :has_unidentified_provider?, :has_unidentified_provider
+      
+        def initialize(**args)
+           update!(**args)
+        end
+      
+        # Update properties of this object
+        def update!(**args)
+          @detected_provider_ids = args[:detected_provider_ids] if args.key?(:detected_provider_ids)
+          @has_unidentified_provider = args[:has_unidentified_provider] if args.key?(:has_unidentified_provider)
+        end
+      end
+      
       # A request for associating a deal and a creative.
       class AddDealAssociationRequest
         include Google::Apis::Core::Hashable
@@ -638,6 +682,11 @@ module Google
         # @return [String]
         attr_accessor :ad_choices_destination_url
       
+        # Detected ad technology provider information.
+        # Corresponds to the JSON property `adTechnologyProviders`
+        # @return [Google::Apis::Adexchangebuyer2V2beta1::AdTechnologyProviders]
+        attr_accessor :ad_technology_providers
+      
         # The name of the company being advertised in the creative.
         # Corresponds to the JSON property `advertiserName`
         # @return [String]
@@ -793,6 +842,7 @@ module Google
         def update!(**args)
           @account_id = args[:account_id] if args.key?(:account_id)
           @ad_choices_destination_url = args[:ad_choices_destination_url] if args.key?(:ad_choices_destination_url)
+          @ad_technology_providers = args[:ad_technology_providers] if args.key?(:ad_technology_providers)
           @advertiser_name = args[:advertiser_name] if args.key?(:advertiser_name)
           @agency_id = args[:agency_id] if args.key?(:agency_id)
           @api_update_time = args[:api_update_time] if args.key?(:api_update_time)

data/generated/google/apis/adexchangebuyer2_v2beta1/representations.rb

@@ -40,6 +40,12 @@ module Google
         include Google::Apis::Core::JsonObjectSupport
       end
       
+      class AdTechnologyProviders
+        class Representation < Google::Apis::Core::JsonRepresentation; end
+      
+        include Google::Apis::Core::JsonObjectSupport
+      end
+      
       class AddDealAssociationRequest
         class Representation < Google::Apis::Core::JsonRepresentation; end
       
@@ -672,6 +678,14 @@ module Google
         end
       end
       
+      class AdTechnologyProviders
+        # @private
+        class Representation < Google::Apis::Core::JsonRepresentation
+          collection :detected_provider_ids, as: 'detectedProviderIds'
+          property :has_unidentified_provider, as: 'hasUnidentifiedProvider'
+        end
+      end
+      
       class AddDealAssociationRequest
         # @private
         class Representation < Google::Apis::Core::JsonRepresentation
@@ -820,6 +834,8 @@ module Google
         class Representation < Google::Apis::Core::JsonRepresentation
           property :account_id, as: 'accountId'
           property :ad_choices_destination_url, as: 'adChoicesDestinationUrl'
+          property :ad_technology_providers, as: 'adTechnologyProviders', class: Google::Apis::Adexchangebuyer2V2beta1::AdTechnologyProviders, decorator: Google::Apis::Adexchangebuyer2V2beta1::AdTechnologyProviders::Representation
+      
           property :advertiser_name, as: 'advertiserName'
           property :agency_id, :numeric_string => true, as: 'agencyId'
           property :api_update_time, as: 'apiUpdateTime'

data/generated/google/apis/cloudidentity_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/identity/
     module CloudidentityV1
       VERSION = 'V1'
-      REVISION = '20190503'
+      REVISION = '20190529'
 
       # See, change, create, and delete any of the Cloud Identity Groups that you can access, including the members of each group
       AUTH_CLOUD_IDENTITY_GROUPS = 'https://www.googleapis.com/auth/cloud-identity.groups'

data/generated/google/apis/cloudidentity_v1/classes.rb

@@ -311,43 +311,10 @@ module Google
       
         # The `Status` type defines a logical error model that is suitable for
         # different programming environments, including REST APIs and RPC APIs. It is
-        # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-        # - Simple to use and understand for most users
-        # - Flexible enough to meet unexpected needs
-        # # Overview
-        # The `Status` message contains three pieces of data: error code, error
-        # message, and error details. The error code should be an enum value of
-        # google.rpc.Code, but it may accept additional error codes if needed.  The
-        # error message should be a developer-facing English message that helps
-        # developers *understand* and *resolve* the error. If a localized user-facing
-        # error message is needed, put the localized message in the error details or
-        # localize it in the client. The optional error details may contain arbitrary
-        # information about the error. There is a predefined set of error detail types
-        # in the package `google.rpc` that can be used for common error conditions.
-        # # Language mapping
-        # The `Status` message is the logical representation of the error model, but it
-        # is not necessarily the actual wire format. When the `Status` message is
-        # exposed in different client libraries and different wire protocols, it can be
-        # mapped differently. For example, it will likely be mapped to some exceptions
-        # in Java, but more likely mapped to some error codes in C.
-        # # Other uses
-        # The error model and the `Status` message can be used in a variety of
-        # environments, either with or without APIs, to provide a
-        # consistent developer experience across different environments.
-        # Example uses of this error model include:
-        # - Partial errors. If a service needs to return partial errors to the client,
-        # it may embed the `Status` in the normal response to indicate the partial
-        # errors.
-        # - Workflow errors. A typical workflow has multiple steps. Each step may
-        # have a `Status` message for error reporting.
-        # - Batch operations. If a client uses batch request and batch response, the
-        # `Status` message should be used directly inside batch response, one for
-        # each error sub-response.
-        # - Asynchronous operations. If an API call embeds asynchronous operation
-        # results in its response, the status of those operations should be
-        # represented directly using the `Status` message.
-        # - Logging. If some API errors are stored in logs, the message `Status` could
-        # be used directly after any stripping needed for security/privacy reasons.
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+        # three pieces of data: error code, error message, and error details.
+        # You can find out more about this error model and how to work with it in the
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::CloudidentityV1::Status]
         attr_accessor :error
@@ -421,43 +388,10 @@ module Google
       
       # The `Status` type defines a logical error model that is suitable for
       # different programming environments, including REST APIs and RPC APIs. It is
-      # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-      # - Simple to use and understand for most users
-      # - Flexible enough to meet unexpected needs
-      # # Overview
-      # The `Status` message contains three pieces of data: error code, error
-      # message, and error details. The error code should be an enum value of
-      # google.rpc.Code, but it may accept additional error codes if needed.  The
-      # error message should be a developer-facing English message that helps
-      # developers *understand* and *resolve* the error. If a localized user-facing
-      # error message is needed, put the localized message in the error details or
-      # localize it in the client. The optional error details may contain arbitrary
-      # information about the error. There is a predefined set of error detail types
-      # in the package `google.rpc` that can be used for common error conditions.
-      # # Language mapping
-      # The `Status` message is the logical representation of the error model, but it
-      # is not necessarily the actual wire format. When the `Status` message is
-      # exposed in different client libraries and different wire protocols, it can be
-      # mapped differently. For example, it will likely be mapped to some exceptions
-      # in Java, but more likely mapped to some error codes in C.
-      # # Other uses
-      # The error model and the `Status` message can be used in a variety of
-      # environments, either with or without APIs, to provide a
-      # consistent developer experience across different environments.
-      # Example uses of this error model include:
-      # - Partial errors. If a service needs to return partial errors to the client,
-      # it may embed the `Status` in the normal response to indicate the partial
-      # errors.
-      # - Workflow errors. A typical workflow has multiple steps. Each step may
-      # have a `Status` message for error reporting.
-      # - Batch operations. If a client uses batch request and batch response, the
-      # `Status` message should be used directly inside batch response, one for
-      # each error sub-response.
-      # - Asynchronous operations. If an API call embeds asynchronous operation
-      # results in its response, the status of those operations should be
-      # represented directly using the `Status` message.
-      # - Logging. If some API errors are stored in logs, the message `Status` could
-      # be used directly after any stripping needed for security/privacy reasons.
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+      # three pieces of data: error code, error message, and error details.
+      # You can find out more about this error model and how to work with it in the
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
       class Status
         include Google::Apis::Core::Hashable