Don't Save User Data With Document

I’m using user data (Tools > Options > LibreOffice > UserData) in a Writer document to control whether certain fields are hidden or displayed. It works but the user data is stored with the document, which makes no sense, and I can’t find any way to say don’t do this but rather read the data from centralized source when the file is loaded. Unchecking Tools > Options > LibreOffice > UserData > Use data for document properties does nothing. Tools > Options > LibreOffice > Security > Security Options and Warnings > Remove Personal Information on Saving does nothing. Can a document be saved without user data, forcing this information to be read when the file is opened? W10 Libre 6.1.5.2 (x64) and Ubuntu-Mate 18.04 Libre 6.0.7.3.

Typically for documents …

  • Document properties hold the ID for the originator of the file.
  • Document content may be marked with the ID of the user who entered it (which is the case when you track changes).
  • Altering originator upon opening is strange, and as far as I can see it requires saving to be useful.

Typical situations when this “property import” is useful

  • Templates initiate a new document, and suggests saving this document to a different name so you don’t overwrite the template file. Works as requested, out of the box.
  • When you need to know who last edited a document without tracking changes.

For that last point, there is an “edited” property listed in the properties dialog. Not sure whether you can access this easily.

To clear user data, unticking the option to apply user data and clicking "remove (like you indicated) works for me.

So, why do you need this? Not saying it can’t be done, but perhaps a different approach is simpler and/or better.

I’m not quite sure to understand what you want to do and how you do it. I had a look at what is recorded in a file. User Data and File Properties are not recorded as some kind of dictionary in the file in any configuration of the check boxes.

The inserted fields are specially marked so that their content can be dynamically updated when some change. Their current content at time of save is also recorded in the file. This may be this copy you’d like to make empty.

When you reload the file, Writer displays the contents of the file. However, if you update the fields (F9), they take their value from user data/properties of the current computer. This means, if you send the file to another computer, field Docinformation Sender>Last Name et al. are changed to what they are on the second computer.

Unfortunately, there is no automatic field update on open. This may be compensated with a macro but I’m not competent in this area.

If my answer does not address your question, please edit it or comment my answer. Don’t use an answer which is reserved for solutions.

Changing the predicate data (user data that determines whether a field is displayed) and updating the fields makes the document appear to be modified. If the displayed fields change and the document is not saved, the document will revert to the previous state. This makes it appear that user data is stored in the document, but further testing reveals that it is field update that modifies the document. Just invoking update (F9) even if the displayed fields don’t change at all “modifies” the document. This is bad for version control, which relies on the file’s time stamp, and for distributing a single document throughout an organization where different readers (e.g. user-position) get appropriately customized views.

A feasible but imperfect remedy is an event-triggered macro that updates the fields and resets the modified state. The macro is assigned to Open Document in Tools > Customize > Events. If this is saved in the document then every time the document is opened the user will be asked whether to let macros run and, if they decline, the fields will not be updated. Saving in LibreOffice is more reliable and convenient in use but comes with a high coordination cost, as the macro has to be installed on each computer. It also will be essentially permanently resident because it will be invoked for every document and not just those for which it is relevant.

sub WhateverOnOpenDoc
    on error goto BadDoc
    createUnoService(DispatchHelper).executeDispatch( _
    ThisComponent.CurrentController.Frame, ".uno:UpdateFields", "", 0, Array())
    ThisComponent.SetModified(FALSE)
BadDoc:
    on error goto 0
end sub