Created attachment 135584 [details] .odt file to reproduce the problem Steps to reproduce: - open the attached document - look at the numbered formulas in the document => the second formula is deleted, yet its number is taken into account in the incrementation: the third formula should be numbered '2', not '3'.
I could reproduce it with the following steps 1. Open an new document 2. Open fields-dialog => variables 3. Choose number range / Text / Arabic: Text=Text Value=Text+1 => Insert 4. Repeat step 3 for two times 5. The document shows three fields (with the numbers 1, 2 and 3) 6. Enable record changes (Strg+Shift+E) 7. If you delete number 2, number 3 changes If you skip step 6, everything works fine.
Although I set this report to NEW, I'm not sure, whether this is really a bug or not. It also might be useful to change the numbering only after you accept the change. So I ad the keyword needsUXEval
Isn't this just a question of updating fields? Press F9 after show/hide changes to see how well it works.
No, pressing F9 does not change the field.
(In reply to Frederic Parrenin from comment #4) > No, pressing F9 does not change the field. @Xisco: Apart from the question if 'tracked' fields should count for numbering this might be a regression if field update doesn't work for Frederic. F9/Update fields updates the changed numbering if tracked changes are shown or not on my system. Version: 5.4.0.3 Build ID: 5.4.0-2 CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group
Maybe I did not explain correctly: F9 updates the fields, but in this case the numbering does not change. IMHO, in this case, there should be two fields: a field strikedthrough without the changes, and a field underlined with the changes applied.
WORKSFORME with Version: 7.1.0.0.alpha0+ (x64) Build ID: 41d8b41767032681a9897b7551f011d450e3725e CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded