Access to restricted files that were replaced is lost
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 564
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 29
Description
I couldn't find information about the expected behavior of restricted files that were replaced and published in the documentation, so at the moment this seems like a bug to me (sorry if it is intended and I missed it):
What steps does it take to reproduce the issue?
- publish a dataset with a restricted file
- replace the restricted file
- publish the draft (=> new version of the dataset)
What did you expect to happen?
For users that had access to the previous version of the file to still have access to the new version of the file. Or for a button or something similar to appear in the publication process to choose whether users should still have access to the file in the new version.
So far I understood the replace function as a way to update the same file, so that access is lost/not granted anew automatically surprised me. For new files, however, I would expect exactly that.
What happens?
Users do not have access to the new version of the file. We only found out about this after some users contacted us themselves.
To whom does it occur (all users, curators, superusers)?
All users.
Which version of Dataverse are you using?
Dataverse v. 6.5, but we do not have many datasets with restricted files, so the behavior might have been there for some time.
Any related open or closed issues to this bug report?
#9697 also deals with access to replaced files, but the focus is a different one.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file, test, or entry point is identified in the issue. Reproduce the restricted-file replacement and publication workflow described, then review related issue #9697; done means confirming whether prior access is retained or an explicit access choice is provided for the new version.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authorization, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100