Hi @drn05r,

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)

I think they will get excluded by the following:

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?