JCU/fix(access-status): report a file's embargo to privileged users too - #1394
Merged
milanmajchrak merged 1 commit intoAug 7, 2026
Merged
Conversation
access.status.for-user.bitstream = current computes a bitstream's access status for the current user, so anyone who can read the file - administrators, editors, anyone the policy lets in early - is told the file is open.access. The Item View then shows them no embargo label at all, which is backwards: the people curating the repository are the ones who need to know an embargo exists and when it ends. Switch it to anonymous, which is what access.status.for-user.item already uses and what XOAI always uses. The label becomes a statement about the file rather than about the viewer's own permissions; access itself is unchanged, this only affects the reported status. Pairs with dspace-angular#1439, which turns the label on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the default DSpace access-status configuration so bitstream access status is calculated as anonymous rather than current, ensuring embargo details (including end date) are reported consistently to privileged users as well as anonymous users.
Changes:
- Change
access.status.for-user.bitstreamdefault fromcurrenttoanonymousindspace.cfg. - Align bitstream access-status calculation behavior with the existing item-level default and the documented behavior around embargo visibility.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to dataquest-dev/dspace-angular#1439, which turns the embargo label on in the Item View.
With that alone, an administrator sees no label — which is backwards, since the people curating
the repository are the ones who need to know an embargo exists and when it ends.
Why
dspace.cfgships two settings that decide whose permissions the access status describes:currentcomputes a bitstream's status for the current user (AccessStatusServiceImpl→getAccessStatusFromBitstream(context, bitstream, forever_date, bitstreamCalculationType)), soanyone who can read the file — administrators, editors, anyone a policy lets in early — is told
open.access. The frontend renders the label only when anembargoDatecomes back, so they getnothing.
Note the asymmetry: the item-level setting one line above is already
anonymous, and XOAI alwayscalculates the status anonymously regardless of either setting.
currentwas the odd one out.Verified
Local Docker DSpace 9.3 with the JCU configuration. Bitstream with an anonymous READ policy starting
2030-01-01:current(before)embargo/2030-01-01open.access/nullanonymous(after)embargo/2030-01-01embargo/2030-01-01In the UI, with dataquest-dev/dspace-angular#1439 applied, the Item View then shows
Embargo until 2030-01-01next to the file when logged in asadmin@jcu.cz, where before it showedthe plain filename.
Scope
This changes what is reported, not who can read what. Authorisation is untouched — the
administrator could always download the file and still can; they are now simply told it is under
embargo. The one trade-off: a logged-in user who was granted early access sees
Embargo until …ona file they can open. The file still opens.
🤖 Generated with Claude Code