Description: I have a numbered list where the first item had a "restart numbering" option set. Steps to Reproduce: I moved the first item to the head of another numbered list (via cut & paste), so the old first item in the second list became the second item, but stil having number "1". So I selected "continue numbering" via right mouse button for the second item, just to find out that the number was still "1"! Looking again I realized that "restart numbering" was still in effect. I had to deselect it, then numbering was as intended. Actual Results: OK after using the fix described above. Expected Results: Correct result with fewer steps needed to fix. Reproducible: Didn't try User Profile Reset: No Additional Info: So these are the fixes to consider: 1) Do not copy the "restart numbering" attribute when copying list items. Or allow not pasting the attribute. 2) Make "continue numbering" and "restart numbering" mutually exclusive. 3) Both of the above. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
I confirm the behaviour you describe, but for me this behaviour is logical. So for me it isn't a bug. And I can think of a lot of situations, where it is helpful, that the "restart numbering" remains if you copy the item. So I change it to enhancement, because everything works as it should work. And my proposal is to close this bug as NOTABUG.
The issue is reproduced on with: • Operating system : Windows 8.1 Pro 64-bits. • LibreOffice : Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: en-US (en_US); Calc: group And also on : • Operating system : Ubuntu 16.04.3 64-bits. • LibreOffice :Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: ja-JP (ja_JP.UTF-8); Calc: group
On "NOTABUG": The original issue was ``"Resume numbering" does not cancel "restart numbering" on enumerated list'' (from comment #0) > (...) So I selected "continue numbering" via right mouse > button for the second item, just to find out that the number was still "1"! > Looking again I realized that "restart numbering" was still in effect. I had > to deselect it, then numbering was as intended. Please read again!
Let's set to NEW then.
I revert the summary to it's original state because I think the bug opener was misunderstood. It's not a pasting problem. I'll test this when I'm on a PC or laptop. Ulrich, please test again with a new document in LibreOffice 6.3 or 6.4.
I can't reproduce because if I insert parts of another list (direct formatted lists or list with styles formatting) the original list numbering isn't pasted. Therefore I can't resume nor deselect a numbering restart. Ulrich, please retest.
Created attachment 155088 [details] Example document
*** Bug 139912 has been marked as a duplicate of this bug. ***
Created attachment 171653 [details] 113213_restartNumbering.odt: example document to demonstrate request. I think I agree that a fairly logical work flow when switching from one list to another (called "add to list" instead of "continue numbering") would be to clear the "restart numbering" property at the same time.
sw/source/uibase/shells/textsh1.cxx's SwTextShell::Execute if ( pRule ) { + if( rWrtSh.IsNumRuleStart(/*pPam=nullptr*/) + && rWrtSh.GetNumRuleAtCurrCursorPos() != pRule) + { + rWrtSh.SetNumRuleStart(false, /*pPam=*/rWrtSh.GetCursor()); + } rWrtSh.SetCurNumRule( *pRule, false, sContinuedListId ); } [If the selection spans multiple numbering rules, the one at the cursor might be identical to the one being joined. So this isn't going to be consistent in every scenario, but it would cover the normal case - which should be good enough.] But this isn't good enough because IsNumRuleStart/SetNumRuleStart only affects pPaM->GetPoint() (the end of the selection), so instead we need to somehow step through the selection and check each para if it isNumRuleStart for a different numRule.
Proposed fix at https://gerrit.libreoffice.org/c/core/+/117660.
Created attachment 173213 [details] 113213 _removeNumberingWhileAddingToList.patch: abandoned Whether cancelling re-numbering while merging is desired will be completely dependent on the content, which a machine won't be able to determine. It would not be appreciated by automation. If you have already shot yourself in the foot by restarting numbering a list, and now you want to shot yourself in the other foot by merging it with another list, I guess you shouldn't be surprised that you feel pain. The patch seems fine to me, but Writer is so incredibly complex and I couldn't find the functions that I would have expected to handle basic things like walking through paragraphs. So perhaps the code is rather poor, since I felt I was re-inventing some basic things.
Since LO 7.2 we have "Add to List" instead of "Continue Previous Numbering" and we also have a documentation about it [1] and also a documentation about "Restart numbering"[2] Ulrich, taking into account this improvments, could you please retest? (I must admit, I couldn't understand comment 9 - comment 12) => NEEDINFO [1] https://help.libreoffice.org/7.3/en-GB/text/swriter/02/add_to_list.html?&DbPAR=WRITER&System=WIN [2] https://help.libreoffice.org/7.3/en-GB/text/swriter/02/06140000.html?&DbPAR=WRITER&System=WIN(In reply to Regina Henschel from comment #12)
I don't see a need for Needinfo, nor is this resolved with Help. I set New again.
I just realized (after years) that the Example document attached is text/plain. It was intended to be an ODT. However I can't reproduce what went wrong, and I don't have the document any more.
Created attachment 179921 [details] Example file Based on what I understand the initial problem was the following 1. open the attached file 2. Place cursor at 'Hello' at toggle restart numbering on 3. Save the file (needed for step 7) 4. Copy Select Hello 5. Paste it at list 2, number 4.. numbering restarts 6. Cause: List 1 has restart numbering toggled on & its included in copy/paste 7. File -> Reload 8. Notice the toggle restart numbering not being on (so it isn't saved). Technically outside the scope here Word behaves as OP expected (at least that's what I make of it)
Dear Ulrich Windl, 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