Page History

...

When an embargo is set on either an item level or a bitstream level, a new ResourcePolicy (i.e. access policy) is added to the corresponding Item or Bitstream. This ResourcePolicy will automatically control the lifting of the embargo (when the embargo date passes). An embargo lift date is generally stored as the "start date" of such a policy. Essentially, this means that the access rights defined in the policy do not get applied until after that date passes (and prior to that date, the access rights will default to Admin only).

The scheduled, manual "embargo-lifter" commands (used prior to DSpace 3) are no longer necessary and not recommended to run.

Managing Embargoes on existing Items

...

Configuring and using Embargo in DSpace Submission User Interface

Introduction

The following sections describe the steps needed to configure and use Embargo functionality in the DSpace Submission User Interface.

As a DSpace administrator, you may choose to integrate either Simple or Advanced Embargo as part of the item submission process in the user interface. These are outlined in detail in the sections Simple Embargo Settings and Advanced Embargo Settings.

This preference is stored in the dspace.cfg value webui.submission.restrictstep.enableAdvancedForm.  If not set, the default is for Simple Embargo.

On the level of an individual item, a new Private/Public state has been introduced 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, …)

Configuring the Embargo UI

As already mentioned the user will be given the opportunity to choose between:

• Simple Embargo Settings
• Advanced Embargo Settings

To switch between the two, you need to set following variable in the dspace.cfg file (or your local.cfg, see Configuration Reference). A value of false (the default) enables the Simple settings while a value of true enables the Advanced settings.

webui.submission.restrictstep.enableAdvancedForm=false

Submission Process

item-submission.xml

To enable the embargo, changes are required to the item-submission.xml file, located in your [dspace]/config/ directory. This file determines which steps are executed in the submission of a new item (see also Submission User Interface).

Two new submission steps have been introduced in the file. By default, they are not activated:

• AccessStep: the step in which the user can set the embargo at item level, effectively restricting access to the item metadata.
• UploadWithEmbargoStep: the step in which the user can set the embargo at bitstream level. If this step is enabled, the old UploadStep must be disabled.  Leaving both steps enabled will result in a system failure.

Here is an extract from the new file:

<!--Step 3 will be to Manage Item access.
       <step>
           <heading>submit.progressbar.access</heading>
           <processing-class>org.dspace.submit.step.AccessStep</processing-class>
           <jspui-binding>org.dspace.app.webui.submit.step.JSPAccessStep</jspui-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 enable the new Embargo, ensure that the new steps are uncommented and the old UploadStep is commented out.

Simple Embargo Settings

Using the simple embargo settings, submitters will be able to define embargoes bound to specific dates, that are applied to all anonymous and default read access. To keep the interface simple, options to apply embargoes for particular groups of DSpace users are not shown. The simple embargo settings interface assumes that embargoes always start immediately upon submission, so only end dates are configurable.

AccessStep

The simple AccessStep Embargo form renders three options for the user:

• Private item: to hide an item's metadata from all search and browse indexes, as well as external interfaces such as OAI-PMH.
• Embargo Access until Specific Date: to indicate a date until which the item will be embargoed.
• Reason: to elaborate on the specific reason why an item is under embargo.

When Embargo is set, it applies to Anonymous or to any other Group that is indicated to have default read access for that specific collection.

This shows how the Access step is rendered, using the simple embargo settings:

Image Removed

UploadWithEmbargoStep

The simple UploadWithEmbargoStep form renders two new fields for the user:

• Embargo Access until Specific Date: to indicate a date until which the bitstream will be embargoed. When left empty, no embargo will be applied.
• Reason: to elaborate on the specific reason why the bitstream is under embargo.

These fields will be preloaded with the values set in the AccessStep.

The following picture shows the form for the Upload step, rendered using the simple embargo settings with preloaded values:

Image Removed

Advanced Embargo Settings

The Advanced Embargo settings are really designed with a submitter in mind who is aware of user groups in DSpace and has understanding of how Resource Policies work.

AccessStep

