| Page Properties | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||
Resources & Remarks
Modification History
Not all tags are relevant for the general user, e.g. tags that are needed for automatic data processing. To prevent the general user from seeing these tags, a classification tag can be defined as follows in the schema: <classification>tag[tenMyTenant:process,0,1,2,3,4,5,6,10,100]</classification> For the general user, only the tags that are explicitly listed are displayed. The name and value of the tag will be shown. If specified, they are localized. Note: Tags will not be validated by the backend. The same tag name can be used by different clients, but the tag can be used differently by these clients. Since this can lead to problems, it is recommended to assign an appropriate name space to the tag, e.g. the tenant name. In the above example, the tag "process" has been assigned to the name space tenMyTenant. |
| Excerpt |
|---|
The basic idea for the usage of tags is to describe the state of an object within a process chain. They consist basically They basically consist of a name and a state value and can be assigned to any object. |
| Section | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
...
- Tags do NOT belong to the metadata and thus do not need to be defined in the schema.
- Tags are stored together with the object as value for the property '
system:tags' property similar to metadata. - Pure tag operations do NOT lead to the creation of a new object version.
- Tags can only be attached to the current version of an object, whereas previous versions cannot have tags.
- For version-specific information, metadata provide the suitable options. They have to be defined in the schema.
...
Behavior during POST metadata updates:
- If the property
system:tagsproperty is specified in the request body,- all included tags are assigned to the new object version with the given
nameandstate. The same value assystem:lastModificationDateandsystem:traceIdwill be set automatically forcreationDateandtraceIdrespectively for all of them. - each tag that is not included is deleted. The new object version will not have that tag.
- all included tags are assigned to the new object version with the given
- If the property
system:tagsis NOT specified in the request body or is set tonull, all tags will be deleted. The new object version will not have any tag.
Behavior during PATCH metadata updates:
- If the property
system:tagsproperty is specified in the request body,- all included tags are assigned to the new object version.
- each tag that is not included is deleted. The new object version will not have that tag.
- If the property
system:tagsproperty is NOT specified in the request body, all tags are transferred to the new object version. Theirstate,creationDateandtraceIdremain unchanged. - If the property
system:tagsis property is set tonull, all tags will be deleted. The new object version will not have any tag.
...
- If the tag
nameends with the suffix:resistant, the tag is transferred to the new object version. Its state remains unchanged. - If the tag
namedoes NOT end with the suffix:resistant, the tag is deleted. It will not be assigned to the new object version.
Behavior during POST restoring actions of an old version (as of 2022 Spring):
- If the tag
nameends with the suffix:resistant, the tag is transferred to the new object version. Its state remains unchanged. - If the tag
namedoes NOT end with the suffix:resistant, the tag is deleted. It will not be assigned to the new object version.
Any tag operation is documented in the object audit trail.
...
| Property | Type | Description | In a request |
|---|---|---|---|
name | String | Name of the tag for identification. It has to be unique for the corresponding object. The tag names are validated during a tag creation or update process. To pass the validation, they have to match the regular expression [a-z](:?[a-z][a-z0-9]*)* and must not be longer than 32 characters (as of 2022 Spring, not no longer than 128 characters). As of version 2021 Summer, the suffix | required |
state | Integer | Represents the status of the corresponding object in a process chain. | required |
creationDate | String | Date and time of the last modification of the tag. It is set automatically by the system. | optional, only available in search queries |
traceId | Hexadecimal lowercase string with maximum length 16 | Process identification of any tag operation. If not specified in the request, a random String value will be set after the tag operation. In a tag update or delete request, the request parameter Per default, | optional, specified by means of the HTTP header X-B3-TraceId |
In a request, the corresponding properties are included directly in the URL for the call of the endpoint. In contrast, if tags are displayed in a response body, their properties are listed as a part of a JSON structure in the value of the property system:tags property.
Tagging Endpoints
The following endpoints for pure tag operations do not trigger a new version of the corresponding object, but only a new entry in the audit trail:
...
Resistant tags are identified by the suffix :resistant at the end of the string tag nametag name.
Note: The tag name including the suffix must not exceed the length limit of 128 characters.
Summary
This article gave an introduction into the handling of tags as a feature of the lifecycle management of objects in yuuvis® Momentum. In the "Tagging Objects for Processing" tutorial, an exemplary use case is explained.
...