Page tree

Current Release

This documentation covers the latest release of DSpace, version 6.x. Looking for another version? See all documentation.

Skip to end of metadata
Go to start of metadata

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.

A DSpace item where access to the content has been restricted (XMLUI)

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.

A DSpace item with restricted content (JSPUI)

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.

request_item.admintemplate for the message that will be sent to the administrator of the repository, after the original submitter requests to have the permissions changed for this item.
request_item.authortemplate for the message that will be sent to the original submitter of an item with the request for copy.

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

itemRequest.response.body.approveDefault message for informing the requester of the approval
itemRequest.response.body.rejectDefault message for informing the requester of the rejection
itemRequest.response.body.contactAuthorDefault message for the helpdesk to contact the author
itemRequest.response.body.contactRequesterDefault message for the helpdesk to contact the requester

Configuration parameters

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

Property:

request.item.type

Example Value

request.item.type = all

Informational Note

This parameter manages who can file a request for an item. The parameter is optional. When it is empty or commented out, request a copy is disabled across the entire repository. When set to all, any user can file a request for a copy. When set to logged, only registered users can file a request for copy.

Property:

mail.helpdesk

Example Value

mail.helpdesk = foo@bar.com

Informational Note

In JSPUI, the email address assigned to this parameter will receive the emails both for granting or rejecting request a copy requests, as well as requests to change item policies. In XMLUI, the parameter will also receive these requests to change item policies. However, the actual requests for copy in XMLUI will initially be directed at the email address of the original submitter. When this email address can not be retrieved, the address in mail.helpdesk will be used as a fallback.

This parameter is optional. If it is empty or commented out, it will default to mail.admin.

WARNING: This setting is only utilized if the RequestItemHelpdeskStrategy bean is enabled in [dspace]/config/spring/api/requestitem.xml (see below)

Property:

request.item.helpdesk.override

Example Value

request.item.helpdesk.override = true

Informational Note

Should all Request Copy emails go to the mail.helpdesk instead of the item submitter? Default is false, which sends Item Requests to the item submitter.

WARNING: This setting is only utilized if the RequestItemHelpdeskStrategy bean is enabled in [dspace]/config/spring/api/requestitem.xml (see below)


 

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

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>


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>


  • No labels

1 Comment

  1. TODO: would be nice if this were to be updated with Mirage 2 screenshots for the XMLUI