Description: I have a odt document including chapters and subchapters. 1. Chapter1 1.1 subchapter 1.1 2. Chapter2 2.1 subchapter 2.1 3. Chapter3 3.1 subchapter 3.1 Everytime y save to odt file the subchapters are renumbered: * 2.1 to 1.2 * 3.1 to 1.3 if I clean direct format (Ctrl+M) on these subchapters, it corrects and go back to 2.1 and 3.1 but when saving and loading, it becomes bugged again Steps to Reproduce: 1. Open attached file. See subchapters enumerations 2. use Ctrl+M to clean direct formats on every subchapter 3. Save file. Actual Results: Loading the file the subchapters are bugged again and Ctrl + M must be pressed again on every subchapter Expected Results: Subchapters should have clean direct formats, but not... Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 155936 [details] odt with Bugged subchapters
Thank you for reporting the bug. I can confirm the bug present in Version: 6.4.0.0.alpha1+ (x86) Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30 Locale: en-US (en_US); UI-Language: en-US Calc: threaded But, not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
This is a FILEOPEN problem
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=bafd49fb4d72b6dbb10b2fea1386d295dc9d435c author Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2018-10-14 22:55:25 +0200 committer Björn Michaelsen <bjoern.michaelsen@libreoffice.org> 2018-10-15 21:56:55 +0200 commit bafd49fb4d72b6dbb10b2fea1386d295dc9d435c (patch) tree c7f8273d9f7d51839411b051494208f53733f94d parent aa75bf8b11c6e2e4fd7e9988c3c9d7db2420389a (diff) tdf#118049 tdf#118833 tdf#118725: Fix some SwDepend regressions Bisected with: Adding Cc: to Bjoern Michaelsen
Still present in Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
repro 7.2+ Note that in an earlier time, this document was in an MS Format.
The subchapter style is not a renames "Heading 2", but a custom style. Why should this even work? If anything, the bug is that those headers are "2.1" and "3.1" in the first place ...
Hi David, Your test file has been created by conversion from a doc/docx file. Please could you provide the original MS-Word file to check how current version of LibreOffice import that file. To restore the expected behavior, you need to modify the style "Default Paragraph Style": - edit its style - in tab Outline & List, change List style to "No List" (instead of WW8Num10) - Apply then OK I do not see any good reason to have a numbering style there for the style "Default Paragraph Style" Best regards. JBF
Dear David, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear David, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp