Extending DAM document libraries

The out of the box configuration only contains one DAM library which structure name is asset. This default structure is configured with recommended properties.

Most of these properties reflect technical properties of an asset (eg: width, height, assetnature...).

If you don't think you need some property, it is highly recommended to hide from users rather than to remove it from the structure.

Few of these properties are purely functional and are common to all DAMs (such as keywords, folder…)

Creating new libraries

During the project implementation, you might need to create additional libraries. This need can come from different use cases:

• Differentiate assets with different functional metadata. Exemple: for product assets, you will probably need to store a product ID / SKU / product category for each asset

• Ease governance of assets. Exemple: a legacy library can be created to store old assets not used, but kept for legacy. Such assets are generally not available to all users, and it can be easier to store them in a different repository.

It is recommended to duplicate the asset structure for creating a new library rather than creating the library from a fresh new structure. Doing so, you are sure not to forget required configuration.

Check list after creating a new library from a BO perspective

• Give a functional name to the library

• Create a new entry in the rubrique object

• Assign the created rubrique to roles in charge of managing this library

• Adapt permissions groups if the library is related to governance.

• Create additional BO dashboard widgets to ease management for users

Check list after creating a new library from a Portal perspective

• Should a dedicated context in the DAM explore page be created?

• Adapt dam-import configuration to make sure authorised users only have access to import assets in this new library.

Extending a library

You are free to add specific metadata to any library. If you have created additional libraries and you want to add a property to multiple of the libraries, remember you can copy a property from one structure to another.

Check list after creating a property from a BO perspective

• Give a functional name to the property

• Make sure the new property is in the appropriate section, and at the right position

• Make sure you have adapted faces for this new property

• Make sure the property has BO interface configuration tags (left search, simple search, advanced search)

• Should this property be configured for analytics

• If property is text, does it need internationalisation support?

Check list after creating a property from a Portal perspective

• Add rest_api_include tag on the property if the field is neither in list or in view and you still need to use it in portal

• Configure the displays in which this property should be used

• Configure the filters for using this new property in the portal

• Configure import and edit configurations if you need specific behaviours

Extending metadata

It is recommended to create new kinds of metadata by duplicating an existing metadata structure. However, you need to be careful about different configuration points:

Check list after creating a metadata from a BO perspective

• Give a functional name to the metadata

• Create a new entry in the rubrique object

• Assign the created rubrique to roles in charge of managing this metadata

• Create additional BO dashboard widgets to ease management for users

• Add appropriate security tags (pkg/security/secugroup/xxx). More info about the tags : https://crossmedia.atlassian.net/wiki/spaces/WD/pages/1629978625/Setting+Up+Permissions+and+Roles#Identifying-eligible-structures

• Check/Set the object family for the new metadata. For the new metadata to be used in the new user interface for managing roles and permissions, it’s family should be set to one those below :

  • Opened metadata

  • Closed metadata

  • AI metadata

• Adapt permissions groups for this metadata

• Adapt BO interface tags (allow multi-update, analytics tab, …)

Check list after creating a metadata from a Portal perspective

• Add REST API tags to enable creation of instances from REST APIs (rest_api_dam_create)

• Add REST API tags to enable etags (rest_api_etag)

Extending workflows

With starter-kit, DAM libraries and metadata use 2 workflows. If you want to enrich the default provided workflows, we recommend creating a new workflow and building statuses and actions on those instead of changing the default provided ones.

It is legitimate to have multiple workflows when you need to introduce specific behaviours, however, in order to ease security configuration, it is highly recommended to keep focal points for your different steps and to adopt naming conventions for your actions.

Further reading

Adapting The Data Model

Setting Up Workflows

Setting Up Analytics

Setting Up Permissions and Roles