Item and Bitstream level embargo Support (Extending ResourcePolicies)
---------------------------------------------------------------------
Key: DS-895
URL: https://jira.duraspace.org/browse/DS-895
Project: DSpace
Issue Type: Improvement
Components: DSpace API, JSPUI, Unit Testing Framework, XMLUI
Affects Versions: 1.7.1, 1.7.0, 1.6.2
Reporter: Mark Diggory
Fix For: 1.8.0
In working on a preexisting Embargo solution for DSpace we came across the fact
that ResourcePolicies have start and end dates (but that there is a bug in the
implementation needing to be corrected. (see:
https://jira.duraspace.org/browse/DS-171)
I propose that Embargo duration and reason should be captured completely in
Resource Policies such that an Embargo Resource Policy would be created that
controlled acces s to the Item for a specified period. At this time setting
the start date to the date the Item (and/or bitstream) should be released from
embargo will allow the AuthorizationManager to mediate embargo access controls
entirely rather than relying on crontab changes to the Item ResourcePolicies.
With proper implementation, this would allow for the setting of embargo and
control of access at both the Item and Bitstream level
Item Level Embargo
Item <-- ResourcePolicy( name: Embargo, description: "Embargoed as requirement
of Publisher", action:Read, group:Anonymous, start:20120101, end:null)
Bitstream Level Embargo
Bitstream <-- ResourcePolicy( action:Read, group:Anonymous, start:20120101,
end:null)
a.) AuthorizationManager would need to be slightly altered to limit Access
Control to Bitstream if Item is Embargoed
b.) ResourcePolicy may be enhanced to have "name" and "description" fileds
allowing the addition of a meaningful "Embargo Policy" title and a description
of why it was embargoed.
Of course, this doesn't work unless other Policies on the Item don't expose
access to anonymous, So it may be wise to introduce "Restrict" Action in the
Resource Policies that would trump the "Read" Policy and alter
AuthorizationManager to support it with a higher priority
Item Level Embargo
Item <-- ResourcePolicy( name: Embargo, description: "Embargoed as requirement
of Publisher", action:Restrict, group:Anonymous, start:20110101, end:n20120101)
Bitstream Level Embargo
Bitstream <-- ResourcePolicy( name: Embargo, description: "Embargoed as
requirement of Publisher", action:Restrict, group:Anonymous, start:20110101,
end:n20120101)
Ideally, the goal here would be to not utilize the metadata as "system level"
embargo configuration store, which introduces a significant need to code
something like an EmbargoManager and run crontabs to synchronize
ResourcePolicies with that system level metadata. A better solution just uses
ResourcePolicies and requires no supporting cron services ultimately making
Embargo a more intrinsic feature of the model regardless of how it is presented
in submission steps, Item views or impacts search/browse behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
