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
Refactoring authority framework, value pairs and controlled vocabulary #2792
Conversation
the visualization is now responsability of the angular UI so it is better by default present a clean label as the hierarchy is still visible in the otherInformation
This pull request fixes 2 alerts when merging e06832fd38fa2e4ee15985300d30d0b7a7f7ecb4 into 6b3bd4d - view on LGTM.com fixed alerts:
|
e06832f
to
769dd06
Compare
This pull request fixes 2 alerts when merging 769dd06 into 6b3bd4d - view on LGTM.com fixed alerts:
|
This pull request fixes 2 alerts when merging b232def into 6b3bd4d - view on LGTM.com fixed alerts:
|
@tdonohue @benbosman all your previous feedback have been addressed as far as I can check. To simply the review I have explicitly linked the "solution" under each not yet resolved comment. About the ORCID test mentioned here #2792 (comment) it cannot be performed because the ORCID integration with the authority framework was dropped sometimes ago but it should be restored (I have created #2891 for that) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Thanks @abollini ! I've re-reviewed the code, and all previous requests (by both @benbosman and I) seem to be addressed. I've also manually tested the endpoints and they respond as documented in the contract per DSpace/RestContract#128
That said, I'm noticing that I cannot merge this PR until the Angular PR (DSpace/dspace-angular#751) is also ready to merged. Unfortunately, without the corresponding Angular PR, the current main
submission form is unusable (I get an Error: Authority name is not available. Please check the form configuration file.
). That said, I think this PR is ready to go as soon as the Angular PR is also ready.
private void addFormDetailsToAuthorityCacheMap(String submissionName, String authorityName, String fieldKey) { | ||
Map<String, List<String>> authorityName2definitions; | ||
if (authoritiesFormDefinitions.containsKey(authorityName)) { | ||
authorityName2definitions = authoritiesFormDefinitions.get(authorityName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This variable name sounds quite confusing. It seems to be a map from the submission name to the fields (and the authorityName is not the same as the submission name)
@@ -44,10 +50,10 @@ | |||
public class DCInputAuthority extends SelfNamedPlugin implements ChoiceAuthority { | |||
private static Logger log = org.apache.logging.log4j.LogManager.getLogger(DCInputAuthority.class); | |||
|
|||
private String values[] = null; | |||
private String labels[] = null; | |||
private Map<String, String[]> values = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add JavaDocs explaining what values and labels are now?
If values is a map, it's not clear what the keys and values of the map are (and similar for labels)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point in time, this branch should not be merged since there's no Angular UI. This also implies I currently can't test the authority control part at all (I have no solr authority core to test with).
Once the Angular UI branch is ready, I will perform another review. Please ping me at that time
I've added a few comments, which can be improved in the meanwhile as well
I noticed another problem with this branch which doesn't need to be solved, but reported:
- The Accept-Language is not handled completely yet. When using
Accept-Language: nl;q=0.8,en;q=0.7
it will return Dutch values on /server/api/submission/vocabularies/common_iso_languages/entries, but when usingAccept-Language: de;q=0.9,nl;q=0.8,en;q=0.7
it will return the English values because German is configured to be supported, but not used for the submission forms. This can perhaps be added to Multi-linguism requires submission-forms to be in sync #2827 as another use case where translations only work if everything is translated
latest feedback has been addressed. The angular part is in this PR DSpace/dspace-angular#751 that as by today dev mtg discussion will be updated today by @atarix83 to be in a testable status |
This pull request fixes 2 alerts when merging ed58d44 into fa3e714 - view on LGTM.com fixed alerts:
|
This pull request fixes 2 alerts when merging 70c861a into 2027b03 - view on LGTM.com fixed alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not retest it using the UI, but I've discussed it with Art and he hasn't seen any REST issues while testing with DSpace/dspace-angular#751
This is at +2, as it the corresponding Angular PR (DSpace/dspace-angular#751). So, I'm merging both & pushing an update to the REST API demo site. Thanks @abollini & @Micheleboychuk (and all the reviewers)! |
References
Wiki page with the preliminary discussion: https://wiki.lyrasis.org/display/DSPACE/4Science+proposal+to+improve+authority+support+in+DSpace7
Rest Contract PR DSpace/RestContract#128
Angular PR: DSpace/dspace-angular#751
Description
This PR restores the previous way of DSpace to store metadata when values are retrieved from valuepairs and controlled vocabularies (without the authority ID in the metadatavalue).
Nevertheless, value-pairs and controlled vocabularies are managed using the same infrastructure previously used for Authority Control, for these reasons we agree to rename all these features under the common name of controlled vocabularies.
Finally, this PR also fix a couple of outstanding issues that were noted on the previous implementation
https://jira.lyrasis.org/browse/DS-4350
https://jira.lyrasis.org/browse/DS-4371
https://jira.lyrasis.org/browse/DS-4408
this also replace the previous PR #2743 adding the necessary features to support the visualization of the hierarchical vocabularies
Instructions for Reviewers
ITs have been added to cover the new VocabularyEntryDetails endpoint and the refactoring related to the link repositories.
Other than reviewing the code by inspection and checking the ITs it could be useful to verify the correct exposition of the default submission definitions where the value-pairs must be exposed as common_types vocabulary. It is also possible to enalbe the srsc controlled vocabulary to verify that it meet the example in the REST Contract
Checklist
pom.xml
), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.