Setting for public only installations, new API endpoint for restricting files

[scolapasta]

As we work with groups like SBGrid and MOC, we've designed these workflows where all files need to be public (i.e. restricting a file on the dataverse side isn't useful, since the files are available publicly outside the system). So we need to have a setting to make the dataverse installation public only. If this setting is set, then we would not render UIs that allow users to restrict files and would have those commands throw unsupported exceptions.

[mheppler]

UI impact (reference doc):

• Dataset
  • Restricted lock icons (will not be applying render logic, because we don't need to turn off something that can't be turned on)
  • Request Access button (ditto)
  • Edit button > Permissions, conditional render for "Files"
  • Edit Files button > Restrict/Unrestrict options
  • Terms tab > Restricted Files + Terms of Access panel, conditional render for "Terms of Access" header text
  • Terms tab > Restricted Files + Terms of Access panel > Restricted Files, hide label and text
• Edit/Create Dataset
  • Create Dataset > Warning msg... "File Access - Files are stored on a publicly accessible storage server."
• Edit Dataset Terms
  • Terms tab > Restricted Files + Terms of Access panel, conditional render for "Terms of Access" header text
  • Request Access, hide option + label
• Upload Files (both create/upload workflows)
  • Restricted lock icons
  • Restrict button
  • Edit/Upload Files > Warning msg... "File Access - Files are stored on a publicly accessible storage server."
• Edit Files
  • Restricted lock icons
  • Restrict button, hide
  • Edit/Upload Files > Warning msg... "File Access - Files are stored on a publicly accessible storage server."
• Manage File Permissions
  • Page link removed from dataset pg
• Files
  • Restricted lock icons
  • Request Access button
  • Edit button > Restrict/Unrestrict options
• Dataverse
  • Access facets, remove
  • Restricted lock icons
  • dataverseLinksStayOnPage param removed, no longer in use search-include-fragment ui:param - dataverseLinksStayOnPage == true ? #1521
• Bundle
  • Create Dataset + Edit/Upload Files > dataset.message.publicInstall > "File Access - Files are stored on a publicly accessible storage server."
• User Guide > Dataset + File Management
  • File Handling + Uploading
  • Tabular Data Files
  • File Tags
• API Guide
  • Native API
• Installation Guide
  • Configuration

[pdurbin]

@ferrys as I mentioned to you, @bsilverstein95 and @raprasad at lunch yesterday, I encourage you to consider making the correctness of the code you are writing for this issue testable in an automated fashion via API tests. One challenge will be that currently the ability to restrict files is a GUI-only feature. Note that just yesterday @mdmADA asked in #3873 if we could add the ability to restrict files via API (a duplicate of #2497) and related to #3440. I gave @bsilverstein95 #3431 about getting set up to write API tests using REST Assured so you may want to check in with him and take a look at the API tests I asked him to write last summer in pull request #3299 (in ConfirmEmailIt.java).

[dlmurphy]

For #3747 I added this warning to the Dataset Management page of the User Guide and the Config page of the Installation Guide:

Note: At present, any file restrictions that users apply in Dataverse will not be supported in Swift. This means: if you set a file on Dataverse as "restricted", a user without proper permissions could bypass that restriction by accessing the file through Swift. For now, do not rely on file restrictions to limit access to data in a cloud-enabled Dataverse.

This warning will need to be edited or removed to reflect that fact that public-only installations are now an option.

[pdurbin]

Interesting. I didn't know you added that, @dlmurphy . Looks good. Thanks.

[dlmurphy]

Also, are we concerned that public-only installations will still connect with the same set of guides that still explicitly refer to and explain the file restriction feature? Is it possible to connect public-only installations with an alternate set of guides without those sections?

Edit: A low-impact (but potentially slightly confusing) solution might be to add a note in those sections mentioning that the feature is disabled in public-only installations.

[pdurbin]

@dlmurphy I say no to alternate guides. The guides should be a description of what's possible with the product (Dataverse) and it should mention, where appropriate, how configuration options affect the behavior that users will see. You've already done this by mentioning how Swift being turned on interacts with file permissions and we should continue in this vein.

[ferrys]

I was chatting with @mheppler and @TaniaSchlatter about adding an initial message for contributors to a Cloud Dataverse which informs them that they are using a public install (since it would not be obvious), so they know their data will be public. If we choose to implement this, we could also mention the file restriction features there.

[dlmurphy]

@pdurbin, that's a good point. I agree, let's not have alternate guides. I'll go through the guides and make any edits needed to make sure that users are clear that file restrictions aren't enabled on public-only installations.

@ferrys, that initial message sounds like a great idea. I was concerned that users wouldn't know whether their install was public-only or not, so getting them oriented up front with a message like that is really helpful. Keep me posted on that message, and if you need any help writing it or proofreading, let me know!

[ferrys]

Observations from the current implementation of the code:

• Restricting a file on an existing dataset through "Upload Files" and restricting a file on an existing dataset through the "Edit Files" tab both call the UpdateDatasetCommand to update the metadata.
• Restricting a file on the File Page and restricting a file by editing the metadata through the "Edit Files" tab both call the database to update the metadata.

So, considering all things, I think I will take the time to create something similar to a RestrictFileCommand so it is both accessible through the API (#3873) and able to be tested in an automated fashion.