Bug 118420 - TRACK CHANGES: Shifting status of "show track changes" or "Record track changes" changes "saved" status
Summary: TRACK CHANGES: Shifting status of "show track changes" or "Record track chang...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.7.2 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Track-Changes Writer-Toolbars
  Show dependency treegraph
 
Reported: 2018-06-27 16:50 UTC by sdc.blanco
Modified: 2018-06-28 09:41 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2018-06-27 16:50:22 UTC
1.  Open a new document.
2.  Shift status of "Show Track Changes" or "Record Track Changes"

Result:  "Save" status of document is now shown as "unsaved".

         (Same situation occur with any document)

Expected behavior: 

Changing "show track changes" or "record track changes" status does not change the "Saved" status of the document.
Comment 1 Dieter 2018-06-27 17:43:23 UTC
I confirm it with

Version: 6.1.0.0.beta2 (x64)
Build ID: 0f4d2060bc90b4008fbc8e6d9a49ec7eeea60b78
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: en-US (de_DE); Calc: CL
Comment 2 Xisco Faulí 2018-06-28 09:16:48 UTC
This is the expected behaviour.

Show track changes and record track changes are 2 properties saved in the document and not in LibreOffice in general, thus, if we change them, the UI asks to save it.

Closing as RESOLVED NOTABUG
Comment 3 Dieter 2018-06-28 09:41:21 UTC
(In reply to Xisco Faulí from comment #2)
> This is the expected behaviour.
> 
> Show track changes and record track changes are 2 properties saved in the
> document and not in LibreOffice in general, thus, if we change them, the UI
> asks to save it.

But I would expect, that - if something is changed in the document - the undo button is active. That's not the case and so it is not consistent. If you agree to that, Xisco, I'll open a bugreport.