Make validation and publication options usable without the metadata approval workflow

[josegar74]

Three options in Administration → Settings have been moved into more suitable groups so it's clear they can be used at any time:

Option	Was grouped under	Now grouped under
Force validation on metadata save	Metadata workflow	Metadata save (new group)
Allow publication of invalid metadata	Metadata workflow	Metadata publication
Automatic unpublication of invalid metadata	Metadata workflow	Metadata publication

Until now these three options lived under the "Metadata workflow" group. Because of that, people naturally assumed they only had an effect when the metadata approval workflow was switched on. In reality they apply whether or not the workflow is being used — for example, you can force a validation check every time a record is saved even if you don't use the approval process at all.

Grouping them under "Metadata save" and "Metadata publication" instead removes that confusion and makes it obvious the options are always available.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[GeoSander]

Looks good to me. Good decision I think to reorganize these settings.

[josegar74]

@cmangeat , @sebr72 this test fails:

core-geonetwork/schemas/iso19115-3.2018/src/test/java/org/fao/geonet/schema/BuildEditorFormTest.java

Lines 73 to 85 in a45dcfc

	@Test
	public void rawUpperRhineCastlesEdit() throws Exception {
	Path xslFile = getResource("gn-site/xslt/ui-metadata/edit/edit.xsl");
	Path xmlFile = getResource("raw-UpperRhineCastles-inflated-for-edition.xml");
	Element inflatedMd = Xml.loadFile(xmlFile);
	Element editorForm = Xml.transform(inflatedMd, xslFile);
	XMLOutputter xmlOutputter = new XMLOutputter(Format.getPrettyFormat().setLineSeparator("\n"));
	String actual = xmlOutputter.outputString(editorForm);
	TestSupport.assertGeneratedDataByteMatchExpected("raw-UpperRhineCastles-editor-form.xml", actual, GENERATE_EXPECTED_FILE);
	}

Even updating raw-UpperRhineCastles-editor-form.xml with the new value (variable actual) it still fails. Which is bizarre, and makes me wonder if the XML produces different output in each execution?

Locally, after updating the file with the actual variable value:

array lengths differed, expected.length=339874 actual.length=331659; arrays first differed at element [65513]; 
Expected :32
Actual   :34

It's not the first PR having problems with this test. Also I can not see any value for these editor tests. I agree unit testing is very important, but this low level XML editor stuff that is not easy to update, it seems more problematic than useful.

Can you please describe how to update the files properly so tests can pass after changes applied for settings in this case, which is quite unrelated.

[cmangeat]

@cmangeat , @sebr72 this test fails:

core-geonetwork/schemas/iso19115-3.2018/src/test/java/org/fao/geonet/schema/BuildEditorFormTest.java

Lines 73 to 85 in a45dcfc

	@Test
	public void rawUpperRhineCastlesEdit() throws Exception {
	Path xslFile = getResource("gn-site/xslt/ui-metadata/edit/edit.xsl");
	Path xmlFile = getResource("raw-UpperRhineCastles-inflated-for-edition.xml");
	Element inflatedMd = Xml.loadFile(xmlFile);
	Element editorForm = Xml.transform(inflatedMd, xslFile);
	XMLOutputter xmlOutputter = new XMLOutputter(Format.getPrettyFormat().setLineSeparator("\n"));
	String actual = xmlOutputter.outputString(editorForm);
	TestSupport.assertGeneratedDataByteMatchExpected("raw-UpperRhineCastles-editor-form.xml", actual, GENERATE_EXPECTED_FILE);
	}

Even updating raw-UpperRhineCastles-editor-form.xml with the new value (variable actual) it still fails. Which is bizarre, and makes me wonder if the XML produces different output in each execution?

Locally, after updating the file with the actual variable value:

array lengths differed, expected.length=339874 actual.length=331659; arrays first differed at element [65513]; 
Expected :32
Actual   :34

It's not the first PR having problems with this test. Also I can not see any value for these editor tests. I agree unit testing is very important, but this low level XML editor stuff that is not easy to update, it seems more problematic than useful.

Can you please describe how to update the files properly so tests can pass after changes applied for settings in this case, which is quite unrelated.

Hello. First approach could be setting this boolean to true;

core-geonetwork/schemas/iso19115-3.2018/src/test/java/org/fao/geonet/schema/BuildEditorFormTest.java

Line 47 in a45dcfc

private static final boolean GENERATE_EXPECTED_FILE = false;

and run the tests locally, so to read the updates with git diff for example (setting the boolean to true will produce the expected control files).

"quite unrelated" is the point.

[josegar74]

@cmangeat thanks for the feedback, I'll try that and let you know

[josegar74]

@cmangeat thank you. I have tried the option you pointed and it seems to work.