Request a Copy

Introduction

The request a copy functionality was added to DSpace as a measure to facilitate access in those cases when uploaded content can not be openly shared with the entire world immediately after submission into DSpace. It gives users an efficient way to request access to the original submitter of the item, who can approve this access with the click of a button. This practice complies with most applicable policies as the submitter interacts directly with the requester on a case by case basis.

Requesting a copy using the XML User Interface

Users can request a copy by clicking the file thumbnail or the blue lock symbol displayed on files that are restricted to them.

The request form asks the user for his or her name, email address and message where the reason for requesting access can be entered.

After clicking request copy at the bottom of this form, the original submitter of the item will receive an email containing the details of the request. The email also contains a link with a token that brings the original submitter to a page where he or she can either grant or reject access. If the original submitter can not evaluate the request, he or she can forward this email to the right person, who can use the link containing the token without having to log into DSpace.

Each of these buttons registers the choice of the submitter, displaying the following form in which an additional reason for granting or rejecting the access can be added.

After hitting send, the contents of this form will be sent together with the associated files to the email address of the requester. In case the access is rejected, only the reason will be sent to the requester. 

After responding positively to a request for copy, the person who approved is presented with an optional form to ask the repository administrator to alter the access rights of the item, allowing unrestricted open access to everyone.

Requesting a copy using the JSP User Interface

Users can request a copy by clicking the green "Request a Copy" button for files that are restricted to them.

The request form asks the user for his or her name, email address and message where the reason for requesting access can be entered.

After clicking request copy at the bottom of this form, the original submitter of the item will receive an email containing the details of the request. The email also contains a link with a token that brings the original submitter to a page where he or she can either grant or reject access. If the original submitter can not evaluate the request, he or she can forward this email to the right person, who can use the link containing the token without having to log into DSpace.

After approving or rejecting the request for a copy, the contents of the form will be sent together with the associated files to the email address of the requester. In case the access is rejected, only the reason will be sent to the requester. 

(Optional) Requesting a copy with Help Desk workflow

(Optional) Request Item with HelpDesk intermediary, is steered towards having your Repository Support staff act as a helpdesk that receives all incoming RequestItem requests, and then processes them. This adds the options of "Initial Reply to Requestor" to let the requestor know that their request is being worked on, and an option "Author Permission Request" which allows the helpdesk to email the author of the document, as not all documents are deposited by the author, or the author will need to be tracked down by a support staff, as DSpace might not have their current email address.

Initial Reply to Requester

Author permission request, includes information about the original request (requester name, requester email, requester's reason for requesting). The author/submitter's name and email address will be pre-populated in the form from the submitter, but the email address and author name are editable, as the submitter's of content to DSpace aren't always the author.

Email templates

Most of the email templates used by Request a Copy are treated just like other email templates in DSpace. The templates can be found in the /config/emails directory and can be altered just by changing the contents and restarting tomcat.

The templates for emails that the requester receives, that could have been customized by the approver in the aforementioned dialog are not managed as separate email template files. These defaults are stored in the Messages.properties file under the keys

Configuration parameters

Request a copy is enabled in DSpace by default. Only two configuration parameters in dspace.cfg relate to Request a Copy:

Selecting Request a Copy strategy via Spring Configuration

The process that DSpace uses to determine who is the recipient of the Item Request is configurable in this Spring file: [dspace]/config/spring/api/requestitem.xml

Configure who gets request via a metadata field

By default the RequestItemMetadataStrategy is enabled, but falls back to the Item Submitter eperson's name and email. You can configure the RequestItemMetadataStrategy to load the author's name and email address if you set that information into an item metadata field.  For example:

<bean class="org.dspace.app.requestitem.RequestItemMetadataStrategy"
 id="org.dspace.app.requestitem.RequestItemAuthorExtractor">
 <!-- 
 Uncomment these properties if you want lookup in metadata the email and the name of the author to contact for request copy.
 If you don't configure that or if the requested item doesn't have these metadata the submitter data are used as fail over
 
 <property name="emailMetadata" value="schema.element.qualifier" />
 <property name="fullNameMatadata" value="schema.element.qualifier" /> 
 
 --> 
 </bean>

Configure this as follows:

1. Create a metadata field which you'd like to use to store this email address (and optionally a second metadata field for the full name).
   1. Hint: You may wish to add this metadata field to your "metadata.hide.*" settings in local.cfg in order to ensure this metadata field is hidden from normal users & is only visible to Administrative users.  That way this email address will NOT appear in Item display pages (except to Administrators)
2. Uncomment the "emailMetadata" setting above, and configure it's "value" to use the new metadata field.
3. Edit the Item(s) which you wish to use this field.  Add the new metadata field to those items, given it a value of the email address which will receive the request for copy.  By default, if an Item does NOT have this metadata field, the request for copy will still go to the Item's submitter.

Configure all requests to go to a helpdesk email

Another common request strategy is the use a single Helpdesk email address to receive all of these requests (see corresponding helpdesk configs in dspace.cfg above). If you wish to use the Helpdesk Strategy, you must first comment out the default RequestItemMetadataStrategy,  bean and uncomment this bean:

<!-- HelpDesk to instead get RequestItem emails-->
<bean class="org.dspace.app.requestitem.RequestItemHelpdeskStrategy"
        id="org.dspace.app.requestitem.RequestItemAuthorExtractor"></bean>