Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-3266

AIP Restore is not respecting access restrictions (on Items)

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 6.0
    • Fix Version/s: 5.6, 6.0
    • Component/s: API
    • Labels:
      None
    • Attachments:
      0
    • Comments:
      3
    • Documentation Status:
      Not Required

      Description

      How to reproduce:

      1. Login as an Admin
      2. Edit an Item, change all its Access Policies to "Administrator" group (instead of the default of Anonymous)
      3. Export the Item via AIP tools, e.g. ./dspace packager -d -t AIP -e [username] -i [handle] item-aip.zip
      4. Delete the Item from DSpace
      5. Then, perform a Restore via AIP tools, e.g. ./dspace packager -r -t AIP -e [username] item-aip.zip

      The result will be that the Item is restored successfully. However, it will now be publicly readable.

      Looking more closely at the Item's Resource Policies will show that all the "Administrator" policies will still be in-tact (i.e. they were exported and re-imported successfully). However, alongside each of them will now be a policy giving "Anonymous" rights (and that second policy overrides the first one).

      My suspicion is that during the AIP restore process, Anonymous rights are initially "inherited" from the Collection. They are supposed to be removed and replaced by the resource policies from the AIP. However, that second action seems to be silently failing.

      These activities take place in the METSRightsCrosswalk's "ingest()" method. There is a step that looks like it's supposed to be removing any inherited policies, but I'm not sure it's actually working:
      https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/crosswalk/METSRightsCrosswalk.java#L457

      UPDATE: This seems to ONLY affect Items (from my testing). Access restrictions on Community/Collections seem to be restored successfully.

      UPDATE #2: This bug also seems to occur in 5.x, so it is not 6.0 specific and therefore a fix likely needs backporting.

      UPDATE #3: Additionally, this bug ONLY occurs during a restore (-r flag) of a deleted item. Performing a replace (-r -f) of an existing item successfully replaces/reverts all resource policies to those detailed in the AIP.

        Attachments

          Activity

            People

            • Assignee:
              tdonohue Tim Donohue
              Reporter:
              tdonohue Tim Donohue
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: