reExportAll does not respect the exclusion of email addresses of dataset contacts from metadata export when it should according to the configuration

[PaulBoon]

When disabling the export of email adresses in the metadata export on a existing system, we set :ExcludeEmailFromExport to true.

Newly published datasets get the correct metadata export, without the emails in DDI and JSON.
To clean all existing metadataexports, all published datasets need to be reexported.

However, after running curl http://localhost:8080/api/admin/metadata/reExportAll
the existing metadata exports are not changed, and for the new datasets the email adresses are back in the metadata exports.

[pdurbin]

@PaulBoon thanks for the bug report. If it helps, here's where the "exclude" logic is applied:

https://github.com/IQSS/dataverse/blob/v4.8.6/src/main/java/edu/harvard/iq/dataverse/util/DatasetFieldWalker.java#L86

I'm surprised that the logic above isn't used by reExportAll. It must be a different code path.

[PaulBoon]

Yes it's strange that it's not working, maybe it doesn't get the settings somehow. But I would like to have someone else confirm the bug, just to be sure that it's not only me or I am not doing something right here.

[pameyer]

On 4.8.1, I can confirm that running curl http://localhost:8080/api/admin/metadata/reExportAll results in email addresses being included in the cached export files.

[pameyer]

From preliminary additional investigation, I'm wondering if this behaviour could be related to API calls ending up in JsonPrinter with null SettingsServiceBean (assuming that's a condition that's actually occurring here).

[PaulBoon]

Looks like it needs a bit of debugging to confirm its the null SettingsServiceBean. BTW I am running a fork of 4.8.6.

[pdurbin]

While I was reviewing pull request #4691 I noticed that the deprecated ExportService.getInstance().getExport(dataset, formatName) method that doesn't pass in the SettingsServiceBean is still being called in four places:

[sekmiller]

I fixed the two references to the deprecated version of the ExportService.getInstance() that @pdurbin noted above. This fixes the export All bug. The one in the ExportService itself can be called with a null parameter since it's just getting the names of the Exporters to display in the UI.

I didn't fix the one in Xrecord since it's a POJO. @landreev can you take a look at it and see if it needs to be fixed.

[landreev]

@sekmiller @kcondon
About calling export from Xrecord - I believe it's ok; because the OAI server only handles the metadata records for the datasets that appear in the OAI sets. And only the datasets that have already been successfully exported are included in OAI sets...

So, in other words, this call from the OAI server should always be getting a cached copy.