Create a new document with several lists, assigned to one list-style. Set "restart numbering" for the first items of the created lists. The attribute 'text:start-value="1"' is saved for all the lists, except the first one. This is vital for using master-documents. Because of this issue, I have numbered lists in the second and later parts of the component document starting not with 1, instead, for example, with 3 or 5. P.S. The workaround is to set the attribute in ODF file manually (it should not be cleared by resaving document from LibreOffice). Another workaround is to use different list styles in different parts of the component document.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Issue is still reproducing in the 3.5.0 beta2
I tried to reproduce this bug using LibreOffice 3.5.4.2 on Linux Mint Debain Edition. And I can admit that this bug is correct and I could reproduce it. However you should note that for exactly reproducing this bug you should assign the same list-style to all the lists. To do so you must select all the lists, then press F11 to view all kind of styles, then select the "List Styles" button which is fifth button from the left to view all list-styles and then select the same list-style (e.g. "Numbering 1") for all the selected lists. After doing all these steps and saving and reopening the ODT file, the "Restart Numbering" button is enabled for first items of all lists except the first list. But after saving as DOC file and reopening it, not only the "Restart Numbering" button is disabled for all the items, but also each list now has different list-style (i.e. WW8Num3, WW8Num4 and WW8Num5).
Created attachment 112415 [details] ZIP containing master/sub ODTs showing renumbering problem (In reply to Pavel from comment #0) > Create a new document with several lists, assigned to one list-style. Set > "restart numbering" for the first items of the created lists. Attached example uses List 1 Start, List 1 Cont., and List 1 End paragraph styles, all associated with the Numbering 1 list style. Also tested with using only the List 1 paragraph style associated with the Numbering 1 list style (same behaviour). > This is vital for using master-documents. Because of this issue, I have > numbered lists in the second and later parts of the component document > starting not with 1, instead, for example, with 3 or 5. Confirmed. In the attached example, created under v3.6.7.2 the first list in the second sub-document (c.odt, when viewed from within a.odt) starts at item 4, rather than 1 as expected. Viewing the sub-document (c.odt) directly exhibits correct behaviour. Opening the example under these versions exhibits identical behaviour in all cases, so it appears inherited from OOo: v3.3.4.1 OOO330m19 Build: 401 v3.4.6.2 OOO340m1 Build: 602 v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b v3.6.7.2 Build ID: e183d5b v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a v4.2.8.2 Build ID: 48d50dbfc06349262c9d50868e5c1f630a573ebd v4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 v4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 (In reply to Sina Momken from comment #3) > ... but also each list now has different list-style > (i.e. WW8Num3, WW8Num4 and WW8Num5). This is unrelated to the problem described by this report and is instead the result of saving to a non-ODF file format that does not support list styles e.g., MS Binary (DOC). Original report relates to ODF master/sub-documents.
As per comment 4, summary edited to be clear this issue relates to ordered list numbering in master/sub-documents.
*** Bug 45516 has been marked as a duplicate of this bug. ***
This bug is definitely still there in 5.0.3 as well. Why is this still open after 4 years? Master documents and paragraph styles are what you're supposed to use with any moderately complex document yet they can't even handle numbering correctly.
I should also note that if you just use Numbering, then it restarts correctly in each subdocument. The problem comes when you start using a paragraph style to apply the numbering.
Created attachment 120671 [details] Master Document showing numbering not restarting with paragraph styles
This bug is definitely still there in 5.1.5.2 as well. Workaround - insert the top of the master document hidden paragraph numbering. Then your text will retain the option "restart numbering" when saving a document. But it is wrong way. We need an acceptable solution. Who can tell where to look to fix this bug? How can I help to fix it?
I found an additional solution: 1. Insert above your list item with the same style 2. The first item on your list to note "restart numbering" 3. Save the file 4. close the file 5. open the file 6. remove the first additional element 7. save the file This sequence will result - saving for the first item on your list options "restart numbering". I think the problem is specific in saving function
A simpler workaround that works for me, with no extra open/close Given the numbered list below 1) bla bla bla 2) bla bla bla place the cursor after the "1)", press enter, then right click restart numbering. place the cursor after the "1)" (up arrow), then press suppr now save
** Please read this message in its entirety before responding ** 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 http://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
After 7 years the bug is still there and I know that nobody cares. This bug is definitely still there in 5.1.5.2
Repro in 6.1+. Setting to "inherited". Adding Bug 117233.
Dear Pavel, 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 http://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
We use LibreOffice 6.0.7.3 and the bug is still present.
*** Bug 121064 has been marked as a duplicate of this bug. ***
*** Bug 95107 has been marked as a duplicate of this bug. ***
*** Bug 137484 has been marked as a duplicate of this bug. ***
*** Bug 155931 has been marked as a duplicate of this bug. ***