discoverygarden/dgi_actions

Provides a framework to support minting and deletion of identifiers either locally or with external services.

DGI Actions

Introduction

Provides a framework to support minting and deletion of identifiers either locally or with external services.

Requirements

This module requires the following modules/libraries:

• Islandora

Installation

Install as usual, see this for further information.

Configuration

This module and its submodules come with no configuration out of the box. Below is the steps for configuring the included dgi_actions_ark_identifier.

Entity configuration

The main configuration overview for all entities used within the module is located at admin/config/dgi_actions.

Data profile configuration

Data profile entities contain data used when building up a request to a service. These values are retrieved from the entity and are passed along with an HTTP request. EZID provides a good example of how this is used.

1. Create a new data profile: admin/config/dgi_actions/data_profile/add.
2. Give the data profile a name.
3. Select the entity and bundle for which the data will be retrieved from. In this example choose node and Repository Item.
4. Select the DataProfile plugin that's being used. In this example choose ERC.
5. For the three ERC fields choose which fields to map from.
6. Save the data profile.

Service data configuration

Service data entities contain configuration used for interacting with external APIs.

1. Create a new service data: admin/config/dgi_actions/service_data/add.
2. Give the service data a name.
3. Select the ServiceData plugin that's being used. In this example choose EZID.
4. Fill in the required fields that is provided by the EZID plugin.
5. Save the service data.

Identifier configuration

Identifiers tie everything together. In the event ServiceData and DataProfiles are being used they store references to the configured entities from above. Similarly, they store where the minted identifier is going to be placed.

1. Create a new identifier: admin/config/dgi_actions/identifier/add.
2. Give the identifier a name.
3. Select the entity and bundle for which the data will be stored on. In this example choose node and Repository Item.
4. Select the field in which the identifier will be stored in. For the example choose whichever field you want.
5. Choose the ServiceData being used for the request from the dropdown if needed. For the example choose the one created above.
6. Choose the DataProfile being used for the request from the dropdown if needed. For the example choose the one created above.
7. Save the identifier.

Action configuration

An action is required for each identifier being minted and optionally deleted.

1. Create a new action: admin/config/system/actions.
2. Under Create an advanced action choose either the mint or delete action to be configured. For the example choose Mint ARK EZID Identifier.
3. Choose the identifier entity that the action will trigger and save.
4. Repeat the above and instead choose Delete ARK EZID Identifier and save.

Context configuration

Drupal's Context module is used in conjunction with conditions and entity hooks to handle minting and deleting with a custom condition to check if a entity already has a persistent identifier.

1. Create a new context: admin/structure/context/add.
2. Give it a name and optionally fill out the other fields and save.
3. Configure the conditions required for an identifier to be minted. For the example create two conditions: Node Bundle and Entity Has Persistent Identifier. Configure the Node Bundle condition to look for the Repository Item bundle and Content from hook. Configure the Entity Has Persistent Identifier condition to use the Identifier created above and Content from hook. Negate this condition such that it will only mint if it does not already exist.
4. Choose require all conditions.
5. Add a reaction choose Mints an identifier.
6. Under entity choose whatever the mint action created above was called.
7. Repeat the above and instead choose the Deletes an identifier reaction and conditions that satsify deletion. Normally this would be just removing the negation on Entity Has Persistent Identifier.

New Integrations

To create a new identifier minting integration at least a MintIdentifier action is required.

Optionally a DataProfile plugin, a ServiceDataType plugin and a DeleteIdentifer action can be created if required.

Troubleshooting/Issues

Having problems or solved a problem? Contact discoverygarden.

Maintainers/Sponsors

Current maintainers:

• discoverygarden

Development

If you would like to contribute to this module, please check out the helpful Documentation, Developers section on Islandora.ca and contact discoverygarden.

License

GPLv3

dgi_actions's Issues

ERC DataProfile doesn't serialize entity reference fields well

I have an ERC DataProfile with a TypedRelation field type as the source for "Who". This results in sending "Who:65, relators:abr" (or the similar) to EZID. I know the actual populating of "What", "When", and "Who" get set @ https://github.com/discoverygarden/dgi_actions/blob/v1.1.0/modules/dgi_actions_ezid/src/Plugin/DataProfile/Erc.php#L40, but I haven't traced back how the passed data array it is set and if we can account for it there or if it needs to be handled further upstream.

Allow minting ARKs on Nodes as an Action from the Content management page's action drop-down

We occasionally want to manually trigger minting an identifier outside of a context reaction. However, there are two issues preventing this.

First, the Advanced Action configuration form creates an action with the "type" property of "entity" which prevents it from appearing in the Content page's action dropdown. This is despite the fact that the identifer_entity property is set to an identifier entity configured for nodes. I was able to get around this by exporting the config, manually updating it, and re-importing it. This felt like an unnecessary step as the action's type could/should be inferred from the selected identifier entity and set automatically. Alternatively, the action form could provide a field to select the entity type manually.

Second, the action never save's the entity's updated identifier value. The save call used to be there but was dropped in adb81bd as it caused issues when the action was being called via a hook triggered context reaction, but without it I can't save the identifier when calling the action without that presave hook.

One way to address this is Mark Jordan's persistent_identifiers module had a similar issue so they added a flag to the call to enable/disable the save as necessary depending on how it is being called.

Another is to create a new action plugin, extending MintIdentifier, and overwriting setIdentifierField with something like:

parent::setIdentifierField();
$this->entity->save();

Then we could use that plugin for my action instead of the existing one.

EZID Service Data Form's Namespace field needs clarification

For EZID, the "namespace" is simply the initial "ark:/99999/" which may or may not be synonymous with a minting "shoulder". Simply adding the namespace will cause the minter to throw an error. E.g. using the test namespace ("ark:/99999/") to create a test ark this field should be "ark:/99999/fk4".

I recommend changing the label to "Shoulder" and providing the test minting shoulder in the description text as an example.

Missing data profile type for Handle

It seems the Handle's data profile type is missing in this file:
https://github.com/discoverygarden/dgi_actions/blob/main/modules/dgi_actions_handle/config/schema/dgi_actions_handle.schema.yml

I enabled all 3 sub modules, so there should be 3 types of data profiles here: one for EZID (ERC), one for Handle, and one for ARK. But there is only ERC data profile in the select box.

Simon.

EZID ARKs are not resolveable

While the dgi_actions_ark_identifier submodule can mint ARKS, their _status value is currently set to reserved so that they can be deleted (as noted in the README).

However, these ARKS, according to the EZID documentation, are not sent to the resolver, which means on the EZID page (E.g. https://ezid.cdlib.org/id/ark:/99999/fk46d7bs2v) the "Identifier as URL" for the identifier (e.g. https://n2t.net/ark:/99999/fk46d7bs2v) will return a 404 unless the repository manually sets the _status to public.

Also, I would think that the expected behavior for the resulting persistent identifier link would be the resolver URL leading back to the object itself, not to the EZID object page.