-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting for public only installations, new API endpoint for restricting files #3776
Comments
UI impact (reference doc):
|
@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 |
For #3747 I added this warning to the Dataset Management page of the User Guide and the Config page of the Installation Guide:
This warning will need to be edited or removed to reflect that fact that public-only installations are now an option. |
Interesting. I didn't know you added that, @dlmurphy . Looks good. Thanks. |
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. |
@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. |
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. |
@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! |
Observations from the current implementation of the code:
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. |
Edited PublicInstall section of Config doc for clarity.
…s, and file pg. Removed references to old ShowFileLandingPage setting. [ref #3776]
Let's retest #3653 when we put this issue through QA. |
@dlmurphy yes, here's the screenshot you wanted. It says, " File Access - Files are stored on a publicly accessible storage server." |
@dlmurphy also, code has been deployed to the dvn-build server if you'd like to click around the UI to see the changes. |
@ferrys can you add a test to RestrictFileCommand where publicInstall is set to true? |
I think that the "File Access" message at the top of the Create Dataset page does get the concept across fine, but I worry that it's not emphatic enough. My understanding is that ultimately this message is supposed to be a warning that keeps researchers from uploading sensitive data to a public-only installation. If this is accurate, then this message might need more of a cautionary tone. What do folks think of this messaging: |
@dlmurphy yeah, I agree that it wouldn't hurt to make the message a bit more cautionary. I'd love to hear @pameyer weigh in on this since his users are going to be reading it. We could consider making in configurable, similar to |
@dlmurphy is going to run the text change past @pameyer and then give it to @bsilverstein95 to commit. Thanks, all! |
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.
The text was updated successfully, but these errors were encountered: