Tags

Here are all tags for dam and data API (or affiliates).

Structure tags

Name

Purpose

Comment

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

see

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

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

  • field names, (examples : rest_api_dam_data/name, rest_api_dam_data/name|status)

  • field positions ((examples : rest_api_dam_data/2|3 ie created and modified)

  • tagname prefixed with @ (example: rest_api_dam_data/@xxx all fields of the nature tagged with xxx)

  • no subtags: all the viewable or listable or indexed fields (example: rest_api_dam_data)

  • note it’s possible to mix them (example: rest_api_dam_data/name|@xxx )

 

recursivity (auto configuration for child properties) 11.29

Relational type properties are automatically treated as in the classic automatic properties (tag/structure reflection).

  • A property path can be indicated. There is no automatic recursivity for these properties. rest_api_dam_data/status.id|status.name|status.color.name

  • We can for dam_data by tag indicate recursivity (@tag/* for recursivity (default), or @tag/! for no recursivity).

  • status fields are always processed recursively (if recursivity is disabled, reflection is disabled and there is a simple hard coded configuration: status.id, status.name, status.color.name)

 

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

  • either child but not “tree”, or string (data or sentence only)

  • is not binary (file, image, blob), nor separator,

  • if its position is not 1, 5 or 6

  • is not a multiple relational

  • does not meet any of the above conditions

the fields automatically selected as groupable are

  • either visible in a list (structure)

  • or indexed (if string)

  • either tagged rest_api_include or rest_api_include_list or rest_api_include_view

  • or tagged rest_api_group_include

  • but tagged rest_api_group_exclude

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

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.

  • if no subtag, the name is used (i.e. rest_api_update_by_value_fields does nothing whether present or not)

  • otherwyse the following subtags is the list of field selector separated with pipes. Field selectors can be

    • name (or position) of field (example rest_api_update_by_value_fields/code|bussinessunit)

    • starting with @, a tagname (means all fields in the nature with this tag will be selected) (example rest_api_update_by_value_fields/@keyword_update_by_value_property

    • names, positions and tag selectors can be mixed

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 restapi_update_by_value_path_separator=| means a value like this Earth|Europe|France will be splitted to [Earth, Europe, France].

It is preferable to pass a path by array (JSON) to avoid parsing.

The default separator is configured in plugin parameter damValuePathSeparator (default value is \ (backslash))

rest_api_update_by_value_mode

sets the mode for update by value (the mode is the sub tag)

available modes are:

  • most_recent (order by modified desc, take the first one)

  • less_recent (order by modified asc, take the first one)

  • any (no order by, take the first one)

  • first (order by pid asc, take the first one)

  • last (order by pid desc, take the first one)

  • default (any)

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_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 as same name and same type. This works only for field with position greater than 7 (status).

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 :

  • rest_api_order_by: the data are sorted by this field, ascendantly

  • rest_api_order_by/desc: the data are sorted by this field, descendantly

  • rest_api_order_by/1/a: the data are sorted by this field as secondary field (if there is one with no weight, or weight 0), ascendantly

  • rest_api_order_by/2: the data are sorted by this field as tertiary field (if there is one with no weight, or weight 0, and one with weight 1), ascendantly

within the tree service in keyword mode, only the first field is used
To sort thesaurus on string values with numbers, add the tag thesaurus/digitized_label ( for best performance, however, it is preferable to use an integer "position" field).

 

 

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 tag

  • and 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

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 rest_api_create_not_required

mandatory for PUT and not mandatory for POST

Editable field 3

with tag rest_api_update_not_required

mandatory for POST and not mandatory for PUT

Editable field 4

with tag

rest_api_not_required

not mandatory for POST and PUT

Structure

with tag rest_api_create_not_required

like if all fields have rest_api_create_not_required

Editable field 1

without tag

mandatory for PUT and not mandatory for POST

Editable field 2

with tag rest_api_create_not_required

mandatory for PUT and not mandatory for POST

Editable field 3

with tag rest_api_update_not_required

not mandatory for POST and PUT

Editable field 4

with tag

rest_api_not_required

not mandatory for POST and PUT

Structure

with tag rest_api_update_not_required

like if all fields have rest_api_update_not_required

Editable field 1

without tag

mandatory for POST and not mandatory for PUT

Editable field 2

with tag rest_api_create_not_required

not mandatory for POST and PUT

Editable field 3

with tag rest_api_update_not_required

mandatory for POST and not mandatory for PUT

Editable field 4

with tag

rest_api_not_required

not mandatory for POST and PUT

Structure

with tag rest_api_not_required

like if all fields have rest_api_create_not_requiredand rest_api_update_not_required

Editable field 1

without tag

not mandatory for POST and PUT

Editable field 2

with tag rest_api_create_not_required

not mandatory for POST and PUT

Editable field 3

with tag rest_api_update_not_required

not mandatory for POST and PUT

Editable field 4

with tag

rest_api_not_required

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 rest_api_create_required

mandatory for POST and not mandatory for PUT

has also the tag rest_api_update_required

mandatory for PUT and not mandatory for POST

has also the tag rest_api_required

mandatory for POST and PUT

Strict mode versus lazy mode

  1. By default, without one of the above mentioned tags, we are in strict mode. All fields that can be edited are mandatory.

  2. 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.

  3. 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 tag rest_api_create_required, rest_api_update_required or rest_api_required depending on the action(s) you want to target.