Description: If you are working with a DOCX file, Writer lets you insert comments in footnotes with no warning, but after you save the file, they are lost. Reopening the file, both in Writer and in Word, shows no comment at all. I understand Word doesn't allow comments in footnotes, but I consider it a bug because Writer allows you to insert them and doesn't give any warning about this. It should restrict the user from entering a piece of data that will be lost. Steps to Reproduce: 1. Open (or create and save) a DOCX file. 2. Insert a footnote. 3. Insert a comment in the footnote. 4. Save and reopen. Actual Results: Comment is not saved. Expected Results: User should be unable to insert a comment in a footnote if the file is in DOCX format. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.2 (X86_64) / LibreOffice Community Build ID: 41d6f628ba3f046f16b5fa9fa8db8d4c2ab3b582 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-AR (es_AR); UI: en-US Calc: CL threaded
There is a compatibility option for this use case: Go to Options - Advanced - Open Expert Configuration Search for AllowCommentsInFootnotes key -> change it to false, now the option will be disabled in the UI It would be nice to have some UI option to enable all similar MSO-compat options in one step. Currently these are hard to find and scattered all over the Options dialog. - There are some more keys in the same ooO.Compatibility.View category - Also now for Calc - Compatibility: bug 156611 - Also considering that recently a Forms menu related option was removed in bug 157006 - There are some MSO-compatibility settings under Load/Save - MS Office. Perhaps all these could be now consolidated into one UI setting to enable/disable all of them? Otherwise, feel free to mark duplicate of bug 86188.
No objection to have access to this option from Tools > Options > Writer > Compatibility. But would you have checked this, Nadie? (In reply to Gabor Kelemen (allotropia) from comment #1) > - There are some more keys in the same ooO.Compatibility.View category See https://github.com/LibreOffice/core/blob/master/officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs
I would, before getting to work in an important document. I certainly didn't think of going to the "Expert Configuration", so it would be a clear improvement.
So is this bug now only about this specific compatibility option, or the general MSO compatibility, or both?
This topic was on the agenda of the design meeting. We should not clutter the (compatibility) options and add important features only. My take here is AllowCommentsInFootnotes and ClockwisePieChartDirection but not ReverseSeriesOrderAreaAndNetChart and ReverseXAxisOrientationDoughnutChart. This could be easyhackable, code pointer is sw/source/ui/config/optcomp.cxx.
So is this a move towards limiting the UI for each external type, based on which file we open? So when we open a TXT, we should turn into a gedit clone? I do not see why should this be implemented. It would still be a problem, if one creates a new document, which then they would save as, say, DOCX. The important bit here is: (In reply to Nadie Nada Nunca from comment #0) > Writer ... doesn't give any warning about this. Well, technically speaking, it does: it warns by default, that saving to an external file format may loose data/formatting. If a user selects DOCX as their default file type, this warning would not show for DOCX; also, one may "do not show it again" in the warning - but in both cases, user tells that they know what they are doing. However: there is a longstanding issue of not having a *more detailed* warning about problems in export. We *may* provide details on export, if we postpone the warning until the export has collected the data for that; indeed, it would require some substantial work, and each such detailed warning needs to include some expansion notice like "Other incompatibilities may also happen", or the like...
I reviewed this issue today, and I think this can not be considered as an EasyHack. In an EasyHack, it is obvious what should be implemented, and then, code pointers are provided to do that implementation. Considering comment 6 from Mike, it is not obvious how this issue should be handled. I agree with Mike's suggestion to provide "more detailed" warning, but then it will be also out of the scope of an EasyHack. @Heiko: If you do not object, I will remove the easyHack keyword. What do you think?