An embargo is a temporary access restriction placed on metadata or bitstreams. Its scope or duration may vary, but the fact that it eventually expires is what distinguishes it from other content restrictions. For example, it is not unusual for content destined for DSpace to come with permanent restrictions on use or access based on license-driven or other IP-based requirements that limit access to institutionally affiliated users. Restrictions such as these are imposed and managed using standard administrative tools in DSpace, typically by attaching specific policies to Items, Collections, Bitstreams, etc. Embargo functionality was originally introduced as part of DSpace 1.6, enabling embargoes on the level of items that applied to all bitstreams included in the item. In DSpace 3.0, this functionality has been extended for the XML User Interface, enabling embargoes on the level of individual bitstreams.
New Embargo Functionality
Embargoes can be applied per item and per bitstream. The item level embargo will be the default for every bitstream, although it could be customized at bitstream level.
This preference is stored in the dspace.cfg value webui.submission.restrictstep.enableAdvancedForm.
Please note that the configuration parameter name has been changed in DSpace 4.0 from xmlui.submission.restrictstep.enableAdvancedForm to webui.submission.restrictstep.enableAdvancedForm
On the level of an individual item, a new Private/Public state has been introducted to control the visibility of item metadata in the different indexes serving the DSpace web interface (search, browse, discovery), as well as machine interfaces (REST-API, OAI-PMH, …)
- Edit Item
- Edit Bitstream
- Wildcard Policy Admin Tool
Configuring and using Embargo's in DSpace 3.0+
The following sections describe the steps needed to configure and use the new Embargo functionality in DSpace 3.0.
Note: when the embargo will be set at item level or bitstream level a new ResourcePolicy will be added.Note: the
|The new embargo is|
|supported on JSPUI since DSpace 4.0.|
As a first step, the following script needs to be executed to ensure that your DSpace database gets extended with 3 new fields, required by the new embargo.
<!--Step 3 will be to Manage Item access. <step> <heading>submit.progressbar.access</heading> <processing-class>org.dspace.dspace.submit.step.AccessStep</processing-class> <jspui-binding>org.dspace.app.webui.submit.step.AccessStep<JSPAccessStep</processingjspui-class>binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.AccessStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> --> <!-- Step 4 Upload Item with Embargo Features (not supported in JSPUI) to enable this step, please make sure to comment-out the previous step "UploadStep" <step> <heading>submit.progressbar.upload</heading> <processing-class>org.dspace.submit.step.UploadWithEmbargoStep</processing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPUploadWithEmbargoStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.UploadWithEmbargoStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> -->
To use this feature, assign the super group name to following configuration value in dspace.cfg:
Please note that the configuration parameter name has been changed in DSpace 4.0 from xmlui.submission.restrictstep.groups to webui.submission.restrictstep.groups
Once a specific group is configured as supergroup here, only the groups belonging to the indicated group will be loaded in the selection dialogs. By default, all groups are loaded.