Created attachment 53337 [details] Behavior of track changes as it is working now, It would be nice if the number also gets a strike through and the list doesn't count the deleted number. Problem description: Mayby it is more like a feature request than a bug report. Tracking changes delivers for deleted text an line through. But when editing a numbered list the deletion of the number cannot be tracked. Steps to reproduce: 1. create a document with a numbered list 2. enable track changes 3. delete a rule with its number Current behavior: The deleted rule gets a strike through, but the number keeps normal or totally deleted without notion of its deletion Expected behavior: The nicest behavior would be that the number gets a strike through and the next number is the same, so that when the changes are accepted the numbering doesn't change any more Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20111002 Firefox/7.0.1 PaleMoon/7.0.1
reproduced in 3.3.4 and 3.5.2 on Fedora 64 bit changing version to 3.3.4 as most early reproducible for comparison, msWord 2007 strikes out all numbers of items beginning from deleted line until end of list and places new variants of numbers to right of stricked out.
Reproducible with LO 4.4.0.0.beta1 (Win 8.1). To delete the number you need to use the Backspace key to get to the previous line.
** 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.0.4 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
In the current 5.0.4.2 (x64) version of Libreoffice this bug, or lack of feature, is still present. Still either the number stays in normal formatting or with an extra backspace it gets deleted completely without tracking its deletion.
*** Bug 97519 has been marked as a duplicate of this bug. ***
** 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.2.5 or 5.3.0 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-20170306
Bug is still present in version 5.3.0.3 (X64) on windows. Behaviour is the same as the original reported behaviour. Either no line through the number of deleting the entire number.
Create a list: 1. one 2. two 3. three Track changes delete "two", you get : 1. one 2. (deleted) 3. three With one more backspace: 1. one (empty) (deleted) 2. three With Show/Hide Track Changes only deleted "two" is shown, without number. I had a case where numbers are messed up, but I can't reproduce.
*** Bug 93795 has been marked as a duplicate of this bug. ***
*** Bug 115523 has been marked as a duplicate of this bug. ***
Let's include the case when numbered items are added, numbering should reflect that it's due to a tracked change. The cases (deletion and addition) have to be fixed together after all.
*** Bug 115524 has been marked as a duplicate of this bug. ***
** 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
tdf#42748 show changes of list numbers and bullets At splitting or joining list items or adding new ones, the removed or new list number or bullet didn't show the change, only a vertical line added to the left margin of the list items. Moreover, deleting only the text of the list item (keeping its number) looked like the full deletion of the item.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/173b7fcaae86980809889db30ddb82f8ba883103 tdf#42748 show changes of list numbers and bullets It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 155239 [details] Screen shots: before & after fixing
From the screenshot, this only partially fixed (I'm not sure how to mark it in this tracker). - The "3" in the 4th part of the screenshots be a "2". - The color of the line through the deleted 2 should indicate that it was deleted and thus should match the deleted color line. Also, what happens to numbers after #3, the "Deleted this..." line? Do they get renumbered appropriately?
(In reply to Ellis Farmer from comment #17) > From the screenshot, this only partially fixed (I'm not sure how to mark it > in this tracker). > > - The "3" in the 4th part of the screenshots be a "2". I suggest to file a new issue to request the Word-like or a similar layout for numbered lists (bulleted lists are complete now with this fix). > - The color of the line through the deleted 2 should indicate that it was > deleted and thus should match the deleted color line. The strike out line is the same yellow, but the subpixel rendered screen shot may show it differently. > > Also, what happens to numbers after #3, the "Deleted this..." line? Do they > get renumbered appropriately? As the example can show, there is no perfect solution for the layout, ie. there was no "2 Item", because that "Item" was only part of the original "2 emItem". We have to choose between the compact/readable/but incomplete and the detailed/less readable/complete/hard to implement (see references) layouts. For example, I don't like the detailed double numbering of Word (every list item gets two numbers), because it's less readable, but I can imagine, that it can helpful, especially during software migrations, so I like the idea, analyzing Word and other document editors [maybe the references get similar double numbering, too], choosing and implementing a better or optional change tracking layout for numbered lists in Writer, too. That could be a second step. I think, this fix/issue has met the minimum requirement, visibility of changes in list items, and this is the first major step forward since 1998.
I think we can mark this one Verified and reopen 3 bugs that were marked duplicates. Thanks László. I most value those fixes that are "inherited".
This may go to Release Notes. Should other bugs be fixed, the better.