Supported in 7.1 or above
Request a Copy was not available in DSpace 7.0. It was restored in DSpace 7.1. See DSpace Release 7.0 Status
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 User Interface
Users can request a copy by clicking the file thumbnail or the name of a file that the user is restricted from viewing.
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.
While responding positively to a request for copy, the person who approved may also ask the repository administrator to alter the access rights of the item, allowing unrestricted open access to everyone, by checking "Change to open access".
(Optional) Requesting a copy with Help Desk workflow
Available in 7.5 or later. However, in 7.5, users approving/rejecting these requests via the HelpDesk workflow must first authenticate. This is a known bug as described in https://github.com/DSpace/DSpace/issues/8636
As of 7.6, the HelpDesk workflow can be performed without requiring authentication (issue #8636 has been fixed)
(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.
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.admin||template 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.author||template 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.approve||Default message for informing the requester of the approval|
|itemRequest.response.body.reject||Default message for informing the requester of the rejection|
|itemRequest.response.body.contactAuthor||Default message for the helpdesk to contact the author|
|itemRequest.response.body.contactRequester||Default message for the helpdesk to contact the requester|
Request a copy is enabled by default. These configuration parameters in dspace.cfg relate to Request a Copy:
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.
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.
This parameter is optional. If it is empty or commented out, it will default to
WARNING: This setting is only utilized if the
Should all Request Copy emails go to the
WARNING: This setting is only utilized if the
Selecting Request a Copy strategy
The process that DSpace uses to determine who is the recipient of the Item Request is configurable in this Spring file:
New in DSpace 7
The strategy is selected using a Spring
<alias alias='org.dspace.app.requestitem.RequestItemAuthorExtractor' name='theStrategyClass'/>. Previously this was done by moving the
id to the selected
New in DSpace 7.6
The strategy is selected by configuring it into the
RequestItemMetadataStrategy as a constructor argument.
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:
Configure this as follows:
- 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).
- 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)
- Uncomment the "emailMetadata" setting above, and configure it's "value" to use the new metadata field.
- 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
Prior to 7.6, all users who wish to respond to a request to the helpdesk email must first login to DSpace. See https://github.com/DSpace/DSpace/issues/8636 This was fixed in 7.6.
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 replace the references to the default
RequestItemMetadataStrategy, bean with the
Configure all requests to go to the administrators of a Collection
This strategy sends mail to all of the members of the administrators group for the collection which owns the item.
Combine multiple strategies
This strategy combines the results of other strategies into a single list of email recipients. Pass the strategy a single constructor argument, being a list of the strategy beans whose output should be combined.
In the following example, email will be sent to the address(es) found in the configured metadata fields (or to the submitter if none), and to the owning collection's administrators.