As contact_email has moved from core DataObj/EPrints.pm to flavours/pub_lib/cfg.d/eprint_fields_common.pl. If any changes had been made to this field in core (i.e. not to prevent it being exported for GDPR reasons), this change will be reverted.
For better GDPR compliance It makes sense to set export_as_xml to 0 by default (in flavours/pub_lib/cfg.d/eprint_fields_common.pl) and then system admins can change this if they are unhappy. I believe this will still appear in history revisions but it would be useful to check how easy it is to re-include this in internal (authenticated) exports.
The text was updated successfully, but these errors were encountered:
I believe this will still appear in history revisions
Did you validate this is true?
From observations in v3.3.16, and code inspection of the current 3.4 branch, I don't think this is the case - are you able to confirm that export_as_xml => 0 fields appear in your XML revision files? (I've just tried testing this on http://tryme.demo.eprints-hosting.org/ but it's 3.4.0 and the contact_email field doesn't have export_as_xml => 0 set)
To my mind, this means XML revision files are an incomplete record of changes. For contact_email and GDPR purposes, this may still be desirable, but other export_as_xml fields possibly should be included in the revisions.
The export_as_xml flag is being used for two purposes - including/excluding public information (e.g. by Export::Simple) and by back-end processes (e.g. revision files).
There should probably be two different flags for this (or export_as_xml could be a set rather than a boolean - but that would be quite messy IMO.)
Hi John. You are right. Another example of me assuming the logical thing, (i.e. all non-volatile fields need to be included into revision files or you cannot properly track the revision changes), and that not actually being the case. I think this may explain why I often see new revisions that don't seem to change anything but lastmod and rev_number fields, which should only be updated if something non-volatile in the eprint has changed.
What I have initially just done (not yet committed) is add an options flag for calling $dataobj->to_xml called "revision_generation" that if you set to 1 will override the export_as_xml, (i.e. will not skip adding field whether true or false). I have found that this now means the fileinfo field is exported when previously it wasn't. I am not sure if this is a good or bad thing, as it is a generated field based on the value of others, so maybe it should have been set as volatile all along.
I think this is longer-standing than just this change - but it felt like the right place to comment.
I think there's interplay with the 'hide_volatile' flag which is passed in to revision xml generation.
I haven't fully traced this through, but I think it is honoured by Subobjects that are documents, but not other metafield types - which might be where the fileinfo stuff comes in?