Guide to Plugin configurations
Plugins are utilized throughout Curator to serve a multitude of purposes.
Example uses of plugins vary from transferring hi-res to a final location to transcoding files using a different EPR file, or archiving certain assets.
This guide will explain how to configure plugins, as well as explaining plugins and their configurations, including detailed instructions on how to modify them to suit your needs.
Where to find plugins
Plugins come out of the box, and can typically be copied and then modified to fit the intended purpose of the plugin.
Out-of-the-box plugins can be found within the Curator Server install Directory, which can generally be found here:
C:\Program Files\IPV\Curator\Server\Config\w[]-u[]-win[]-m[]\WebApplications
Understanding Plugins
In most cases, plugins will call and point towards a single MediaStore configuration, or, in some cases, multiple MediaStores chained one after the other.
Let's look at a typical plugin that moves a hi-res file from one location to another as an example.
A plugin created for this task could select the assets that the user would like to move the hi-res.
Within the plugin configuration, it would point to a specific MediaStore such as “HI-RES-MOVE” in order to do this.
The HI-RES-MOVE MediaStore would then house the source MetadataName of the current hi-res location and information including where the destination is going to be as well as other parameters, such as whether the transfer of the file is going to involve moving or copying the file.
When a plugin is actioned against assets in the web applications, a log of events will be made available within Process Engine. The related jobs will also be shown in Device Director.
Configuration of a Plugin
Sendtodestination is the most commonly used plugin type: whilst there are other plugin options available, most things can be archived with sendtodestination.
If you can understand the making of a sendtodestination plugin, it will help you to understand more complex plugins.
If you need further assistance, reach out to IPV support for further guidance on more unique and complex plugins.
Below is an example image of a typical sendtodestination plugin makeup.
Looking at the plugin configuration from top to bottom, let's go through what each section means and what options are available to configure.
The top section is shown as follows:
<filters>
<classes>
<allow type="media"/>
<allow type="audio"/>
<allow type="image"/>
<allow type="scratchpad"/>
</classes>
<instances>
</instances>
</filters>
The next section begins with ‘PEServiceConfiguration’.
<PEServiceConfiguration processDefinitionName="Plug-in - Send to GenericV4"/>
This is the configuration that defines the workflow which will be called by the workflow. Typically, for a sendtodestination, we would use Plug-in - Send to GenericV4, however there are some rare instances in which we do stray from it.
Other plugins, such as the search and report plugin, will call a different workflow here. Please reach out to IPV support if you're unsure of which workflow to use.
This section also shows us the available asset types that the plugin is enabled for.
If you have a plugin that you wish to disable for image assets specifically, for example, you would need to remove the “<allow type="image"/>” section here.
“Scratchpads” are what we consider Collections and productions.
Note: When selecting assets across multiple asset types, if the selection includes an asset type that is not enabled in the configuration, the plugin will be disabled for the entire selection.
Another option available is to filter by metadata on the selected assets. For example, the below is what a default value looks like:
<filters>
<classes>
</classes>
<instances>
<allow type="id" value=""/>
<deny type="id" value=""/>
<allow type="metadata" metadataName="" value=""/>
<deny> type="metadata" metadataName="" value=""/>
</instances>
</filters>
As showcased above, there are two types that can be configured. The first, ID, allows you to state that asset id X is allowed or is denied access to this plugin. This is beneficial if you know that certain assets should never be allowed access to this plugin, or alternatively is the only asset that should have access.
However, the second option, allows you to configure rules around the metadata fields an asset may have. Let's take the below example:
<filters>
<classes>
</classes>
<instances>
<allow type="id" value=""/>
<deny type="id" value=""/>
<allow type="metadata" metadataName="Origin" value="London"/>
<deny type="metadata" metadataName="Archived" value="True"/>
</instances>
</filters>
In the above example, only assets that have an original value of London and are not archived can use the plugin. This may be beneficial for multi-site environments, where the plugin will carry out an action specifically designed for assets in London.
Note: In the current form, this section can only be utilized for hard-coded values. For example ENUM or Boolean fields. This section will NOT work for wildcards.
The ‘SendAssetsToDestinationConfiguration’ section is the reference to the plugin pointing to MediaStore configurations.
An example of this is shown below:
<SendAssetToDestinationConfiguration>
<Destinations>
<!-- User -->
<Destination name="Deliver file to third party" locationPath="THIRDPARTY-FILE-DELIVERY" />
<Destination name="Retrieve the Hi-Res file" locationPath="DELIVER-HI-RES" />
<Destination name="Retrieve the proxy" locationPath="DELIVER-PROXY" />
</Destinations>
</SendAssetToDestinationConfiguration>
The Destination name is showing the description of the option within the plugin.
The LocationPath is the MediaStore which will be used if the plugin option is actioned.
You can increase the number of destinations by adding a new line in the config; you must have at least one destination for the plugin to function.
Note: When only one option is available, this drop-down will be removed from the plugin UI.
In the example, a singular MediaStore is displayed for each option. In some cases, you may wish to have more than one MediaStore to be used when selecting one option in the plugin window within Process Engine.
An example of how to do this is shown below:
<Destination name="Retrieve the Hi-Res file" locationPath="DELIVER-HI-RES,DELIVER-PROXY" />
With this option selected, the first MediaStore will be actioned first (in this case DELIVER-HI-RES) When the first MediaStore has finished its job, the assets will be handed to the next MediaStore on the chain.
Rename the destination in order to point it to your MediaStore.
The next block displayed is the library files:
<LibraryFiles>
<File name="kendo.2019.1.220.min" path="Plugins/Scripts" type="js"/>
<File name="PEArgumentHelpers" path="Plugins/Scripts" type="js"/>
<File name="PluginUtilities" path="Plugins/Scripts" type="js"/>
<File name="CuratorEnums" path="Plugins/Scripts" type="js"/>
</LibraryFiles>
These are the required Javascript files used to build the plugin within the web apps.
They may vary between each type of plugin, typically if you see Javascript errors with your plugins, it's usually related to these files, with most errors being either access-related or related to missing files.
These files are stored on the IIS server hosting the web apps. These will generally be stored somewhere like this: C:\inetpub\wwwroot\CuratorClipSelect\Plugins\Scripts
Please note that Clip Link has its own separate store too.
The final section is the PluginUIConfiguration. This section is what it says on the tin. With various configuration options, we have to change the UI makeup of the plugin. Each part is listed below:
Filename – the file name of the plugin being called. (MUST be the same as the plugin file name - this is CASE SENSITIVE)
Folder – The folder in which the plugin configurations sit. (Typically this stays as SendToDestination)
Icon – The icon which is to be displayed for the plugin (see the section below for a set of steps on how to change this)
Namespace - The namespace of the plugin (In most cases this stays the same as SendToDestination, or its respective plugin type, e.g.,: CreateProduction)
contextMenuTitle – The title of the context menu that appears when hovering over the plugin.
tooltip – The description of the plugin when selected.
alwaysEnabled – This option will ignore the asset filtering options in the first section. (Typically we don’t change this)
hideOkCancel – Hide the OK and Cancel buttons. (Typically we don’t change this)
hideHeader - Hide the Header/Name of the plugin. (Typically we don’t change this)
Permissions
Plugin permissions work within a folder structure placed in the Curator Server install location.
A separate guide has been written to explain how the plugin permissions work and how they can be distributed between workgroups. This can be found here: https://ipv.helpjuice.com/en_US/plugins/360017495477-Plugin-Permissions-How-they-work
Changing Plugin Icons
You may want to change the icons that are displayed in the Curator web apps so that the plugins display an image that is more familiar or unique to the plugin at hand.
If you wish to do this, we recommend doing a simple Google search for ‘Plugin Icons’.
Curator supports the use of both SVG and PNG file types for plugin icons, and will scale to size. Example plugin icons can be downloaded from a range of websites in these formats.
IPV recommends that you use plugin icons that are not blocky and do not have bold images, as these do not display well in the small-scaled area which Curator has to scale down to.
To change a plugin icon:
- Place the newly downloaded icon SVG/PNG in the plugin source store. This can be found on the IIS server which the websites (Clip Link/Clip Select) are being hosted on. An example of this path can be found here: C:\inetpub\wwwroot\CuratorClipSelect\Plugins\SendToDestination
Note: The above example may vary depending on how your plugin has been configured. - Update the PluginUIConfiguration (described at the end of the Configuration of a Plugin section above) with the new icon name.
Once these details have been updated, the new icon should be correctly displayed following an IIS restart and clearing of cache.