[ 
https://jira.duraspace.org/browse/DS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Diggory updated DS-895:
----------------------------

    Affects Version/s:     (was: 1.7.1)
                           (was: 1.7.0)
                       3.0
                       1.8.2
        Fix Version/s: 3.0
             Assignee: Mark Diggory
              Summary: Advanced Embargo Support  (was: Item and Bitstream level 
embargo Support (Extending ResourcePolicies))
    
> 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
>             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) 
> 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

        

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to