Page History

...

Edit Item
Edit Bitstream
Wildcard Policy Admin Tool

...

Admin Documentation

Introduction

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

ResourcePolicy

describes the steps needed to configure the new Embargo functionality on DSpace 3.0.

Note: when When the embargo will be set at item level or bitstream level a new ResourcePolicy will be added.

Three new attributes have been introduced in the ResourcePolicy class:

rpname: resource policy name
rptype: resource policy type
rpdescription: resource policy description

While rpname and rpdescription _are fields manageable by the users the _rptype is a fields managed by the system. It represents a type that a resource policy can assume beteween the following:

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.

An embargo policy record will be something similar to the following:

Code Block

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

To manage Private/Public state a new boolean attribute has been added to the Item:

isDiscoverable

When and Item is private the attribute will assume the value false.

Item.inheritCollectionDefaultPolicies(Collection c)

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

AuthorizeManager

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

Code Block

language	java

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);

Withdrawn

The function withdrawn has been modified to keep all the custom policies in place.

Reinstate

The function reinstate have been modified to preserves existing custom policies.

Current Embargo

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

Admin Documentation

Introduction

The following document describes the steps needed to configure the new Embargo functionality on 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 the script:

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

Here is the script for postgres:

Code Block

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 Oracle:

Code Block
ALTER TABLE resourcepolicy ADD ( rpname rpname VARCHAR2(30); rpdescription VARCHAR2(100); rptype VARCHAR2(30) ); ALTER TABLE item ADD discoverable NUMBER(1);

dspace.cfg

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

Simple Embargo Settings
Advanced Embargo Settings

To do it is needed to set the following variable in the dspace.cfg file.

Code Block
xmlui.submission.restrictstep.enableAdvancedForm=false

Submission Process

item-submission.xml

To enable the new embargo have to be edited the item-submission.xml file.

This file has been modified, introducing two new steps:

AccessStep: it is a step in which the user can set the embargo at item level
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.

Here is an extract from the new file:

Code Block

<!--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 new Embargo occurs uncomment-out the new steps and comment-out the old UploadStep.

Simple Embargo Settings

AccessStep

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

Private item: to make an item not searchable
Embargo Access until Specific Date: to indicate a date until the item will be embargoed
Reason: to provide a description of the Item status

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 simple embargo settings:

Image Removed

UploadWithEmbargoStep

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

Embargo Access until Specific Date: to indicate a date until the bitstream will be embargoed
Reason: to provide a description of the bitstream status

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 simple embargo settings with preloaded values:

Image Removed

Advanced Embargo Settings

AccessStep

The Advanced AccessStep Embargo form 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: to make an item not searchable
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 status

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 exception, so that combination 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 another groups ...

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

Image Removed

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:

Image Removed

When the button will be pushed a form similar to the one in the AccessStep will be render and will make 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.

To do it occurs to assign a value to the following configuration field:

xmlui.submission.restrictstep.groups=name_of_the_supergroup

If a value is assigned to the parameter will be loaded only the group belonging to the indicated group otherwise, by default, all the groups will be loaded.

Private/Public Item

The users could handle Private/Public item also in the EditItem _functionality.

Here is a screenshot that show the form:

Image Removed

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

To browse between all the private items a view has been created, here is a screenshot of the new form:

Image Removed

Current Embargo Migration Routine

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

To execute it occurs to run the following command:

...

Note: the new embargo is not supported on JSPUI.

Database

Run the script:

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

Here is the script for postgres:

Code Block

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 Oracle:

Code Block
ALTER TABLE resourcepolicy ADD ( rpname rpname VARCHAR2(30); rpdescription VARCHAR2(100); rptype VARCHAR2(30) ); ALTER TABLE item ADD discoverable NUMBER(1);

dspace.cfg

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

Simple Embargo Settings
Advanced Embargo Settings

To do it is needed to set the following variable in the dspace.cfg file.

