@eaquigley @mheppler
FYI HBS complained about this again today, because they have the contact person and email listed in the "Terms" of use, but "request access" is of course not functioning as described above. There is no good or acceptable work around at the moment. I'm going to add to my github review list to prioritize. Any reason we shouldn't? How long would this take to develop? I see no milestone has been added at all but this was part of original FRD?
feedback appreciated.

tagged as related to #2641 and as related to #2572, #2639 (for github issues review)

Removing from 4.5. Will be re-prioritized for a future release.

Heads up to @sbarbosadataverse and anyone else following this issue that I'm closing it in favor of #3997.

Here is the mockup to the Request Access popup, with Terms of Access displayed.

I don't think that we want to include the guestbook in the popup. At least in the context of this issue. There should be another issue where the user can be required to fill out a questionnaire when requesting access to a file. If we want to include the questionnaire for request access on this ticket, then it's way more than a "3".

Hi folks, we have worked on this for our own purposes here at Aust. Data Archive, that has done some of the work described here - @mdmADA developed the code for this. We are planning to show what we have done at an upcoming community meeting soon - per discussions with @djbrooke and @scolapasta

Good morning @stevenmce !

@sekmiller - this will show terms only for now.

Here is a mocked up screenshot of what the missing Request Access w/ Terms of Access popup should look like. The datasets used to create this mockup were set up on dvn-build.

I have dug into the issue of the request access button not refreshing, but have not found a solution.

I am pretty sure the issue is not (solely?) in the primefaces mark-up (tho using update="@all" like we are in file-request-access-popup-fragment.xhtml line 46 may do nothing). Switching that to @form still did not update, and looking at the ajax it seems what is being returned is well-formed and includes the ui element in question.

I then suspected there may have been a problem with the command being used by the popup logic, so in a branch I set the popup to use the FileDownloadHelper, same as the "non-popup" access request. This did not solve the problem tho, and the popup continued to act in the same way.

I am unsure where to look next. Maybe the issue is with the File object that is passed back by datafileService.find(Long id)? It comes back with many of its attributes of type IndirectList. The File object that is updated by FileDownloadHelper for the non-popup request access does not have its attributes of that type. When I tested using FileDownloadHelper with the popup, the attributes were still IndirectList because datafileService.find(Long id) was used to pass the file being requested to the popup.

I do not understand our code + JPA well enough to know if this is ok and if the updated info for file is being persisted so that the UI can update. There is a comment in FileUploadHelper (line 193) which notes that the local file object must be updated so that the page updates.

Also worth noting that my commit for "fixing" the notifications may have made them worse.

The request access popup will appear when the dataset version has Terms of Use other than CC0 and/or Terms of Access set. The popup will display the custom Terms of Use/Access for the dataset. (There is no support for guestbook/custom questions in this ticket) On the popup the user may click "Accept" to continue with the request or "Cancel" and the Request will not happen. If the user clicks the "Request Access" button above the files list then any files that have been selected (via the checkboxes in the file list) will have a Request Access submitted for them. If none of the files have been selected, the user will get a "Hey Dummy, Select some files" popup. If the user is not logged in he/she will get a "please log in before requesting access" popup.

I have 2 observations/ questions:

1. Terms of use are presented every time a file is downloaded. I thought this used to be once per session per dataset. Did this change? Intentionally?
2. TOA appears twice when downloading the same restricted file, 1ce when requesting access, another when downloading file after being granted access. Feels like overkill and see 1.

Responses:

1. That was 3.x behavior. It has not been rebuilt for 4.x. There is probably a ticket for it in the backlog.

2. It was decided to do it like this, but I could be persuaded to change it. Note that it would take a bit of infrastructure to keep track of who had seen the TOA via request access since not all downloaders would need to request access.

The request access popup reads "Please confirm and/or complete the information needed below in order to request access to files in this dataset".

Is this a holdover from the instructions in the popup for the file download button, where I think "complete" part refers to the guestbook, if there is one? In the file request popup, there will be no guestbook, so when requesting access to a file, what will the requester have to "complete"?

Is it appropriate to include that part of the instructions on file request when there is no guestbook or should the instructions be "Please confirm the information below in order to request access to files..."?