Role based search results filtering

[litvinovg]

What does this pull request do?

New property will allow users to define filter values that could be used to exclude sensitive or technical information not intended for public display from search results for any user roles defined in VIVO.

What's new?

Replaced search:defaultPublic data property that was used to apply search filters to public role with
search:isDefaultForRole object property to specify role the filtering should be applied to.

How should this be tested?

• Add test_data.n3.zip to home/rdf/display/firsttime/
• Build VIVO
• If not logged in only continents should appear in search results
• If looged in as admin or self editor only continents should appear in search results
• If logged in as curator, editor or root, search results should not be limited to continents.

Additional Notes:

Removed previously mistakenly committed file.
Default roles identifiers moved to VitroVocabulary

Interested parties

@VIVO-project/vivo-committers

[chenejac]

@litvinovg I am expecting that VIVO customers would like to open all objects by default, and then just add some exceptions. Can you demonstrate in your test data the scenario that everything is searchable for anonymous user (not logged in), except one type of objects (for instance countries)?

[chenejac]

Can we use here VITRO_AUTH prefix? One day we might decide to move from Cornell domain in the Vitro application ontology. The same comment is for the next 4 lines.

Suggested change

	public static final String ROLE_PUBLIC_URI = "http://vitro.mannlib.cornell.edu/ns/vitro/authorization#PUBLIC";
	public static final String ROLE_PUBLIC_URI = VITRO_AUTH + #PUBLIC";

[litvinovg]

Done

[litvinovg]

@litvinovg I am expecting that VIVO customers would like to open all objects by default, and then just add some exceptions. Can you demonstrate in your test data the scenario that everything is searchable for anonymous user (not logged in), except one type of objects (for instance countries)?

To do that one would need to:

• Create SelectQueryDocumentModifier with custom field, for example public_filter_ss, which would be populated with "public" of objects, unless condition that URI is of type country is met.
• Create search field individual with id "public_filter_ss"
• Create search filter "public filter" and set field to it.
• Create search filter value the same way it is defined in test configuration attached to the PR with id "public" and isDefaultForRole for PUBLIC role.

I suggest doing this at the stage of preparing documentation for the release.

[chenejac]

@litvinovg I am expecting that VIVO customers would like to open all objects by default, and then just add some exceptions. Can you demonstrate in your test data the scenario that everything is searchable for anonymous user (not logged in), except one type of objects (for instance countries)?

To do that one would need to:

• Create SelectQueryDocumentModifier with custom field, for example public_filter_ss, which would be populated with "public" of objects, unless condition that URI is of type country is met.
• Create search field individual with id "public_filter_ss"
• Create search filter "public filter" and set field to it.
• Create search filter value the same way it is defined in test configuration attached to the PR with id "public" and isDefaultForRole for PUBLIC role.

I suggest doing this at the stage of preparing documentation for the release.

I suppose it should be part of this wiki pages - https://wiki.lyrasis.org/display/VIVODOC115x/Authorization. Let's define this scenario in the wiki documentation.

[chenejac]

@litvinovg thanks. Works for me. We need one more review.

[wwtamu]

https://github.com/litvinovg/Vitro/blob/c0b48511e2b7b4446b90a4096ed19de3bae6d7bd/api/src/main/java/edu/cornell/mannlib/vedit/beans/LoginStatusBean.java#L21C1-L21C31

Shouldn't an immutable object be a final class?

Can't the class be extended on the classpath to mutate the static reference to the stack of the DUMMY_BEAN?

This is a spaghetti bowl of session management with the dyadic method containing the non-injected bean of unknown origin.

[litvinovg]

I don't know. Let's create an issue and discuss it there.
I think it is out of scope for this PR.

[wwtamu]

Yeah, it is out of scope to some degree. Also, the origins of the beans can be traced back to instantiation. Just not sure of the runtime bytecode modifications between RDF interpolation of Java classes and casting between non concrete classes.