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