Skip to content

Commit

Permalink
feat(documentai): update the api
Browse files Browse the repository at this point in the history
#### documentai:v1

The following keys were added:
- schemas.GoogleCloudDocumentaiV1ProcessorType.properties.launchStage.type (Total Keys: 1)

#### documentai:v1beta3

The following keys were added:
- schemas.GoogleCloudDocumentaiV1beta3ProcessorType.properties.launchStage.type (Total Keys: 1)
  • Loading branch information
yoshi-automation committed Oct 12, 2021
1 parent e99de16 commit fa10141
Show file tree
Hide file tree
Showing 5 changed files with 61 additions and 11 deletions.
5 changes: 3 additions & 2 deletions docs/dyn/documentai_v1.projects.locations.html
Original file line number Diff line number Diff line change
Expand Up @@ -121,16 +121,17 @@ <h3>Method Details</h3>

{ # Response message for fetch processor types.
&quot;processorTypes&quot;: [ # The list of processor types.
{ # A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we&#x27;ll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the &#x27;available_locations&#x27; field to show under which regions a processor type is available. For example, users can call either the &#x27;US&#x27; or &#x27;EU&#x27; endpoint to feach processor types. In the return, we will have an &#x27;invoice parsing&#x27; processor with &#x27;available_locations&#x27; field only containing &#x27;US&#x27;. So the user can try to create an &#x27;invoice parsing&#x27; processor under the location &#x27;US&#x27;. Such attempt of creating under the location &#x27;EU&#x27; will fail. Next ID: 8.
{ # A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we&#x27;ll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the &#x27;available_locations&#x27; field to show under which regions a processor type is available. For example, users can call either the &#x27;US&#x27; or &#x27;EU&#x27; endpoint to feach processor types. In the return, we will have an &#x27;invoice parsing&#x27; processor with &#x27;available_locations&#x27; field only containing &#x27;US&#x27;. So the user can try to create an &#x27;invoice parsing&#x27; processor under the location &#x27;US&#x27;. Such attempt of creating under the location &#x27;EU&#x27; will fail. Next ID: 9.
&quot;allowCreation&quot;: True or False, # Whether the processor type allows creation. If yes, user can create a processor of this processor type. Otherwise, user needs to request access.
&quot;availableLocations&quot;: [ # The locations in which this processor is available.
{ # The location information about where the processor is available.
&quot;locationId&quot;: &quot;A String&quot;, # The location id, currently must be one of [us, eu].
},
],
&quot;category&quot;: &quot;A String&quot;, # The processor category, used by UI to group processor types.
&quot;launchStage&quot;: &quot;A String&quot;, # Launch stage of the processor type
&quot;name&quot;: &quot;A String&quot;, # The resource name of the processor type. Format: projects/{project}/processorTypes/{processor_type}
&quot;type&quot;: &quot;A String&quot;, # The type of the processor, e.g, &quot;invoice_parsing&quot;.
&quot;type&quot;: &quot;A String&quot;, # The type of the processor, e.g., &quot;invoice_parsing&quot;.
},
],
}</pre>
Expand Down
5 changes: 3 additions & 2 deletions docs/dyn/documentai_v1beta3.projects.locations.html
Original file line number Diff line number Diff line change
Expand Up @@ -121,16 +121,17 @@ <h3>Method Details</h3>

{ # Response message for fetch processor types.
&quot;processorTypes&quot;: [ # The list of processor types.
{ # A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we&#x27;ll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the &#x27;available_locations&#x27; field to show under which regions a processor type is available. For example, users can call either the &#x27;US&#x27; or &#x27;EU&#x27; endpoint to feach processor types. In the return, we will have an &#x27;invoice parsing&#x27; processor with &#x27;available_locations&#x27; field only containing &#x27;US&#x27;. So the user can try to create an &#x27;invoice parsing&#x27; processor under the location &#x27;US&#x27;. Such attempt of creating under the location &#x27;EU&#x27; will fail. Next ID: 8.
{ # A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we&#x27;ll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the &#x27;available_locations&#x27; field to show under which regions a processor type is available. For example, users can call either the &#x27;US&#x27; or &#x27;EU&#x27; endpoint to feach processor types. In the return, we will have an &#x27;invoice parsing&#x27; processor with &#x27;available_locations&#x27; field only containing &#x27;US&#x27;. So the user can try to create an &#x27;invoice parsing&#x27; processor under the location &#x27;US&#x27;. Such attempt of creating under the location &#x27;EU&#x27; will fail. Next ID: 9.
&quot;allowCreation&quot;: True or False, # Whether the processor type allows creation. If yes, user can create a processor of this processor type. Otherwise, user needs to request access.
&quot;availableLocations&quot;: [ # The locations in which this processor is available.
{ # The location information about where the processor is available.
&quot;locationId&quot;: &quot;A String&quot;, # The location id, currently must be one of [us, eu].
},
],
&quot;category&quot;: &quot;A String&quot;, # The processor category, used by UI to group processor types.
&quot;launchStage&quot;: &quot;A String&quot;, # Launch stage of the processor type
&quot;name&quot;: &quot;A String&quot;, # The resource name of the processor type. Format: projects/{project}/processorTypes/{processor_type}
&quot;type&quot;: &quot;A String&quot;, # The type of the processor, e.g, &quot;invoice_parsing&quot;.
&quot;type&quot;: &quot;A String&quot;, # The type of the processor, e.g., &quot;invoice_parsing&quot;.
},
],
}</pre>
Expand Down
30 changes: 27 additions & 3 deletions googleapiclient/discovery_cache/documents/documentai.v1.json
Original file line number Diff line number Diff line change
Expand Up @@ -1029,7 +1029,7 @@
}
}
},
"revision": "20210926",
"revision": "20211002",
"rootUrl": "https://documentai.googleapis.com/",
"schemas": {
"GoogleCloudDocumentaiUiv1beta3BatchDeleteDocumentsMetadata": {
Expand Down Expand Up @@ -2961,7 +2961,7 @@
"type": "object"
},
"GoogleCloudDocumentaiV1ProcessorType": {
"description": "A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we'll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the 'available_locations' field to show under which regions a processor type is available. For example, users can call either the 'US' or 'EU' endpoint to feach processor types. In the return, we will have an 'invoice parsing' processor with 'available_locations' field only containing 'US'. So the user can try to create an 'invoice parsing' processor under the location 'US'. Such attempt of creating under the location 'EU' will fail. Next ID: 8.",
"description": "A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we'll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the 'available_locations' field to show under which regions a processor type is available. For example, users can call either the 'US' or 'EU' endpoint to feach processor types. In the return, we will have an 'invoice parsing' processor with 'available_locations' field only containing 'US'. So the user can try to create an 'invoice parsing' processor under the location 'US'. Such attempt of creating under the location 'EU' will fail. Next ID: 9.",
"id": "GoogleCloudDocumentaiV1ProcessorType",
"properties": {
"allowCreation": {
Expand All @@ -2979,12 +2979,36 @@
"description": "The processor category, used by UI to group processor types.",
"type": "string"
},
"launchStage": {
"description": "Launch stage of the processor type",
"enum": [
"LAUNCH_STAGE_UNSPECIFIED",
"UNIMPLEMENTED",
"PRELAUNCH",
"EARLY_ACCESS",
"ALPHA",
"BETA",
"GA",
"DEPRECATED"
],
"enumDescriptions": [
"Do not use this default value.",
"The feature is not yet implemented. Users can not use it.",
"Prelaunch features are hidden from users and are only visible internally.",
"Early Access features are limited to a closed group of testers. To use these features, you must sign up in advance and sign a Trusted Tester agreement (which includes confidentiality provisions). These features may be unstable, changed in backward-incompatible ways, and are not guaranteed to be released.",
"Alpha is a limited availability test for releases before they are cleared for widespread use. By Alpha, all significant design issues are resolved and we are in the process of verifying functionality. Alpha customers need to apply for access, agree to applicable terms, and have their projects allowlisted. Alpha releases don\u2019t have to be feature complete, no SLAs are provided, and there are no technical support obligations, but they will be far enough along that customers can actually use them in test environments or for limited-use tests -- just like they would in normal production cases.",
"Beta is the point at which we are ready to open a release for any customer to use. There are no SLA or technical support obligations in a Beta release. Products will be complete from a feature perspective, but may have some open outstanding issues. Beta releases are suitable for limited production use cases.",
"GA features are open to all developers and are considered stable and fully qualified for production use.",
"Deprecated features are scheduled to be shut down and removed. For more information, see the \u201cDeprecation Policy\u201d section of our [Terms of Service](https://cloud.google.com/terms/) and the [Google Cloud Platform Subject to the Deprecation Policy](https://cloud.google.com/terms/deprecation) documentation."
],
"type": "string"
},
"name": {
"description": "The resource name of the processor type. Format: projects/{project}/processorTypes/{processor_type}",
"type": "string"
},
"type": {
"description": "The type of the processor, e.g, \"invoice_parsing\".",
"description": "The type of the processor, e.g., \"invoice_parsing\".",
"type": "string"
}
},
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -292,7 +292,7 @@
}
}
},
"revision": "20210926",
"revision": "20211002",
"rootUrl": "https://documentai.googleapis.com/",
"schemas": {
"GoogleCloudDocumentaiUiv1beta3BatchDeleteDocumentsMetadata": {
Expand Down
30 changes: 27 additions & 3 deletions googleapiclient/discovery_cache/documents/documentai.v1beta3.json
Original file line number Diff line number Diff line change
Expand Up @@ -796,7 +796,7 @@
}
}
},
"revision": "20210926",
"revision": "20211002",
"rootUrl": "https://documentai.googleapis.com/",
"schemas": {
"GoogleCloudDocumentaiUiv1beta3BatchDeleteDocumentsMetadata": {
Expand Down Expand Up @@ -5399,7 +5399,7 @@
"type": "object"
},
"GoogleCloudDocumentaiV1beta3ProcessorType": {
"description": "A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we'll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the 'available_locations' field to show under which regions a processor type is available. For example, users can call either the 'US' or 'EU' endpoint to feach processor types. In the return, we will have an 'invoice parsing' processor with 'available_locations' field only containing 'US'. So the user can try to create an 'invoice parsing' processor under the location 'US'. Such attempt of creating under the location 'EU' will fail. Next ID: 8.",
"description": "A processor type is responsible for performing a certain document understanding task on a certain type of document. All processor types are created by the documentai service internally. User will only list all available processor types via UI. For different users (projects), the available processor types may be different since we'll expose the access of some types via EAP whitelisting. We make the ProcessorType a resource under location so we have a unified API and keep the possibility that UI will load different available processor types from different regions. But for alpha the behavior is that the user will always get the union of all available processor types among all regions no matter which regionalized endpoint is called, and then we use the 'available_locations' field to show under which regions a processor type is available. For example, users can call either the 'US' or 'EU' endpoint to feach processor types. In the return, we will have an 'invoice parsing' processor with 'available_locations' field only containing 'US'. So the user can try to create an 'invoice parsing' processor under the location 'US'. Such attempt of creating under the location 'EU' will fail. Next ID: 9.",
"id": "GoogleCloudDocumentaiV1beta3ProcessorType",
"properties": {
"allowCreation": {
Expand All @@ -5417,12 +5417,36 @@
"description": "The processor category, used by UI to group processor types.",
"type": "string"
},
"launchStage": {
"description": "Launch stage of the processor type",
"enum": [
"LAUNCH_STAGE_UNSPECIFIED",
"UNIMPLEMENTED",
"PRELAUNCH",
"EARLY_ACCESS",
"ALPHA",
"BETA",
"GA",
"DEPRECATED"
],
"enumDescriptions": [
"Do not use this default value.",
"The feature is not yet implemented. Users can not use it.",
"Prelaunch features are hidden from users and are only visible internally.",
"Early Access features are limited to a closed group of testers. To use these features, you must sign up in advance and sign a Trusted Tester agreement (which includes confidentiality provisions). These features may be unstable, changed in backward-incompatible ways, and are not guaranteed to be released.",
"Alpha is a limited availability test for releases before they are cleared for widespread use. By Alpha, all significant design issues are resolved and we are in the process of verifying functionality. Alpha customers need to apply for access, agree to applicable terms, and have their projects allowlisted. Alpha releases don\u2019t have to be feature complete, no SLAs are provided, and there are no technical support obligations, but they will be far enough along that customers can actually use them in test environments or for limited-use tests -- just like they would in normal production cases.",
"Beta is the point at which we are ready to open a release for any customer to use. There are no SLA or technical support obligations in a Beta release. Products will be complete from a feature perspective, but may have some open outstanding issues. Beta releases are suitable for limited production use cases.",
"GA features are open to all developers and are considered stable and fully qualified for production use.",
"Deprecated features are scheduled to be shut down and removed. For more information, see the \u201cDeprecation Policy\u201d section of our [Terms of Service](https://cloud.google.com/terms/) and the [Google Cloud Platform Subject to the Deprecation Policy](https://cloud.google.com/terms/deprecation) documentation."
],
"type": "string"
},
"name": {
"description": "The resource name of the processor type. Format: projects/{project}/processorTypes/{processor_type}",
"type": "string"
},
"type": {
"description": "The type of the processor, e.g, \"invoice_parsing\".",
"description": "The type of the processor, e.g., \"invoice_parsing\".",
"type": "string"
}
},
Expand Down

0 comments on commit fa10141

Please sign in to comment.