Asset Deletion 3 - Configure deletion policies

Asset Deletion 3 cleans up the asset version history, removes asset versions and the corresponding asset files.

With Asset Deletion 3, you can set up policies for different asset types and domains, and define which versions are kept. A report shows, which versions are kept and why.

The configuration for Asset Deletion 3 consists of three parts:  

• Create asset version policies: They define which asset types in which domains are processed by the asset deletion process.

• Configuration of the Asset Deletion 3 report: Use the report to check, which asset version policy is applied to an asset. Find constraints that prevent a version to be deleted.

• Configuration of the server actions: The automatic server action cleans up the whole database and affected asset files. The individual server action executes the deletion on a single asset.

Prerequisites

• Administration rights for the censhare Admin Client

• Understanding of the deletion process in Asset Deletion 3

• Basic understanding of censhare with assets, asset relations, asset types and domains in censhare

Introduction

To decide which asset versions delete, censhare uses the policies that are defined in the censhare Admin Client in the Master data in the Asset versions table. Deletion policies are the core feature of Asset Deletion 3. If applied, an asset version is marked for deletion and later physically deleted. If not applicable, an asset version is skipped during a deletion run and kept. Likewise, the corresponding storage items are either deleted or kept.

In the Asset versions table, you define the policies for different asset types in different domains. If at least one policy matches during the deletion run, censhare marks the respective versions. Otherwise, the asset and its versions are skipped.

Each asset version policy consists of three parts:

• The selection criteria to apply the policy

• The definition of which asset versions to keep

• The period to keep asset versions that are marked for deletion

There are three parameters as selection criteria. Their combination decides about the selection:

• domain

• 2nd domain

• asset type

Note: A policy also applies to asset sub-types and assets in sub-domains.

To determine which policy to apply, censhare chooses the policy that fits best to the combination of domain, 2nd domain, and asset type. For example, there are two policies that match: One matches with the asset type and one with the exact asset sub-type. The latter fits best.

The mode of a policy defines which asset versions are kept. There are three modes:

• Keep all versions: censhare keeps all versions. No asset version is deleted.

• Delete all versions: censhare only keeps the latest version.

• Delete selected versions: Define a set of versions to keep.

If you set the Delete selected versions mode, you must define to keep the first X and the latest Y versions. censhare deletes all versions in between.

When censhare marks an asset for deletion, it waits for a certain period before it deletes the asset version. During this time, the asset version is not deleted physically and can be restored if necessary. This period is defined in the respective policy.

If an asset is marked for deletion, censhare does not apply any policy to an asset. In the asset XML, the deletion attribute has the value 1. Assets that are planned for deletion, have the deletion value 4. You can overrule the policies by manually setting the Mark for deletion or Plan for deletion flag manually in the censhare Client.

The selection process for asset version policies

Defining the parameters for the selection of a policy

As mentioned above, censhare uses three parameters for the selection of a policy:  

• the first Domain,

• the 2nd Domain and

• the Asset Type.

Each item is inherited to the respective sub-items (sub-domains or sub-types). For example, if the domain "root.Germany." is set in a policy, the policy is also applied to the domain "root.Germany.Munich.". If you set the asset type to "picture.", the policy also applies to the asset subtype "picture.barcode." To overwrite an inherited policy, you must define a new policy for the respective sub-domain and/or asset sub-type.

Here is an example of the domain parameter of a policy, and some asset examples:

• The policy has the Domain "root.magazine.".

• The domain of asset 1 is "root.magazine.". - This is a match.

• The domain of asset 2 is "root.magazine.pic_pool." - This is a match.

• The domain of asset 3 is "root.". - This is not a match because it does not match the domain or subdomain of the policy.

If you want to prevent that a policy applies to a sub-domain or asset sub-type, define a policy for this. For example, there is a policy for the asset type "picture." that should not to apply for the sub-type "picture.barcode.". Define a dedicated policy for “picture.barcide.”.

