[
https://jira.duraspace.org/browse/DS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-895:
---------------------------
Fix Version/s: (was: 1.8.0)
> 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.6.2, 1.7.0, 1.7.1
> Reporter: Mark Diggory
>
> 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)
> 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:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
