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.
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.
Version: 184.108.40.206.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