Metadata editor / Online resources / Keep the panel configuration when editing a resource

[juanluisrp]

Two problems in the online resources dialog, both found while testing #9461 on a local catalogue. The second one loses data.

Configured field defaults are lost when the dialog is reopened

The defaults declared in the associated resources panel configuration (fields.*.value, copyLabel) were only applied from the params.linkType watcher, which is guarded by newValue !== oldValue. openDialog resets protocol, name and description for every new resource, but the watcher does not run again when the selected link type has not changed, so the defaults are never restored.

Reproducible on current main with an iso19139 record, where protocol is both required and configured with a default:

Action	protocol field
Open "Add online resource"	WWW:LINK-1.0-http--link
Close it, open it again	empty

The defaults are now applied when the dialog opens as well, so they no longer depend on the link type reference changing.

Editing a resource discards the schema configuration, dropping fields from the record

getTypeConfig matches the resource being edited against the configured types by comparing each type's fields.protocol.value with the resource protocol. In the iso19139 configuration that value is a default for new links, not a discriminator, so editing a resource with any other protocol matches no type and falls back to the hardcoded DEFAULT_CONFIG.

That is not cosmetic. processParams is built from the fields the active configuration declares, and onlinesrc-add rebuilds the online resource from the parameters it receives. Any field the active configuration does not declare is therefore dropped from the record.

DEFAULT_CONFIG does not declare applicationProfile. On current main, editing a resource that has one and changing only its description:

submitted: url=...&protocol=WWW:DOWNLOAD-1.0-http--download&mimeType=&mimeTypeStrategy=mimeType
           &name=APTEST-ORIGINAL&desc=touched-description-only&function=download&...

applicationProfile is absent from the request even though the dialog loaded it correctly as inspire-download, and <gmd:applicationProfile> is gone from the stored record afterwards.

This flags the generic addOnlinesrc type as the default type, which is the mechanism getTypeConfig already implements for exactly this case (see the comment above the fallback), so editing a resource that matches no specific type uses the schema configuration.

mimeType and mimeTypeStrategy are declared in that configuration too. DEFAULT_CONFIG declares both, so without them the change would just move the data loss to the MIME type: editing a resource stored as gmx:MimeFileType would rewrite the protocol without it. Declaring them keeps every field the edit form already had.

mimeTypeStrategy is declared non-multilingual because it is an option passed to the process, not a user input. Without that it is added to the multilingual field list and blanked when the protocol changes, and the process then stores the protocol without the MIME type.

Result

Editing a resource with both an applicationProfile and a MIME type, changing only its description:

	applicationProfile	MIME type
before	dropped	kept
after	kept	kept

Visible change

The MIME type input now appears in the Add dialog for iso19139. It was already present when editing a resource, via DEFAULT_CONFIG, so this removes an inconsistency where a MIME type could be set on an existing resource but not on a new one.

Testing

By hand on an iso19139 record, checking the submitted process parameters and the stored XML in each case:

• add, close, add again: the configured default protocol is present both times
• editing a resource whose protocol does not match the configured default now resolves to the schema type, with its tooltips, required flags and applicationProfile field
• editing after adding, and adding after editing, both keep the configured defaults
• adding a resource with a MIME type and an applicationProfile stores gmx:MimeFileType and gmd:applicationProfile
• editing that resource and changing only the description preserves both
• mvn -pl web-ui prettier:check passes

Note

#9461 also touches OnlineSrcDirective.js a few lines from the first change here, so one of the two will likely need a trivial rebase depending on merge order. The changes are independent: that one concerns which value of mimeTypeStrategy is submitted, this one concerns which configuration the dialog uses.

[josegar74]

Tested with ISO19139 and looks working fine. Please check the comments added.

[josegar74]

Suggested change

	"tooltip": "gmd:MimeFileType"
	"tooltip": "gmx:MimeFileType"

Requires also to update the labels.xml in ISO19139 to add the following, as not defined:

 <element name="gmx:MimeFileType">
    <label>Format</label>
    <description>File type format</description>
  </element>

[josegar74]

With this change, it shows always the format field in the dialog. Previously it was displayed only if the XML contained gmx:MimeFileType.

It looks fine as if the value is empty, it is encoded as gco:CharacterString, but it can be maybe confusing for users, what do you think @fxprunayre?

[josegar74]

Maybe similar changes should be applied to ISO19115-3.2018?