Locally FAIR Data#12319
Conversation
used when dataverse.feature.add-publicobject-solr-field is not set
# Conflicts: # src/main/java/edu/harvard/iq/dataverse/search/SolrIndexServiceBean.java
pdurbin
left a comment
There was a problem hiding this comment.
Just a quick review for now about tests. I'll start diving in.
@qqmyers I requested access to this one. It's currently private. |
- native API section no longer a code block - added cross links - link to feature flag - fix bullets - adjust case for consistency
| dataverse-management | ||
| dataset-management | ||
| tabulardataingest/index | ||
| locally-fair |
There was a problem hiding this comment.
@DieuwertjeBloemen and @wshahn agree with me that Locally FAIR shouldn't be so high up and prominent in the User Guide. See https://dataverse.zulipchat.com/#narrow/channel/446770-docs/topic/where.20to.20put.20Locally.20FAIR.20docs/near/601213586
# Conflicts: # doc/sphinx-guides/source/installation/config.rst # src/main/java/edu/harvard/iq/dataverse/settings/FeatureFlags.java # tests/integration-tests.txt
|
We plan to add to the API changelog something that changed as of this PR. Here's the issue to track this: |
Hi @pdurbin |
|
@yesilms good to hear! I don't have any guesses please do try the feature and create new issues if you find any problems! Also, here's a related umbrella issue: |
Will do. We already deployed in our test environment and will run a PoC on the Locally FAIR instance. |
|
FWIW: As far as we know, Locally FAIR is production-ready in that it has no known issues and should work as advertised. Aside from the fact that the code is new and therefore could have bugs we didn't catch in testing, the key point about experimental, as pointed out in https://guides.dataverse.org/en/latest/user/dataverse-management.html#why-is-locally-fair-support-experimental, is that admins need to be trained not to do things that would expose data. That blurb also points out that there are various ways, e.g. from bulk metrics, that some Locally FAIR content exists (storage is being used, downloads are happening) that may make the current functionality unsuitable for some use cases. FWIW: I think there is support for fixing any bugs that might be found and we may also try (TBD) to add more automated checking to make sure the other settings on a Locally FAIR collection are consistent/won't expose the Locally FAIR content. |
What this PR does / why we need it: Implements the functionality described in "Locally FAIR" Data: Restricting Data Visibility in Dataverse Installations, allowing the visibility and accessibility of published collections and their published datasets/datafiles to be limited to specific groups.
Which issue(s) this PR closes:
Special notes for your reviewer: https://docs.google.com/document/d/1PPmPsAX8sbQYYdrU5s0Xc2d9YXw_5ROwkKaajT194P4/edit?usp=sharing and https://docs.google.com/document/d/1KBqRIkhRdJWCSs6wIRrnreJNLqWJoISIlqOZmDSTI9Q/edit?usp=sharing are additional resources.
Suggestions on how to test this: There are IT tests. For the UI, a superuser can add a user/group from the Collection/General Info pane and, once that's done, only the selected users should see new content in the collection. Reindexing would make existing published items disappear from search for unauthenticated users.
Does this PR introduce a user interface change? If mockups are available, please link/include them here: See "Locally FAIR" Data, slide 6
Is there a release notes update needed for this change?: inc.
Additional documentation:
Entry point for docs: https://dataverse-guide--12319.org.readthedocs.build/en/12319/user/dataverse-management.html#locally-fair