The Advanced AccessStep Embargo step allows the users to manage more fine-grained resource policies to attach to the item.

The form will render the following fields:

• Policies List: list of the custom policies already added.
• Private Item: whether to hide an item's metadata from all search and browse indexes, as well as external interfaces such as OAI-PMH.
• Name: to give a name to the policy.
• Groups: to indicate the user groups to which the policy will apply.
• Visible/Embargoed: whether the Item will be visible or embargoed for that specific group.
• Embargo Access until Specific Date: to indicate a date until which the item will be embargoed.
• Reason: to elaborate on the specific reason why the policy is applied.

The last two fields will be enabled only when Embargoed has been selected.

This step gives the opportunity to the user to manage the policy manually, so that combinations such as the following will be possible:

• Set Embargo for Anonymous
• Set Embargo for anyone, except for the users belonging to a specific group
• Set Embargo for specific groups, but not for other groups ...

Here is a screenshot of the Access step form that will be rendered for the advanced embargo settings:

Image Removed

UploadWithEmbargoStep

UploadWithEmbargoStep for Advanced Embargo settings displays an additional Policies button next to Edit in the list of uploaded files.
Clicking it brings you to the a page where you can edit existing policies on the bitstream and add new ones.

Image Removed

When the button is pushed, a form similar to the one in the AccessStep will be rendered, making it possible to manage the policies at bitstream level.

Image Removed

Restrict list of displayed groups to specific (sub)groups

For large instances of DSpace, the list of Groups can be quite long. Groups can be nested. This means that not only EPersons can be members of groups, but groups themselves can belong to other groups.

When advanced embargo settings are enabled, you can limit the list of groups displayed to the submitters to subgroups of a particular group.

To use this feature, assign the super group name to following configuration value in dspace.cfg:

webui.submission.restrictstep.groups=name_of_the_supergroup

Starting in DSpace 7, embargo (and lease) settings are configurable via a Spring Bean configuration file [dspace]/config/spring/api/access-conditions.xml

For detailed information on configuring your Embargo options (and other related options like lease or restrict to a particular group of users), see the section on "Configuring the File Upload Step" of the Submission User Interface.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.

Private/Public Item

It is also possible to adjust the Private/Public state of an item after it has been archived in the repository.

Here is a screenshot showing the updated Edit Item dialog:

Image Removed  This can be achieved from either the "Admin Search" (/admin/search), or from the "Status" tab under "Edit Item".

Private items are not retrievable through the DSpace search, browse or Discovery indexes.

Therefor, an admin-only view has been created to browse all private items. Here is a screenshot of this new form:

Image RemovedTherefore, an "Admin Search" option is provided, which allows you to search across all items, including private or withdrawn items.  You can also filter your results to display only private items.

Pre-3.0 Embargo Migration Routine

...

[dspace]/bin/dspace migrate-embargo -a

Technical Specifications

Introduction

The following sections illustrate the technical changes that have been made to the back-end to add the new Advanced Embargo functionality.

...

This method has been adjusted to leave custom policies, added by the users, in place and add the default collection policies only if there are no custom policies.

...

AuthorizeService

Some methods have been changed on AuthorizeManager AuthorizeService to manage the new fields and some convenience methods have been introduced:

...

Creating Embargoes via Metadata

Introduction

Prior to DSpace 3.0, all DSpace embargoes were stored as metadata.  While embargoes are no longer stored permanently in metadata fields (they are now stored on ResourcePolicies, i.e. access policies), embargoes can still be initialized via metadata fields.  

...

You are free to use existing metadata fields, or create new fields. If you choose the latter, you must understand that the embargo system does not create or configure these fields: i.e. you must follow all the standard documented procedures for actually creating them (i.e. adding them to the metadata registry, or to display templates, etc) - this does not happen automatically. Likewise, if you want the field for "terms" to appear in submission screens and workflows, you must follow the documented procedure for configurable submission (basically, this means adding the field to inputsubmission-forms.xml). The flexibility of metadata configuration makes if easy for you to restrict embargoes to specific collections, since configurable submission can be defined per collection.

...