Code Block
xmlui.submission.restrictstep.enableAdvancedForm=false

Submission Process

item-submission.xml

To enable the new embargo have to be edited the item-submission.xml file.

This file has been modified, introducing two new steps:

AccessStep: it is a step in which the user can set the embargo at item level
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.

Here is an extract from the new file:

Code Block

<!--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 new Embargo occurs uncomment-out the new steps and comment-out the old UploadStep.

Simple Embargo Settings

AccessStep

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

Private item: to make an item not searchable
Embargo Access until Specific Date: to indicate a date until the item will be embargoed
Reason: to provide a description of the Item status

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 simple embargo settings:

Image Added

UploadWithEmbargoStep

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

Embargo Access until Specific Date: to indicate a date until the bitstream will be embargoed
Reason: to provide a description of the bitstream status

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 simple embargo settings with preloaded values:

Image Added

Advanced Embargo Settings

AccessStep

The Advanced AccessStep Embargo form 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: to make an item not searchable
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 status

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 exception, so that combination 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 another groups ...

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

Image Added

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:

Image Added

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

Here is a screenshot of the form:

Image Added

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.

To do it occurs to assign a value to the following configuration field:

xmlui.submission.restrictstep.groups=name_of_the_supergroup

If a value is assigned to the parameter will be loaded only the group belonging to the indicated group otherwise, by default, all the groups will be loaded.

Private/Public Item

The users could handle Private/Public item also in the EditItem _functionality.

Here is a screenshot that show the form:

Image Added

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

To browse between all the private items a view has been created, here is a screenshot of the new form:

Image Added

Current Embargo Migration Routine

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

To execute it occurs to run the following command:

Code Block
./dspace migrate-embargo -a

Technical Specifications

Introduction

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

ResourcePolicy

When the embargo will be set at item level or bitstream level a new ResourcePolicy will be added.

Three new attributes have been introduced in the ResourcePolicy class:

rpname: resource policy name
rptype: resource policy type
rpdescription: resource policy description

While rpname and rpdescription _are fields manageable by the users the _rptype is a fields managed by the system. It represents a type that a resource policy can assume beteween the following:

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.

An embargo policy record will be something similar to the following:

Code Block

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

To manage Private/Public state a new boolean attribute has been added to the Item:

isDiscoverable

When and Item is private the attribute will assume the value false.

Item.inheritCollectionDefaultPolicies(Collection c)

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

AuthorizeManager

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

Code Block

language	java

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);

Withdrawn

The function withdrawn has been modified to keep all the custom policies in place.

Reinstate

The function reinstate have been modified to preserves existing custom policies.

Current Embargo

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

...

Legacy Embargo

Embargo model and life-cycle

...

All Versions

DSpace Documentation

Page tree

Page History

Versions Compared

Old Version 7

New Version 8

Key

Admin Documentation

Introduction

ResourcePolicy

Item

Item.inheritCollectionDefaultPolicies(Collection c)

AuthorizeManager

Withdrawn

Reinstate

Current Embargo

Admin Documentation

Introduction

Database

dspace.cfg

Submission Process

item-submission.xml

Simple Embargo Settings

AccessStep

UploadWithEmbargoStep

Advanced Embargo Settings

AccessStep

UploadWithEmbargoStep

Load only specific groups

Private/Public Item

Current Embargo Migration Routine

Database

dspace.cfg

Submission Process

item-submission.xml

Simple Embargo Settings

AccessStep

UploadWithEmbargoStep

Advanced Embargo Settings

AccessStep

UploadWithEmbargoStep

Load only specific groups

Private/Public Item

Current Embargo Migration Routine

Technical Specifications

Introduction

ResourcePolicy

Item

Item.inheritCollectionDefaultPolicies(Collection c)

AuthorizeManager

Withdrawn

Reinstate

Current Embargo

Legacy Embargo

Embargo model and life-cycle