8671 license sorting

[ErykKul]

What this PR does / why we need it:
Right now licenses are sorted only by the ID and this order cannot be changed. With this pull request, admins can sort the licenses with the API calls, where the ordering by ID remains default until changed by manually sorting (order by sortOrder, id). SortOrder is a new column in license that becomes also visible in JSON representation of the license.

Which issue(s) this PR closes:

• Closes Multiple license sorting is inconsistent #8554
• Closes Sorting of licences by admins #8671

[coveralls]

Coverage decreased (-0.008%) to 19.974% when pulling bb1865c on ErykKul:8671_license_sorting into f83e508 on IQSS:develop.

[sekmiller]

Looks good generally, but we should probably update the doc and example files to reflect that the add license api requires a sort order

[ErykKul]

I have updated the documentation and the examples. However, I have also corrected the pre-installed licenses list in documentation by removing CC BY as V5.9.0.1__7440-configurable-license-list.sql does not insert it and I could not find any other place where this could happen. I am not sure about this.

[pdurbin]

@ErykKul hi! The CC BY license is added in scripts/api/setup-all.sh. Please see this PR:

• add CC BY, improve license config docs #8347 #8423

Some more thoughts on what the source of truth should be for licenses (JSON used in setup scripts vs. Flyway scripts): #8407 (comment)

[ErykKul]

@pdurbin I have reverted the removal of the CC BY references in the documentation.

[pdurbin]

I know this PR is already in QA but I looked anyway and wanted to note a couple things.

• I'm seeing "Sort order field is mandatory." This should probably be emphasized in the release note snippet. It can be put under a ##Backward Incompatibilities heading. @ErykKul do you want to do this?
• I'm off campus so I can't see why the Jenkins tests failed. If someone could check why, that would be great.

[qqmyers]

looks like the LicensesIT test is failing due to lack of that sort order value: {\"status\":\"ERROR\",\"message\":\"There should be a sort order value in the request body\"}\n[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.886 s <<< FAILURE! - in edu.harvard.iq.dataverse.api.LicensesIT\n[ERROR] edu.harvard.iq.dataverse.api.LicensesIT.testLicenses

[ErykKul]

There was a problem with my flyway script. I have fixed it and got the integration test to run and pass.

[kcondon]

This works, waiting for integration tests to run before merging.

[ErykKul]

OK. I will try to fix the jenkins build (I cannot see the output, I assume it fails because of the not null column without default value) by dropping the column first and then reverting the drop.

[ErykKul]

@kcondon I still had a problem with preparation script as the column generated by eclipse-link was not the same as the one added by the flyway script (making this column nullable was the most difficult thing that I did in the dataverse context up until now, but it was worth it: I have learned a lot). Now both scripts; preparation and test, run without problems. Can you see why the jenkins build fails? I cannot see the output of that. The output of the integration test that I get locally looks OK to me:

[INFO] Results:
[INFO] 
[WARNING] Tests run: 185, Failures: 0, Errors: 0, Skipped: 8
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  19:48 min
[INFO] Finished at: 2022-11-16T15:44:53+01:00
[INFO] ------------------------------------------------------------------------

[kcondon]

Hi @ErykKul The jenkins build fails due to a component in the test pipeline infrastructure and not due to an integration test. Essentially, the image used for the test box has been updated and we are waiting for the corresponding ansible lib to be able to host the tests. The team is looking at it now. Thanks for the efforts and apologies for the delay.

[qqmyers]

The build issue is related to gdcc/dataverse-ansible#263 and is not about a failing test. Once that issue is fixed (Don is working now), rerunning the build job should be enough to get the build to show green. So as far as I can tell, nothing for @ErykKul to do now (except wait a bit).

[ErykKul]

OK, thanks!

[qqmyers]

@ErykKul FYI - tests have run and there's a new failure:

java.lang.AssertionError: 
Expected status code <204> doesn't match actual status code <400>.
	at edu.harvard.iq.dataverse.api.SwordIT.testDeleteFiles(SwordIT.java:863)