Require selection of enable access request or adding Terms of Access for restricted files

[djbrooke]

Overview of the Feature Request

When a file is restricted, a popup appears that allows the user to add terms for accessing the restricted files or allows enabling an access request. The popup can currently be closed without making any changes. After some discussion in the multiple license PR (#7920 (comment)), I'd like to propose that either terms of access or request access must be added. I've added the reasoning below. It makes sense to me but I'd be interested to hear from other installations.

• If request access is enabled for a file, it's OK if no terms are defined because the thinking is that the person will request access and it will allow the requestor and the depositor/curator to start a conversation (since login is required for requesting access, we can be sure we will always have the requestor's contact information). A conversation can take place outside of the Dataverse installation about the access request if needed. Another option is that the depositor/curator can just make a decision about giving access with no conversation. This provides the flexibility for both.
• If request access is not enabled for a file, the terms are required because they provide the context about why request is not enabled. For the Murray Dataverse collection, the use case is that there's a separate process outside of the Dataverse installation. Same for restricted files in IFPRI collection. Generally, we don't want to just provide a wall for access with no information about why the access is not possible - the terms allow us to provide context or provide the option(s) for accessing the data.

All of this being said, we need to do a better job of surfacing the terms during the data access process. Issue to follow on the presentation of terms to accessors, but I wanted to get this issue in as it's pretty neatly scoped (hopefully ;)).

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)

Curator, Depositor, Superuser

What inspired the request?

Discussion in the multiple license PR, linked above. This is related but not within the scope of the license work.

What existing behavior do you want changed?

See above, but the general idea is that our current behavior provides the opportunity to upload data with no real way to get at it, and we're all about data sharing! :)

Any brand new behavior do you want to add to Dataverse?

See above, some extra validation!

Any related open or closed issues to this feature request?

#7691 is related. It covers this and also dips in the license requirement.

[djbrooke]

• For existing files in this state, we wouldn't make any changes, but if someone tries to make an update they would presented with the new validation.
• When a user tries to restrict a file, they get the popup with the access request / TOA populated based on previous selection (the same validation would be in place for both)
• To discuss - do we want a default state of request access enabled? The alternative would be that we need to write some default text for Terms of Access (@djbrooke - let's have a default state of access request enabled)
• We'd want to not create restricted files in the undesirable state via API (see above)
• Implementation detail - this would need to Ajax enabled - you can't wait until save here.

[djbrooke]

Thanks @TaniaSchlatter @sekmiller @scolapasta for discussing. The entry point from the terms tab is a bit challenging, since we display restricted file-related options to people who may not have restricted files, and introducing the validation into the workflow could add some confusion. Adding the validation when the entry point is at the file level is easier to implement because we are dealing with someone who is actively restricting a file. Some follow ups:

• Tania will investigate changes to the terms page, whether by making better use of the accordion for Terms of Access/Restricted files, graying out options, not implementing validation on the terms page when restricted files are not present, or some combination thereof.
• Stephen will investigate the case of public installations - in these installations we do not display the restrict options.
• After we get the changes to the terms page in a good place, we can review text on the terms page and the restrict file popup to reflect the new validation workflow

[TaniaSchlatter]

This needs the equivalent of "needs discussion." Any next steps need to be considered in the context of the multiple license work from DANS that's in the 5.10 release.

[sekmiller]

For our discussion, there is no real interaction with multiple licenses. The validation rests solely on the presence of restricted files and request access or terms of access settings. If there are restricted files then the dataset must allow access requests or have terms of access provided. For new datasets we are setting request access to true and when a dataset owner restricts a file they will be presented a popup with request access checked. If they uncheck “request access” they must provide terms of access in order to restrict the file. That is, if they press “cancel” on the popup the file will not be restricted. Likewise on the edit terms page, if there are restricted files present, the save button for Edit Terms is inactive while “request access” is unchecked and terms of access are blank. If request access is checked or terms of access are provided then the save button is activated.

For existing datasets that have restricted files but are not in compliance with the new requirement we haven’t done anything to bring them into compliance. What has been done so far is to give the owner of the dataset a banner at the top of the dataset which informs them that the dataset is out of compliance with the new requirement and includes a link that opens the Edit Terms page with the “request access” set to true. If they simply press save here that would bring the dataset into compliance. It would also, for published datasets create a new draft version which would have to be published. If they uncheck the request access they would have to enter terms of access in order to re-activate the save button. Also for datasets in draft that are not in compliance publishing is disabled along with most edit functions - except edit terms.

[TaniaSchlatter]

Thanks @sekmiller. I've revised mockups based on 5.10. I also did a little research on accessibility and disabling buttons. We can review.

[TaniaSchlatter]

There has not been any feedback from the community about issues requiring Terms of Access or Request Access, so I think we are clear from that perspective.

[amberleahey]

Hi all, we are just noticing that this introduction of logic for requiring the Request Access when Data Access Place is in use conflicts with our metadata-only for non-restricted datasets that are housed in another database (from our legacy database called ODESI, which we imported using the DDI APIs which seems to ignore some of Dataverse's requirements). Typically, Data Access Place in DDI doesn't have any dependencies on restricted access, so Dataverse's assumptions that the data are always restricted and require Request Access is conflicting with our use of this DDI field. Do you have any suggestions for us? I'd advise against any logic here that restricts use of metadata fields, but I'm not as familiar with the original use case/approach to why this was needed. We get a warning now in the UI and it is not editable ...

And it would be great to make Data Access Place actionable with support for a URI field, but I will create a separate ticket for that.

[qqmyers]

FWIW: Having a Data Access Place should be fine. However, Datasets must now have either request access = true or have Terms of Access set. By default new Datasets should be created with request access = true and avoid the warning (the one known exception is if you have an old template that doesn't set it, but the DDI import could be another and should probably be it's own issue.) The 5.11 release notes include a query to find datasets that have this problem. @sekmiller would be able to confirm, but I think 5.12 then had a fix to avoid enforcing this constraint when there aren't any restricted files to apply it to. The work-around before then is to either temporarily restrict a file to turn these fields on in the UI so you can check enable access request, after which you can unrestrict the file, or to edit in the db.

[amberleahey]

thanks @qqmyers yes, perhaps we need to look at the DDI import API yes, this is a bit out of date now, and thanks for clarifying we can get this in if Terms of Access are set, would it be set to 'custom'?

[qqmyers]

re: would it be set to 'custom'?
Not sure I get what you mean. As a guess -putting text in the 'Terms of Access for Restricted Files' or setting the allow access request = true would not affect the license /make the dataset have a custom license. If you're just asking about what text to use - I'd suggest flipping allow access requests to true instead of adding text. If you want text instead, I'd suggest maybe 'N/A' instead - the reason it is grayed for you is that there are no restricted files to be affected, so whatever you don't won't apply to anything (which is why it is hidden/not checked when there are no restricted files once you have v.512).

[amberleahey]

Ok thanks for clarifying @qqmyers , I was confused about the 'custom terms' versus the Terms of Access and Request Access = true. I understand now. We tested this and the Request Access is checked automatically when you add custom terms to the Dataset Terms in the current UI. What we don't understand is why this is needing to be checked for Datasets that have only files that are open access. We did test loading files but not enabling request access at the file level, and this doesn't appear to affect or override end-users access to the open files. The DDI Import API will need some thinking about how to fix this issue to not get the warning, but we will figure out another way to add this in our workflow (likely just updating the JSON to set the Request Access = true). @lubitchv knows more! :)

[amberleahey]

and we will try 5.12 release - thanks for that tip @qqmyers