GNIP 97: New metadata editor

[etj]

Complete rewriting of the metadata editor according to GNIP 97

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

For all pull requests:

• Confirm you have read the contribution guidelines
• You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
• Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

• There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
• The issue connected to the PR must have Labels and Milestone assigned
• PR for bug fixes and small new features are presented as a single commit
• Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
• PR title must be in the form "[Fixes #<issue_number>] Title of the PR"
• New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
• This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
• This PR passes the QA checks: black geonode && flake8 geonode
• Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates
• Commits adding new texts do use gettext and have updated .po / .mo files (without location infos)

Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

[etj]

Hi @gannebamm, happy new year!
Did you manage to test the new editor?

[codecov]

Codecov Report

Attention: Patch coverage is 94.61500% with 107 lines in your changes missing coverage. Please review.

Project coverage is 67.95%. Comparing base (91f32c6) to head (c07bf42).

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12794      +/-   ##
==========================================
+ Coverage   67.00%   67.95%   +0.95%     
==========================================
  Files         952      975      +23     
  Lines       56912    58883    +1971     
  Branches     6725     6886     +161     
==========================================
+ Hits        38134    40016    +1882     
- Misses      17166    17229      +63     
- Partials     1612     1638      +26     

[mattiagiupponi]

is there any reason why the serializer is no longer used?

[etj]

It is used indeed.
Please note that the code you're pointing to has changed name from base_linked_resources_payload to base_linked_resources_instances. The new base_linked_resources_payload calls base_linked_resources_instances (now also used elsewere for DRY), and still uses the serializer, returning the same content as before.

[mattiagiupponi]

From my undestanding, the inspire app is not totally required, is more a documentation app. If is not used, i would propose to switch it as documentation or if is needed for testing purpose only, i would document this and move the app in the tests.
Is open to discussion

[etj]

Pls note that I used the inspire app for an example in this very thread (#12794 (comment)). It is a really good point for documentation and testing handler overriding. I know it is something not used outside Europe, but I guess we need some real override implementation inside geonode.

[mattiagiupponi]

Should this be PUT si is the method used in the function?

[ridoo]

I am not sure to be ready to do a helpful review from my position. However, I was wondering why the schema will include geonode specific properties like geonode:required or geonode:handler. The handler will know the schema parts it is responsible for, won't it? And if parts of the schema are required are also known -- on the client side the regular schema properties should indicate required properties, so for which cases geonode:required is necessary?

[etj]

Hi @ridoo

geonode:handler

The handler will know the schema parts it is responsible for, won't it?

The MetadataManager class is responsible for dispatching the field handling to the proper handler: the geonode:handler info tells which handler is to be called.
The handling override mechanism foresees that an handler may declare itself as the main handler for an existing field declared by another hander, so different handlers may work on the same field, but only the last declared one will be invoked, that is the one that lastly set himself as geonode:handler.

See this for example:

geonode/geonode/inspire/metadata.py

Lines 52 to 58 in 7e81443

	# override base schema: was a codelist, is a fixed value in the codelist
	jsonschema["properties"][FIELD_RESTRICTION_TYPE] = {
	"type": "string",
	"title": "restrictions",
	"ui:widget": "hidden",
	"geonode:handler": "inspire",
	}

geonode:required

so for which cases geonode:required is necessary?

JSON schema defines the required fields (using the annotation required) in a level above the sub schema definition.
The handlers only work on their own sub schema.
The MetadataManager uses the geonode:required custom annotations to build the upper level required array:

geonode/geonode/metadata/manager.py

Lines 78 to 85 in 7e81443

	# Set required fields.
	required = []
	for fieldname, field in schema["properties"].items():
	if field.get("geonode:required", False):
	required.append(fieldname)
	if required:
	schema["required"] = required