Local file for download checkbox+link not showing on the "download summary" form

[awalsh]

Using GN 2.8.0 RC1 clicking the "DOWNLOAD" button on the 'Hydrological Basins in Africa' sample record brings up a 'Download Summary' form but the form doesn't list the local file for download called 'basins zip'. The form only has a link to a shape file at www.fao.org, link to the WMS for the Hydrological Basins and a Google KML link

I check URL link to basins.zip in the metadata record and it looks OK:

<gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>​http://localhost:8080/geonetwork/srv/en/resources.get?id=1&fname=basins.zip&access=private</gmd:URL> </gmd:linkage> <gmd:protocol> <gco:CharacterString>WWW:DOWNLOAD-1.0-http--download</gco:CharacterString> </gmd:protocol> <gmd:name><gmx:MimeFileType type="application/x-compressed">basins.zip</gmx:MimeFileType></gmd:name><gmd:description> <gco:CharacterString>Hydrological basins in Africa (Shapefile Format)</gco:CharacterString> </gmd:description> </gmd:CI_OnlineResource>

Also the file basins.zip is there as a local file in the 'data' directory.

Attached is a screenshot of the download summary form I get with the 'Hydrological Basins in Africa' sample record.

Also attached is screenshot which demonstrates the 'Local' file link (description text) and download check box. This is what is missing i.e there should be a checkbox and a text link 'Hydrological basins in Africa (Shapefile Format)'.

BTW the same issue occurs with GN 2.8 + ANZMEST extension with ISO19139-MCP1.4 schema plugin.

Some other details:

Service is /geonetwork/srv/eng/prepare.file.download XSLT is C:\geonetwork2.8.0RC1\web\geonetwork\xsl/file-download-list.xsl

[awalsh]

Without local file for download

[awalsh]

With local file for download

[awalsh]

Some more clues....

I note its something to do with update-fixed-info.xsl alters the gmd:name/gco:CharacterString to a gmd:name/gmx:MimeFileType in the <gmd:CI_OnlineResource> element which contains the file for download resource. Reason being was that I happened to open the 'Hydro Basins ..' record for edit/fix as I noted the id no. was 10 in the sample XML gmd:URL which was out of synch with actual is id no. allocated when it was uploaded (31)

Before running update-fixed-info.xsl:

<gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>​http://localhost:8080/geonetwork/srv/en/resources.get?id=10&amp;fname=basins.zip&amp;access=private</gmd:URL>

</gmd:linkage> <gmd:protocol>

<gco:CharacterString>WWW:DOWNLOAD-1.0-http--download</gco:CharacterString>

</gmd:protocol> <gmd:name>

<gco:CharacterString>basins.zip</gco:CharacterString>

</gmd:name> ....

After running update-fixed-info.xsl:

<gmd:CI_OnlineResource> <gmd:linkage>

<gmd:URL>​http://localhost:8080/geonetwork/srv/en/resources.get?id=31&fname=basins.zip&access=private</gmd:URL>

</gmd:linkage> <gmd:protocol>

<gco:CharacterString>WWW:DOWNLOAD-1.0-http--download</gco:CharacterString>

</gmd:protocol> <gmd:name>

<gmx:MimeFileType type="application/x-compressed">basins.zip</gmx:MimeFileType>

</gmd:name> ... ...

Note gmd:name/gco:CharacterString is transformed to gmd:name/gmx:MimeFileType and how the id no in gmd:URL is re-synced to the correct id no 10->31

If you just upload the 'Hydro Basins ..' sample mef file and NOT edit it the download form comes up OK, you fill out the disclaimer and the file download OK.

It may be that prepareFileDownload.java or friends doesn't recognise the newer gmx:MimeFileType element ??

[simonp]

Andrew - reset by update-fixed-info is good, what appears to be the problem is that the record has been loaded but has not had a reset applied by updated-fixed-info. I'll check the various load paths.

Also - google kml links are missing some details.

[simonp]

If the database id specified in the mef file is already in use then the record will be assigned a new database id and any existing download links in the file will be incorrect. Could fix this by offering the user an option to run updateFixedInfo on the record on import? Would be better to remove the dependency on the database id and replace it with the metadata uuid I suspect. In the meantime (ie. for 2.8.x) maybe you could set up a massive/batch xslt to do the sync operation (like update-fixed-info) if the ids get out of sync. I think we'll move this to 2.9/trunk after a fix for the google kml links is applied - what do you think?

[simonp]

Tidied up link list in commit ​https://github.com/geonetwork/core-geonetwork/commit/6269b9569a04d41660f82fac5b568941ccebae91

[awalsh]

Hi Simon,

Thanks for taking look. Yes, this shows up an the issue with MEF uploads whereby the id no. in the download resource URL getting out of synch. with the id no. that GN allocates on the upload. I agree that it would be better if URL's were based on uuid in the longer term perhaps for v2.9.0. However for the short term (v.2.8.0) we have a couple of ways we could fix this:

1) As you noted an option to run updateFixedInfo.xsl after MEF import

2) Option to run an xsl (call it re-synch-id-no.xsl) after mef import. This just adjusts the id no in the gmd:URL to the GN catalog id. Perhaps a check box on the import form.

I prefer option 2) above, it just fixes what you need whereas option 1) goes and changes lots of other things that maybe you don't need.

I will put this issue out there on the developers list as well I sure there maybe are some other ways to fix.

Cheers,

Andrew

PS: Thanks for the fix to ticket #1081, will test in next few days