When creating a new paragraph style based on a pre-existing Heading N style (or, generally, on a style which is used in Chapter Numbering), the newly created style does not have the parent's outline level (it has "Body text" level). It's natural that participation in Chapter Numbering cannot be inherited; but the level itself should. The problem here is that users don't expect *some* property of heading styles to not be inherited, and are confused not seeing the newly created styles in Navigator/ToC etc. Also, maintaining the structure could be more difficult in case of changing the level, because children styles need to be modified separately. Steps to reproduce: 1. Create a new text document. 2. Make sure that Heading 1 is used in Chapter Numbering function. 3. Right-click the Heading 1 style in Styles sidebar pane, and choose New... Actual: On the Outline & Numbering page, see that outline level is Body text. Expected: The outline level is the same that Heading 1 has. If Heading 1 outline level changes (e.g., editing Chapter Numbering), children that haven't overridden the setting explicitly should also get the change.
confirm in Версия: 6.1.2.1 (x64) ID сборки: 65905a128db06ba48db947242809d14d3f9a93fe Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: GL; Локаль: ru-RU (ru_RU); Calc: CL
Also reproduced in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Actually, there is a lot of very specific code that very intentionally makes sure this anomaly happens. Changed the title to clarify that it isn't Heading X per se, but just because they tend to be assigned to Chapter Numbering. Quite honestly, the whole concept of a Chapter Numbering (as one specific style) seems pointless to me. It may have served a purpose when we didn't have the plumbing to handle it generically, but most of the plumbing is now there. Based on the code I saw, I at first assumed it was a MS concept, but I found it was actually a LO thing that was really messing up compatibility with MS documents.
/sw/source/core/doc/fmtcol.cxx SwTextFormatColl::AssignToListLevelOfOutlineStyle
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug