[
https://jira.duraspace.org/browse/DS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Diggory resolved DS-895.
-----------------------------
Resolution: Fixed
> Advanced Embargo Support
> ------------------------
>
> 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.6.2, 1.8.2, 3.0
> Reporter: Mark Diggory
> Assignee: Mark Diggory
> Priority: Major
> Labels: has-pull-request
> Fix For: 3.0
>
>
> In working on a preexisting Embargo solution for DSpace we came across the
> fact that ResourcePolicies have start and end dates. (see:
> https://jira.duraspace.org/browse/DS-171)
> See further details at
> https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
> 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
