Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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)

Status
title11.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

Status
title2021.2.0
Status
colourYellow
title11.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_name

Status
title2022.4

sort by default on the name of the aggregates of this field

rest_api_aggs_sorted_on_name_disabled

Status
title2022.4

disable possibility to sort on the name the aggregates of this field

rest_api_aggs_exclude

Status
title2022.4

exclude from agg fields

rest_api_mass_import_source

Status
titledeprecated 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

Status
title2022.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 ((warning) for best performance, however, it is preferable to use an integer "position" field).

details on the configuration of creations and modifications

...

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

...