-[Support for GeoJSON types <a name="geojson-support"></a>](#support-for-geojson-types)
...
...
@@ -426,9 +428,9 @@ curl --request POST \
```
</details>
## Patch api <a name="patch-api"></a>
## Metadata update api <a name="metadata-update-api"></a>
Bulk Update API allows the update of records metadata in batch. It takes an array of record ids with/without version
This API allows update of records metadata in batch. It takes an array of record ids with/without version
numbers with a maximum number of 500, and updates properties specified in the operation path with value and operation type
provided. If a version number is provided, updates will be applied to the specific version of the record. If not, the
latest version of the record will be updated. Users need to specify the corresponding data partition id in the header as
...
...
@@ -452,7 +454,7 @@ Bulk Update API has the following response codes:
PATCH /api/storage/v2/records
```
### Replace Tags, ACLs and Legal Tags <a name="patch-api-metadata-bulk-replace"></a>
### Replace Tags, ACLs and Legal Tags <a name="metadata-update-replace"></a>
In the "replace" operation, property value in "path" would be fully replaced by values provided in the "value" field. If
we need to replace tags ops.value should be colon separated string value.
...
...
@@ -512,7 +514,7 @@ curl --request PATCH \
</details>
### Add Tags, ACLs and Legal Tags <a name="patch-api-metadata-bulk-add"></a>
### Add Tags, ACLs and Legal Tags <a name="metadata-update-add"></a>
In the "add" operation, the valid Tags, Legal Tags, and ACLs (Acl Viewers, Acl Owners) provided in the "value" field
will be added to the property value in the "path" field. If we need to add tags ops.value should be colon separated
...
...
@@ -575,7 +577,7 @@ curl --request PATCH \
</details>
### Remove Tags, ACLs and Legal Tags <a name="patch-api-metadata-bulk-remove"></a>
### Remove Tags, ACLs and Legal Tags <a name="metadata-update-remove"></a>
In the "remove" operation, the valid Tags, Legal Tags, and ACLs (Acl Viewers, Acl Owners) provided in the "value" field
will be removed from the property value in the "path" field. When the given Tags, Legal Tags, or ACLs (Acl Viewers, Acl
...
...
@@ -642,6 +644,96 @@ curl --request PATCH \
> You can use Search service's query or query_with_cursor [apis](https://community.opengroup.org/osdu/platform/system/search-service/-/blob/master/docs/tutorial/SearchService.md) to search for records based on tags. Since tags is part of metadata, it is automatically indexed. This may not work if the kind is old (older than when the tags feature was introduced ~02/25/2021). You may need to re-index the kind with the [reindex](https://community.opengroup.org/osdu/platform/system/indexer-service/-/blob/master/docs/tutorial/IndexerService.md#reindex) api (with `force_clean=true`) from indexer service.
## Records patch api <a name="records-patch-api"></a>
This API allows update of records data and/or metadata in batch. It takes an array of record ids (without version
numbers) with a maximum number of 100, and updates properties specified in the operation path with value and operation type
provided. Users need to specify the corresponding data partition id in the header as well.
Users need to provide a list of recordIDs and a list of operations to be performed on each record. Each operation has `op`(operation type), `path`, and `value` in the field 'ops'. The currently supported operations are
"replace", "add", and "remove". The supported properties for metadata update are `tags`, `acl/viewers`, `acl/owners`, `legal/legaltags`, `ancestry/parents` and `kind`.
The supported properties for data update are `data` and `meta`. If `acl` is being updated, the user should be part of the groups that are being replaced/added/removed as ACL.
User specifies the property they want to update in the `path` field, and new values should be provided in the `value` field.
Note that this API supports PATCH operation in compliant to the [Patch RFC spec](https://www.rfc-editor.org/rfc/rfc6902). The behavior of the API reflects this accordingly.
Records patch API has the following response codes:
| 200 | The update operation succeeds fully, all records’ data and/or metadata get updated. | |
| 206 | The update operation succeeds partially. Some records are not updated due to different reasons, including records not found or does not have permission to edit the records. |
| 400 | The update operation fails when the remove operation makes Legal Tags or ACLs empty.| |
| `ops` field in payload | array of [PatchOperation](https://community.opengroup.org/osdu/platform/system/lib/core/os-core-common/-/blob/master/src/main/java/org/opengroup/osdu/core/common/model/storage/PatchOperation.java) | [JsonPatch](https://www.rfc-editor.org/rfc/rfc6902) |
| Maximum number of records | 500 | 100 |
## Using service accounts to access Storage APIs <a name="Service-accounts"></a>
The Storage service relies on the Google native data access authorization mechanisms to provide access control on the records.
Based on design decisions, when the Storage service caller is a federated user, no additional configuration is necessary, however if the API caller is a service account, a mandatory configuration is necessary as follows:
