Extending DAM funds

The out of the box configuration only contains one DAM fund 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 dont think you need some property, it is highly recommended to hide from users rather than to remove it from the structure.

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

Creating new funds

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

Qualify 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 fund 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 fund rather than creating the fund from a fresh new structure. Doing so, you are sure not to forget required configuration.

Check list after creating a new fund from a BO perspective

Give a functional name to the fund
Create a new entry in the rubrique object
Assign the created rubrique to roles in charge of managing this fund
Adapt permissions groups if the fund is related to governance.
Create additional BO dashboard widgets to ease management for users

Check list after creating a new fund 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 fund.

Extending a fund

You are free to add specific metadata to any fund. If you have created additional funds and you want to add a property to multiple of the funds, 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)
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 funds 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.

Extending the starter-kit data model