Page History

...

• Edit Item
• Edit Bitstream
• Wildcard Policy Admin Tool

...

Configuring and using Embargo's in DSpace 3.0

Introduction

The following document describes sections describe the steps needed to configure and use the new Embargo functionality on 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 new embargo is not supported on JSPUI.

Database

Run As a first step, the script:following script needs to be executed to ensure that your DSpace database gets extended with 3 new fields, required by the new embargo.

_ \- dspace/etc/\[postgres-oracle\]/database_schema_18-3.sql_

Here is the script for postgresFor PostgreSQL databases, the executed commands are:

ALTER TABLE resourcepolicy ADD rpname VARCHAR(30);
ALTER TABLE resourcepolicy ADD rptype VARCHAR(30);
ALTER TABLE resourcepolicy ADD rpdescription VARCHAR(100);

ALTER TABLE item ADD discoverable BOOLEAN;

update item set discoverable=true;

and here the one for OracleFor Oracle databases, the executed commands are:

ALTER TABLE resourcepolicy
  ADD (
        rpname rpname VARCHAR2(30);
        rpdescription VARCHAR2(100);
        rptype VARCHAR2(30)
      );


ALTER TABLE item ADD discoverable NUMBER(1);

...

• Simple Embargo Settings
• Advanced Embargo Settings

To do it is needed switch between the two, you need to set the following variable in the dspace.cfg file.

...

To enable the new embargo have changes are required to be edited the item-submission.xml file, located in your config directory. This file determines which steps are executed in the submission of a new item.

Two new submission steps have been introduced in the file. By default, they are not activated yet has been modified, introducing two new steps:

• AccessStep: it is a the step in which the user can set the embargo at item level, effectively restricting access to the item metadata.
• UploadWithEmbargoStep: it is 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.

...

<!--Step 3 will be to Manage Item access.
       <step>
           <heading>submit.progressbar.access</heading>
           <processing-class>org.dspace.submit.step.AccessStep</processing-class>
           <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>
           <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.UploadWithEmbargoStep</xmlui-binding>
           <workflow-editable>true</workflow-editable>
       </step>
        -->

To enable the new Embargo occurs uncomment-out , ensure that the new steps and comment-out are uncommented, while the old UploadStep needs to be commented out.

Simple Embargo Settings

AccessStep

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

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.Private item: to make an item not searchable
• Embargo Access until Specific Date: to indicate a date until when the item will be embargoed.
• Reason: to provide a description of the Item statuselaborate 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.

Here is the form that will be rendered in case of This shows how the Access step is rendered, using the simple embargo settings:

UploadWithEmbargoStep

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

• Embargo Access until Specific Date: to indicate a date until when the bitstream will be embargoed. When left empty, no embargo will be applied.
• Reason: to provide a description of the bitstream statuselaborate 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 that will be rendered in case of for the Upload step, rendered using the simple embargo settings with preloaded values:

...

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 notions of the way how Policies work.

AccessStep

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

...

• Policies List: list of the custom policies already added
• Private Item: to make an item not searchablehide 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 group for which the policy will apply to.
• Visible/Embargoed: to set if the Item will be visible or embargoed for that specific group
• Embargo Access until Specific Date: to indicate a date until the item will be embargoed
• Reason: to provide a description of the Item statuselaborate on the specific reason why the policy is applied.

Last two fields will be enabled only in case of Embargoed has been selected.

This step gives the opportunity to the user to manage by hand the exceptionpolicy manually, so that combination as the following will be possible:

...

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

UploadWithEmbargoStep

UploadWithEmbaroStep in case of Advanced Embargo will render only a new button on the file list:

• Policies: pushing it will be possible to navigate into the Policies management.

Here is possible to see the button: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.

When the button will be pushed a form similar to the one in the AccessStep will be render and will make makes it possible to manage the policies at bitstream level.

Here is a screenshot of the form:

Image Removed

Load only specific groups

In case of advanced form has been given another opportunity to the users: load only some specific groups in the "groups" select box.

Image Added

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.cfgTo do it occurs to assign a value to the following configuration field:

xmlui.submission.restrictstep.groups=name_of_the_supergroup

If Once a value is assigned to the parameter will be loaded only the group specific group is configured as supergroup here, only the groups belonging to the indicated group otherwise, by will be loaded in the selection dialogs. By default,  all the all groups will be are loaded.

Private/Public Item

The users could handle It is possible to adjust the Private/Public state of an item also after it has been archived in the EditItem _functionalityrepository.

Here is a screenshot that show the formshowing the updated Edit Item dialog:

Make an item private means that it won't be searchable.

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 To browse between all the private items a view has been created, here is a screenshot of the this new form:

...

Pre-3.0 Embargo Migration Routine

A migration routine has been developed to migrate the current Embargo to the new one.

...

Introduction

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

...

• TYPE_SUBMISSION: all the policies added automatically during the submission process
• TYPE_WORKFLOW: all the policies added automatically during the workflow stage
• TYPE_CUSTOM: all the custom policies added by users
• TYPE_INHERITED: all the policies inherited by the DSO father.

Here is an example of all information contained in a single policy recordAn embargo policy record will be something similar to the following:

policy_id: 4847
resource_type_id: 2
resource_id: 89
action_id: 0
eperson_id:
epersongroup_id: 0
start_date: 2013-01-01
end_date:
rpname: Embargo Policy
rpdescription:  Embargoed through 2012
rptype: TYPE_CUSTOM

...

Item.inheritCollectionDefaultPolicies(Collection c)

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

AuthorizeManager

Some methods have been changed on AuthorizeManager _to manage _the new fields ans some convenient methods have been introduced like:

public static List<ResourcePolicy> findPoliciesByDSOAndType(Context c, DSpaceObject o, String type);
public static void removeAllPoliciesByDSOAndTypeNotEqualsTo(Context c, DSpaceObject o, String type);
public static boolean isAnIdenticalPolicyAlreadyInPlace(Context c, DSpaceObject o, ResourcePolicy rp);
public static ResourcePolicy createOrModifyPolicy(ResourcePolicy policy, Context context, String name, int idGroup, EPerson ePerson, Date embargoDate, int action, String reason, DSpaceObject dso);

...

Withdraw Item

The function withdrawn feature to withdraw an item from the repository has been modified to keep all the custom policies in place.

Reinstate Item

The function reinstate have feature to reinstate an item in the repository has been modified to preserves preserve existing custom policies.

...

Pre-DSpace 3.0 Embargo Compatibility

Current Embargo solution have been modified to adjust the policies setter and lifter

...

Pre-DSpace 3.0 Embargo

Embargo model and life-cycle

...