List "restart numbering" is not preserved in documents for the first lists in a document, despite applying "Restart numbering" for the first item of the lists. I'm working with a master document and each of the first lists in the subdocuments continue their numbering in the master document starting from the last number of the list in the previous subdocument. I decide to try applying the "Restart numbering" property to the first list of each subdocument, but unfortunately this property seems to be lost on document closing and reopening, despite prior saving of the document with this property change. Please fix.
Could not reproduce. 1. New master document 2. Insert new subdocument 3. Created a numbered list 4. Insert new subdocument 5. Created a numbered list, applying "Restart numbering" to the first item 6. Updated master document List numbering for 2nd subdocument starts from 1. Save & reload of master document doesn't change anything. You should attach a test case. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 186f32f63434e16ff5776251657f902d5808ed3d TinderBox: Win-x86@39, Branch:master, Time: 2015-10-16_09:42:47 Locale: en-US (fi_FI) Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the test case.
Created attachment 119748 [details] Masterdocument and subdocuments in which the list numbers are no longer renumbered starting with subdocument3 You can observe the renumbering issue with the lists on page 9, lists that belong to subdocument3.
(In reply to Darius Daniel Grigoras from comment #2) > Created attachment 119748 [details] > Masterdocument and subdocuments in which the list numbers are no longer > renumbered starting with subdocument3 > > You can observe the renumbering issue with the lists on page 9, lists that > belong to subdocument3. I opened subdocument3, went to the first numbering entry, selected Restart numbering. Reloading master document showed that the problem was gone. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
(In reply to Beluga from comment #3) > (In reply to Darius Daniel Grigoras from comment #2) > > Created attachment 119748 [details] > > Masterdocument and subdocuments in which the list numbers are no longer > > renumbered starting with subdocument3 > > > > You can observe the renumbering issue with the lists on page 9, lists that > > belong to subdocument3. > > I opened subdocument3, went to the first numbering entry, selected Restart > numbering. > Reloading master document showed that the problem was gone. > > Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) > Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe > Locale: fi-FI (fi_FI) Really? Well I did that three times to no avail. Would you like to use TeamViewer to convince yourself. I've said in my initial post that "restart numbering" is not preserved in documents when I save them, as is in the case of subdocument3. What? Don't tell me I'll have to delete my user profile for this to work, as this was the solution I was given to fix the page number alignment in the table of contents, and I have to reset my user profile each time I updated a TOC if I want to have the page numbers properly aligned, which is really lame, but that's a different topic to which no solution was offered to me except denial of the issue.
Now I opened the master document again and the problem was still present. Weird.. Could not get it right, so setting to NEW. Yet, you could also try with a completely new document, if you can reproduce it.
(In reply to Beluga from comment #5) > Now I opened the master document again and the problem was still present. > Weird.. Could not get it right, so setting to NEW. > > Yet, you could also try with a completely new document, if you can reproduce > it. I was not able to reproduce this with completely new documents.
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
Same reporter opened bug 121064 which I closed as duplicate of bug 40929. *** This bug has been marked as a duplicate of bug 40929 ***