Finding the best matching policy

If there is a set of matching policies that applies to an asset, censhare selects the best matching policy. This is done in the following order:

1. domain

2. 2nd domain

3. asset type

For each parameter, censhare determines the best matching ones. Only these are considered for the next parameter evaluation.  

The best match is always when the parameters in the asset and the policy are the same. For example:

• Asset: Domain = root.admin.

• Policy = Domain = root.admin.

For example, there is an asset with the Domain = root.admin. There are four policies:

• Policy 1: Domain = root.admin.one.

• Policy 2: Domain = root.admin.

• Policy 3: Domain = root.admin.

• Policy 4: Domain = root.admin.

The best matches are policies 2, 3, and 4. Policy 1 does not match and is ignored.

Next, censhare checks the 2nd Domain:

• The inspected asset has the 2nd Domain = root.accnt.two.

• Policy 2: 2nd Domain = root.accnt.

• Policy 3: 2nd Domain = root.accnt.

• Policy 4: 2nd Domain = root.

There is no perfect match for any of the policies. The best matches are policies 2 and 3. Policy 4 is ignored.

Next, censhare checks the asset type:

• The inspected asset has the Asset Type = image.logo.

• Policy 2: type = image.logo.

• Policy 3: type = image.

Policy 2 is a perfect match and is applied in this case.

Examples of selections

The asset deletion policies:

The following examples show assets and the matching policy:

The keep versions parameter

In the asset version policy, you can configure the following parameters:

• Keep for ## hours before deletion

• Keep the first ## versions

• Keep the last ## versions

• Keep the last ## days

The last three parameters Keep the first ## versions, Keep the last ## versions and Keep the last ## days are only considered if the Mode is set to Delete Selected Versions.  

There are already set values in the fields when creating a new policy. Change them according to your needs. As it depends on your use case, there are no rules of thumb for the parameters.  

If you enter a 0 into all three parameters Keep the first ## versions, Keep the last ## versions and Keep the last ## days, the Mode behaves like the Delete all versions Mode. Only the latest version is kept.  

Keep for ## hours before deletion

The parameter determines the period between an asset version is marked for deletion and the deletion time. The parameter is only considered if the asset version in consideration is already marked for deletion. When the asset version is marked for deletion, the period starts and the timestamp is set to the system time. Only after this period, the version is deleted physically. Until then, you can restore the version. 

For example, the time is set to 24h. When the asset is processed, the server checks the timestamp. If the elapsed time between the current time and the timestamp is less or equal 24h, the asset version is not deleted.

Keep the first ## versions

This parameter defines how many versions (counting from the first) are kept. Versions within this range are not marked for deletion. The asset deletion report shows this as a constraint.

Note: The latest version of an asset cannot be deleted. Therefore, if you set the parameter to 0, the latest one is not marked for deletion and a constraint is displayed in the report.

Keep the last ## versions/## days

The parameter Keep the last ## versions defines how many versions are kept counting from the latest one. The parameter Keep the last ## days defines that censhare keeps all versions that have been created during this time.  

censhare checks both parameters and if at least one matches, the asset version is not marked for deletion. The asset deletion report shows this as a constraint.

Note: To ignore one or both parameters, set the desired ones to 0.

Key steps

Create a policy

In the censhare Admin Client in the Master data folder:  

1. Go to the Asset versions table and open it with a double click.

2. Click the Plus button on the top bar to create a new entry.

3. Select the asset type.

4. Select the Domain.

5. Select the 2nd Domain.

6. Select the Mode.

7. Select the Keep for xx before deletion parameter.

8. If you have selected Delete selected versions, enter the desired values.

9. Click OK to save the policy.

Result

• Overall understanding of asset version policies.

• Understanding the selection of matching asset version policies.

• Understanding the parameters of an asset version rule.

• Knowledge to set up your own policies.

Next steps

Learn more about the Asset Deletion 3 report to test your policies.