...
An example of a correctly configured download approval flow presented here consists of two stages. In the first stage, the administrator configures the download request workflow. It is here where the administrator can decide on all the criteria that limit the download of assets. The second stage is additional configuration in the general settings of the Media Manager. In some cases, it might be necessary to perform other configuration configurations prior to setting up the workflow, for example creating additional metadata fields.
The following elements are required for a functional approval process:
A workflow with the a minimum of three stages: a pending stage, an approved stage, and a rejected stage.
Enabling the download request in the settings of the Media Manager.
...
The basic download approval workflow consist consists of three stages: a pending stage, an approved stage, and a rejected stage.
...
It is also, for example, possible to create a loop from the rejected stage back to the pending stage, if reconsideration should be possible (not included in this example of workflow configuration). For instance, if the reason for rejection is insufficient information provided by the requesting user, this can be fixed by communicating through the comments section of the task. If the conditions for approval are then met, the user responsible for the task can approve the previously rejected request.
| Info |
|---|
Please do not enable “Limit this workflow to one task per item“, as this will only allow only one user to request downlad |
Configuration:
Step | Configuration | Explanation |
|---|---|---|
“Request download” transition | Name: selected by the user Transition type: Manual Unique ID: selected by the user Description: selected by the user (optional) Constraints: execution condition, string input constraints, date input constraint | The transition is manual, because it is initiated by a deliberate action from a user - in this case, a request for asset download. “Any user can transition” constraints is selected to enable any user with the ability to download assets to make the request without having to have additional roles in the system. The input constraints is what builds the request form. In this case, the requesting user will be asked to state their name, their origin, reason for downloading and the deadline for the request. |
“Pending approval” stage | Name: selected by the user Unique ID: selected by the user Description: selected by the user (optional) Mark as completed: no Relevant Meta Fields: - Stage owner: Assign to instance owner Labels: selected from the list of created as custom | The name of the stage is also the name of the task. The optional description will provide the assigned user with the explanation of what is expected in this stage. In this case, the stage owner is the content owner (the person responsible for the management of a particular asset). The configuration requires selecting the correct MIR metadata field, where the content owner is stated. For more information, please refer to the information box about dynamic assignment, located under the table. The label will be displayed on the task. |
“Approve” transition | Name: selected by the user Transition type: Manual Unique ID: selected by the user Description: selected by the user (optional) Constraints: upload constraint | The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions. Constraint:
|
“Approved” stage | Name: selected by the user Unique ID: selected by the user Description: selected by the user (optional) Mark as completed: yes Relevant Meta Fields: - Stage owner: Unassigned Labels: selected from the list of created as custom | The name of the stage is also the name of the task. The optional description will provide the assigned user with the explanation of what is expected in this stage. The label will be displayed on the task. Marking the stage as complete means that the this particular workflow instance will be archived after this stage. |
“Reject” transition | Name: selected by the user Transition type: Manual Unique ID: selected by the user Description: selected by the user (optional) Constraints: string input constraint | The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions. Constraint:
|
“Rejected” stage | Name: selected by the user Unique ID: selected by the user Description: selected by the user (optional) Mark as completed: yes Relevant Meta Fields: - Stage owner: Unassigned Labels: selected from the list of created as custom | The name of the stage is also the name of the task. The optional description will provide the assigned user with the explanation of what is expected in this stage. The label will be displayed on the task. Marking the stage as complete means that the this particular workflow instance will be archived after this stage. |
| Info |
|---|
Dynamic stage owner assignment Dynamic stage assignment of owner is a functionality created for the systems where each asset has a content owner in mind. In order for this to be configured there needs to be a metadata field with the following properties:
This is how the resulting field will look like in Media Manager: |
...
Below are shown the 8 valid scenarios which you can configure the download request.
All users have to request all assets | Metafield = Any |
All users have to request all assets except selected assets | Metafield = Bypass |
All users have to request all assets except for selected formats | Metafield = Any |
All users have to request all assets except selected assets and selected formats | Metafield = Bypass |
No users have to request any assets | Disable download request altogether |
No users have to request any assets except selected assets | Metafield = Require |
No users have to request any assets except selected formats | Metafield = Bypass |
No users have to request any assets except selected assets and selected formats | Metafield = Require |
| Info |
|---|
Please be aware that this does not into consideration that there is the bypass role “Download_Approval_Bypass “ which, as previously stated, will disregard any configured download restrictions. |
...