[
https://jira.duraspace.org/browse/DS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Diggory updated DS-895:
----------------------------
Description:
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.
was:
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.
> 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
> 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. (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
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
