Skip to content

JCU/fix(access-status): report a file's embargo to privileged users too - #1394

Merged
milanmajchrak merged 1 commit into
customer/jcufrom
jcu/show-embargo-status-to-privileged-users
Aug 7, 2026
Merged

JCU/fix(access-status): report a file's embargo to privileged users too#1394
milanmajchrak merged 1 commit into
customer/jcufrom
jcu/show-embargo-status-to-privileged-users

Conversation

@Kasinhou

@Kasinhou Kasinhou commented Aug 7, 2026

Copy link
Copy Markdown

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.cfg ships two settings that decide whose permissions the access status describes:

access.status.for-user.item = anonymous
access.status.for-user.bitstream = current

current computes a bitstream's status for the current user (AccessStatusServiceImpl
getAccessStatusFromBitstream(context, bitstream, forever_date, bitstreamCalculationType)), so
anyone who can read the file — administrators, editors, anyone a policy lets in early — is told
open.access. The frontend renders the label only when an embargoDate comes back, so they get
nothing.

Note the asymmetry: the item-level setting one line above is already anonymous, and XOAI always
calculates the status anonymously regardless of either setting. current was the odd one out.

Verified

Local Docker DSpace 9.3 with the JCU configuration. Bitstream with an anonymous READ policy starting
2030-01-01:

anonymous administrator
current (before) embargo / 2030-01-01 open.access / null
anonymous (after) embargo / 2030-01-01 embargo / 2030-01-01
GET /server/api/core/bitstreams/e144905d-…/accessStatus

In the UI, with dataquest-dev/dspace-angular#1439 applied, the Item View then shows
Embargo until 2030-01-01 next to the file when logged in as admin@jcu.cz, where before it showed
the 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 … on
a file they can open. The file still opens.

🤖 Generated with Claude Code

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>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.bitstream default from current to anonymous in dspace.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.

@milanmajchrak
milanmajchrak merged commit 8007d34 into customer/jcu Aug 7, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants