Tags
Here are all tags for dam and data API (or affiliates).
Structure tags
Name | Purpose | Comment |
---|---|---|
rest_api_exclude | exclude the structure from exposure (especially for structures selected for automatic exposure in DAM services, but also in data services) | this tag takes precedence over any inclusion tag or rule |
rest_api_include | expose the structure (if it is not selected automatically) (in dam services) | has no effect if the structure has the tag rest_api_exclude |
rest_api_dam_include | expose the structure (if it is not selected automatically) (in dam services) as damobject | has no effect if the structure has the tag rest_api_exclude |
rest_api_asset_exclude | allows to consider a tagged damobject (or rest_api_dam_include) structure as not be exposed as “asset” | 11.30 if has tag rest_api_dam_include, the rules of generation are the damobject rules but ressource is not included in “asset” |
rest_api_exclude_list | disable list mode |
|
rest_api_dam_create | activates the creation of objects in this structure (in dam services) | has no effect if the structure has the tag rest_api_dam_readonly |
rest_api_dam_update | activates the modification of objects in this structure (in dam services) | has no effect if the structure has the tag rest_api_dam_readonly |
rest_api_dam_delete | activates the deletion of objects in this structure (in dam services) | has no effect if the structure has the tag rest_api_dam_readonly |
rest_api_dam_workflow | activates workflow control of the objects in this structure (in dam services) | has no effect if the structure has the tag rest_api_dam_readonly |
rest_api_dam_disable_workcopy 11.29 | deactivates workcopy endpoint, (if structure is compliant with, workcopy is activated by default) |
|
rest_api_dam_readonly | protects the structure against modification, creation, deletion, including through a resource that represents another structure (cascade creation) (in dam services) |
|
rest_api_dam_lock | opens the possibility to put or remove locks on an object (in dam services) | not necessary if the object is updatable or its workflow is modifiable (ignored if rest_api_dam_no_lock is present) |
rest_api_dam_no_lock | disable locks on object (in dam services) |
|
rest_api_not_required | defines the default value of all fields that would have not have this tag |
|
rest_api_create_not_required | defines the default value of all fields that would have not have this tag |
|
rest_api_update_not_required | defines the default value of all fields that would have not have this tag |
|
rest_api_disable_i18n | disable localization |
|
rest_api_disable_i18n_read | disable localization for the export of internationalized labels |
|
rest_api_disable_i18n_query | disable localization for comparison of internationalized labels in queries | taken into account in jsonquery and fulltext |
rest_api_disable_i18n_write | disables localization when modifying internationalized labels |
|
rest_api_gen_aggs | enables automatic configuration of aggregates on structures that are not damobject (or exported as such) |
|
rest_api_aggs_sorted_on_name2022.4 | enables sorting on aggregate name on all fields linked to this nature | a tag on the field allows to modify this behavior for the field itself |
rest_api_aggs_sorted_on_name_disabled2022.4 | disables sorting on aggregate name on all fields linked to this nature | a tag on the field allows to modify this behavior for the field itself |
rest_api_subquery_nolimit | disables the maximum limit of retrieved children for a jsonquery subquery, for all fields of the structure | the default limit is max 2000 |
rest_api_pref | allows deletion of preferences (in userssetting type objects) |
|
rest_api_etag2021.2.0 11.30 | configure etag for DAM & DATA services | |
rest_api_unsecured_on_forward | disable security on forwarded request | force secured property to false by default for a forwarded invocation (this not overrides the secured parameter value, but only the configuration value) |
rest_api_only_uuid 2023.5 | indicates that we don't want to expose the id (we only expose the uuid) | this tag is not useful if the plugin is configured with the onlyUUID property set to true: in this case, the ID is not exposed in any service. This tag does not concern legacy services, which are not affected. |
rest_api_trigger_parameter2023.6 | allows to overwrite trigger configuration by parameters in request |
|
rest_api_disable_trigger_on_create2023.6 | disable triggers while a create action |
|
rest_api_disable_trigger_on_update2023.6 | disable triggers while an update action |
|
rest_api_disable_trigger_on_partial_update2023.6 | disable triggers while a partial update action (i.e. patch) |
|
rest_api_disable_trigger_on_workflow2023.6 | disable triggers while a workflow action |
|
rest_api_eval_workflow2023.6 | filter action by invoking “before evaluate” method of workflow trigger when listing workflows action of an instance |
|
FIeld tags
Name | Purpose | Comment |
---|---|---|
rest_api_exclude | exclude the field | this tag takes precedence over any inclusion tag or rule |
rest_api_include | include the field |
|
rest_api_dam_data | include the field in the exposed properties of a sub-object subtags syntax: a pipe separated list of
recursivity (auto configuration for child properties) 11.29 Relational type properties are automatically treated as in the classic automatic properties (tag/structure reflection).
| in general, only the id and the name are exported (except for the status for which other properties are exported automatically) |
rest_api_exclude_list | exclude the field of exported data in lists |
|
rest_api_include_list | include the field in exported data in lists |
|
rest_api_exclude_view | exclude the field of exported data in views (resource by id) |
|
rest_api_include_view | include the field in exported data in views (resource by id) |
|
rest_api_group_exclude | exclude this field from the fields that can be grouped (for fields selected as such) |
|
rest_api_group_include | make the field to be a field on which we can group | we can group on a field, such as its type
the fields automatically selected as groupable are
|
rest_api_ignore_facet | set the property config ignoreFacet to true for this field | this property disable the facets for this field, if the facets are activated during a list or a view. Ignored for status field (workflow) |
rest_api_allow_facet 2021.2.0 11.30 | set the property config ignoreFacet to false for this field | useful when ignoreefacet is true by default. This tag cannot be used for any field. Ignored for status field (workflow) |
rest_api_exclude_dam_name | do not use the name selection rule (so use the name field) | by default, for a damobject, the name is the field with tag gallery_title (put the tag on thé fiel with tag gallery_title) |
rest_api_dam_create | for a relational field, make creatable the values of nature (is not useful if the field is editable) | ignored if field or nature has tag rest_api_dam_readonly |
rest_api_dam_update | make a field updatable, or the values of nature of a relational field (is not useful if the field is editable) | ignored if field or nature has tag rest_api_dam_readonly |
rest_api_dam_readonly | disable modification of a field or creation of values of nature of a relational field |
|
rest_api_tree_exclude | disable the automatic activation of the tree mode of a property | the tree mode is activated automatically if the field is a tree field (arbo_field or thesaurus), or a collection tree (a collection with a collection field on itself) |
rest_api_status_by_id | activates workflow status modification by identifier (instead of workflow action) | only for backwards compatibility with older workflow types |
rest_api_required | if the field has this tag, the field is required for create or for update, whatever the other requirement tags are | by default a field is always required for creation or modification, except if it has a requirement tag, or if the structure has one |
rest_api_not_required | if the field has this tag, the field is not required by default neither for create nor for update | see comment for rest_api_required |
rest_api_create_required | if the field has this tag, the field is required for create | see comment for rest_api_required |
rest_api_create_not_required | if the field has this tag, the field is not required for create, except if has a tag to make it required for create | see comment for rest_api_required |
rest_api_update_required | if the field has this tag, the field is required for update | see comment for rest_api_required |
rest_api_update_not_required | if the field has this tag, the field is not required for update, except if has a tag to make it required for update | see comment for rest_api_required |
rest_api_whoami_include | include this field in the whoami retrievable properties |
|
rest_api_whoami_exclude | do not include this field in the whoami retrievable properties |
|
rest_api_profile_include | for the profile, include the field if it is neither rest_api_profile_exclude nor rest_api_exclude | by default fields with tag account are selected for profile |
rest_api_profile_exclude | exclude the field from profile |
|
rest_api_ignore_retrieve_caption | for other field that name, make the field displayable in case of application of retrieve caption security rule |
|
rest_api_assignable | allows collection item assignment of the field (ignored if field is not collection) |
|
rest_api_update_by_value | sets the by value mode for updatable field |
|
rest_api_update_by_value_fields | by default, in by value mode, the value is the name. this tag allows to set other properties to find the object to assign.
Complexe subqueries can’t be configured by tag. |
|
restapi_update_by_value_path_separator
| Indicates the path separator use to split a string value to a path, when modifying a tree metadata field. The tagname must be followed by assign operator then separator (example It is preferable to pass a path by array (JSON) to avoid parsing. | The default separator is configured in plugin parameter |
rest_api_update_by_value_mode | sets the mode for update by value (the mode is the sub tag) | available modes are:
|
rest_api_aggs_nolimit | disables the maximum aggregate limit, for all fields of the structure | beware, if this is necessary to have reliable count pages in the search filters, disabling the limit may impose a significant load on the server and result in saturation or slowness. |
restapi_json | export the value of a text field, if it’s json object or json array, as json (not as string in json) |
|
restapi_json/object | like restapi_json, but only for json object |
|
restapi_json/array | like restapi_json, but only for json array |
|
rest_api_subquery_nolimit | disables the maximum limit of retrieved children for a jsonquery subquery, for this field | see rest_api_subquery_nolimit for structure |
rest_api_not_treecount | disable treecount for this field in aggregates evaluation |
|
rest_api_aggs_sorted_on_name2022.4 | sort by default on the name of the aggregates of this field |
|
rest_api_aggs_sorted_on_name_disabled2022.4 | disable possibility to sort on the name the aggregates of this field |
|
rest_api_aggs_exclude2022.4 | exclude from agg fields |
|
rest_api_mass_import_source deprecated 11.28 rest_api_massimport_source | select the source field (must be a child to the object configured to handle massimport items) | the source field is a field of damobject that will contain the id of source item, after a mass import/upload creation |
rest_api_mass_import_include | select this field to be exported as item data | this is equivalent of rest_api_include for massimportitem (or specific object used for mass import item) (rest_api_include is ignored in this context) |
rest_api_mass_import_agg | select this field to be exported as item agg field | this is equivalent of rest_api_gen_aggs for massimportitem (or specific object used for mass import item) (rest_api_gen_aggs is ignored in this context) |
rest_api_mass_import_field | select this field to be copied to asset when creating asset (or to simulation while simulate asset) | the field is copied to asset only if it exists and has same name and same type. This works only for field with position greater than 7 (status). |
rest_api_mass_import_from_metadata 2024.4 | the value of this item field will be affected by the corresponding value in the simulation each time a simulation calculation is performed | Fields with position <= 7 (status) are ignored, as are fields with the REST_API_MASS_IMPORT_FIELD tag. The copy will only be made if the fields are of the same type (extended to nature for relational fields). By default, the field with the same name is copied. The tag can indicate the name of the source field as a sub-tag. For example, REST_API_MASS_IMPORT_FROM_METADATA/additionalDescription means that the field will be copied from the asset's additionalDescription field. For example
|
rest_api_order_by 2022.1 | allow to set a default order by. You can set this tag on several fields, but only one by field. You can handle sort order on each field with a trailing sort order keyword (separated by slash), as asc or a, for ascendant sort, and desc or d for descendant (default is ascendant and values are not case sensitive). To set field weight, use an integer between rest_api_order_by and order keyword. If no weight is set, the weight depends of the field order (relative to last sorting field). If more than one field is tagged to sort, prefers to set explicitely weight. Examples :
| within the tree service in keyword mode, only the first field is used |
details on the configuration of creations and modifications
service / end points
A resource offers a possibility of creation by the POST method if the rest_api_dam_create
tag is assigned to the corresponding object(structure).
A resource offers a possibility of modification by the PUT method or the PATCH method if the rest_api_dam_update
tag is assigned to the corresponding object(structure).
The rest_api_dam_readonly
tag disables any possibility of creation or modification and is always right whatever the other tags.
The behavior affected by these tags is also applied for other types of resources (apart from all legacy services of course)
editable fields
A field is editable (or assignable when created) if
it is editable in the structure
or if it has the
rest_api_dam_update
tagand if it does not have the
rest_api_dam_readonly
tag
By default, a field that can be modified by a modification service (or affected by a creation service) is always mandatory (when the service is invoked, a value must be provided for this field), by coherence with the operation of legacy services (or any property indicated in its configuration is necessarily mandatory). See the next section to change this default behavior.
Note that the rest_api_dam_create
tag on a field does not have the same meaning as the rest_api_dam_create
tag on the structure, nor does it have exactly the same meaning as rest_api_dam_update
on a field or on the structure.
On a structure
rest_api_dam_create
allows creations : it enables the possible invocation of POST on the resource corresponding to the object/structure.On a structure
rest_api_dam_update
allows modifications : it enables the possible invocation of PUT or PATCH on the resource corresponding to the object/structure.On a field
rest_api_dam_update
allows to enables the assignment of this field by a POST, a PUT or a PATCH.On a field
rest_api_dam_create
has a particular meaning: it is relevant only for relational fields (child or multiple child) and in the context of assignment by values (a value is passed instead of an identifier and the service can create identifiers for the unknown values). It allows you to activate the possibility of creating new instances of metadata for values for which there is no identifier in the database.
change the default mandatory feature
As said in the warning above a modifiable field is always mandatory by default.
The followings tags allow you to alter this behavior:
Tag | For object/structure | For field |
---|---|---|
rest_api_create_not_required |
|
|
rest_api_update_not_required |
|
|
rest_api_not_required |
|
|
rest_api_required |
|
|
rest_api_create_required |
|
|
rest_api_update_required |
|
|
Tags of type xxx_not_required
can be assigned to the structure or to fields of the structure.
Tags of type xxx_update_xxx
are associated with a modification action (thus with the PUT method). Tags of type xxx_create_xxx
are associated with a create action (thus with the POST method). Tags which contain neither update nor create are associated with both actions. For the PATCH method, no field is ever mandatory.
Assigned to a field, a tag of type xxx_not_required
indicates for the associated action that a value does not have to be provided when invoking the corresponding service.
When we assign a tag of type xxx_not_required to the structure, it is as if we put it on all the fields of this structure. Of course it only has an effect on the editable fields.
Tags of type xxx_required
(without “not
") can be assigned only to fields, to somehow restore the behavior they would have if the structure did not have the corresponding tag of type xxx_not_required
.
On the structure, a xxx_not_required
tag is like a default value for all fields.
Examples
Structure | without tag |
|
Editable field | without tag | mandatory for POST and PUT |
Structure | without tag |
|
Editable field 1 | without tag | mandatory for POST and PUT |
Editable field 2 | with tag | mandatory for PUT and not mandatory for POST |
Editable field 3 | with tag | mandatory for POST and not mandatory for PUT |
Editable field 4 | with tag
| not mandatory for POST and PUT |
Structure | with tag | like if all fields have |
Editable field 1 | without tag | mandatory for PUT and not mandatory for POST |
Editable field 2 | with tag | mandatory for PUT and not mandatory for POST |
Editable field 3 | with tag | not mandatory for POST and PUT |
Editable field 4 | with tag
| not mandatory for POST and PUT |
Structure | with tag | like if all fields have |
Editable field 1 | without tag | mandatory for POST and not mandatory for PUT |
Editable field 2 | with tag | not mandatory for POST and PUT |
Editable field 3 | with tag | mandatory for POST and not mandatory for PUT |
Editable field 4 | with tag
| not mandatory for POST and PUT |
Structure | with tag | like if all fields have |
Editable field 1 | without tag | not mandatory for POST and PUT |
Editable field 2 | with tag | not mandatory for POST and PUT |
Editable field 3 | with tag | not mandatory for POST and PUT |
Editable field 4 | with tag
| not mandatory for POST and PUT |
Whatever the tag among rest_api_create_not_required
, rest_api_update_not_required
or rest_api_not_required
, on the structure or the field, if a field
has also the tag | mandatory for POST and not mandatory for PUT |
has also the tag | mandatory for PUT and not mandatory for POST |
has also the tag | mandatory for POST and PUT |
Strict mode versus lazy mode
By default, without one of the above mentioned tags, we are in strict mode. All fields that can be edited are mandatory.
With tags of type
xxx_not_required
on fields, we are in strict mode with explicit behavior for wanted fields. The fields marked with these tags are not mandatory, the others are.With a tag of type
xxx_not_required
on the structure, we are in lazy mode. All fields are non mandatory. You have to mark the fields you want to make mandatory with the tagrest_api_create_required
,rest_api_update_required
orrest_api_required
depending on the action(s) you want to target.