Details

    • Attachments:
      0
    • Comments:
      4
    • Documentation Status:
      Complete or Committed

      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)

      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.

        Attachments

          Issue Links

            Activity

            Hide
            mdiggory Mark Diggory added a comment -

            final solution that will resolve issues in the following JIRA tickets.

            Show
            mdiggory Mark Diggory added a comment - final solution that will resolve issues in the following JIRA tickets.
            Hide
            helix84 Ivan Masár added a comment -
            Show
            helix84 Ivan Masár added a comment - pull request: https://github.com/DSpace/DSpace/pull/43
            Hide
            robintaylor Robin Taylor added a comment -

            I believe this has been merged https://github.com/DSpace/DSpace/pull/43.

            Show
            robintaylor Robin Taylor added a comment - I believe this has been merged https://github.com/DSpace/DSpace/pull/43 .
            Hide
            mdiggory Mark Diggory added a comment -

            Documentation has been added for Advanced Embargo here

            https://wiki.duraspace.org/display/DSDOC3x/Embargo

            Show
            mdiggory Mark Diggory added a comment - Documentation has been added for Advanced Embargo here https://wiki.duraspace.org/display/DSDOC3x/Embargo

              People

              • Assignee:
                mdiggory Mark Diggory
                Reporter:
                mdiggory Mark Diggory
                Reviewer:
                Mark Diggory
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: