Can't change/remove existing embargo at item level
After an embargo is applied, it can't be removed in any obvious way. When you go to access control in the Edit Item menu, the Access Conditions text box will show that no conditions (i.e., embargos or restrictions) are applied. So I tried going to Process under the Management sidebar on the left. A new process had appeared matching a screen that I saw after applying the embargo. I deleted the process. The files are still embargoed for this item: http://hdl.handle.net/10919/116013
Link issues together to show that they're related. Learn more.
Activity
- Philip Young added Priority label
added Priority label
- Owner
Thank you for reporting this, @cecross1 .
This is definitely not obvious, but one way:
- Edit item
- Access control tab
- Click bitstream switch box
- Leave access condition blank
- Press the execute button
I was able to successfully remove the embargoes from the bitstreams for the item at https://vtechworks-dev-ds7.cloud.lib.vt.edu/handle/10919/116013 with that approach.
Another potential approach that I didn't test because I already removed the embargo.
- Edit item
- Bitstreams tab
- Click the edit (pencil writing on notepad) icon corresponding to the file whose embargo you want to edit
- Near the bottom of the page, click "Edit bitstream's policies"
- Remove Embargo here. Normally that means removing start dates and end dates from the Anonymous read policy, I believe
- Owner
@cecross1 if you have time, try these on another item and let me know if they work for you.
- Author Developer
@vtkeithg Thanks, Keith! The first option worked. For some reason, the second one didn't. This is the item I've been testing: http://hdl.handle.net/10919/116014. When I double-checked the bitstream's policy, it shows that the embargo has been removed (see screenshot below). But if you click on the file when logged out, you'll still be taken to the request form.
Edit: Added correct screenshot.
Edited by Carrie Cross - Owner
@cecross1, It looks like the entire READ policy was removed from the bitstream for Anonymous users, which would cause the problem you're seeing.
DSpace is a bit surprising at times in how it handles authorizations. In order for anyone to be able to access a bitstream (except maybe administrators?), there has to be a READ policy on the bitstream for that user, or for a group that the user belongs to...
There's a group called Anonymous, and that group includes anyone who isn't logged in. So, for most purposes, in order for most people to see a bitstream without the request-a-copy form, there needs to be a READ policy on the bitstream for the Anonymous group. Most of our bitstream embargoes are enforced by putting a start date to that Anonymous READ policy. In that start date, we put the date that the embargo ends. So the Anonymous READ policy doesn't start to take effect until the embargo ends.
To remove an embargo from a bitstream, my understanding is that only the dates should be removed from the policy. The READ policy should remain in place, and not be deleted, but the dates should be removed.
I've added the Anonymous READ policy back to the bitstream in the item you've mentioned, without the dates, and now there's no request a copy form, or lock icon on the download line.
(You still won't be able to download the file in this instance, because it doesn't exist in our dev assetstore, but otherwise it works).
Let me know if this makes sense, and if you're able to successfully end an embargo on a different item by removing just the dates from the Anonymous READ policy for the bitstream, but not deleting the entire policy.
- Author Developer
@vtkeithg Thanks! I was able to end the embargo by removing the dates as you explained above. I guess things look just different enough that I got disoriented. I will add these steps to the wiki.
- Owner
Thanks, Carrie. It's confusing enough that there have been a lot of discussions in the past about changing the way authorizations work.
- Owner
Closing issue as resolved. @cecross1 if you feel that there's more that needs to be done here, feel free to reopen the issue.
- Keith Gilbertson closed
closed
- Carrie Cross reopened
reopened
- Author Developer
This issue showed up again with the following item: https://hdl.handle.net/10919/113214. First, I tried the following process:
- Click Edit item
- Choose Access control tab
- Click bitstream switch box
- Leave access condition blank
- Press the execute button
I tested it by logging out, and the embargo stayed in place. So I logged back in and tried the other process @vtkeithg outlined:
- Click Edit item
- Choose Bitstreams tab
- Click the edit icon corresponding to the original pdf.
- Near the bottom of the page, click "Edit bitstream's policies".
- Remove start date from embargo. The save button was grayed out. Maybe that's why it didn't work?
- Developer
@cecross1 I was able to remove the embargo using the following process:
- Click the edit icon/pencil in the upper right
- Go to Status
- Go to Authorizations
- For the ORIGINAL bundle, you have to click on the box "Show bitstream policies..."
- Now that you can see the date, click the edit icon/pencil
- Remove the start date, and just above, in the empty but required field "Select policy type", select TYPE_INHERITED.
- Click Save at the bottom right.
- Repeat for the TEXT and THUMBNAIL bundles.
- Author Developer
Thanks @pyoung1! I tried it on this dissertation (the author granted permission for release) and it worked.
- Philip Young closed
closed