IQSS
request access: when a user requests access to a file and is rejected, that action is saved and should be available via API
At this time, rejected users are not saved in any way on the file level permissions page:
- This removes and doesn't allow the dataset owner to track their actual numbers of data requests on their restricted file/dataset
- This doesn't provide the user with a list of previous requests they can track and keep a record of rejected users
- This has been requested in support tickets into Harvard Dataverse repeatedly.
@TaniaSchlatter I created this ticket for the request access-rejected user scenario
FWIW: The database is tracking granted and rejected requests these days, but there's no UI/API way to retrieve them yet. It would be relatively easy to add a parameter to the https://guides.dataverse.org/en/latest/api/dataaccess.html#list-file-access-requests call, e.g. ?includeHistory=true (mirroring the flag name from #11268 for curationStatus) to at least make the info accessible. It should also be possible to add the info to the current UI or SPA, but some guidance would be needed as to where to display it (showing the history for all files in the dataset page (permissions tab) could be a long list, could show it only on the file page? or?).
Right, as discussed in Slack as of the following PR there are three possible RequestState values that can be saved in the database: CREATED, GRANTED, REJECTED.
- #9599
Yes, it would be great to expose this via API.
I don't think this requires a db change. It would require API/UI level work.
Ah, I hadn't realized we were now storing rejected. So yes, if that's the case, no DB change; still needs UI design (especially to handle when large number of rejects exist).
2025-04-09 Next steps for whomever picks up issue
- Confirm APIs don't exist
- Implement support in the API
- Open an SPA issue for the UI part (design and implementation) Sizing at 30 initially
Based on @cmbz's comment above I retitled this issue.
Also, @DieuwertjeBloemen just opened the following related issue, after a discussion at https://dataverse.zulipchat.com/#narrow/channel/378866-troubleshooting/topic/file.20access.20requests.20in.20a.20collection
- #11746
Looking for UI comments: ( I still need to consider pagination )
Original without showing history
New showing history
- Open an SPA issue for the UI part (design and implementation)
I'm confused. I thought the plan was to work on the UI in the SPA rather than JSF, per above.
I was going off Jim's comment "It should also be possible to add the info to the current UI or SPA". If that's not relevant then I can remove it
@pdurbin I'm not sure what the frown face emoji indicates. Should I remove the JSF change or leave it in?
@stevenwinship ha! In Firefox, at least, text pops up that says "confused", not "frown". 😄
Thanks for discussing at standup today. I'm not sure if we all reached a consensus or not. 🤷
Created SPA Issue https://github.com/IQSS/dataverse-frontend/issues/895
Now that we can see the history of requests I noticed something that may or may not make sense.
A user requests access to a file and that access is granted. The history shows the state of the request as being granted. When the access is then removed the request still shows a state of granted. Should the request be updated to show rejected? It makes sense that the access being removed doesn't have anything to do with the request but it seems odd when viewing both in the UI and having them contradict each other.
Hmm, should it show both? Accepted as of a timestamp and rejected as of another timestamp? 🤔
Removing access is not in the fileaccessrequests table since it's not a request. It's removing the file_downloader role. the method (removeRoleAssignments()) doesn't check for existing requests like the grantAccessToRequests() does
I don't think revoking access later represents rejecting the request. There is a separate history for roleaccess that should show when access was assigned and removed.