<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - EDITING Adding/removing bullets&numbering is not change tracked" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143051#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - EDITING Adding/removing bullets&numbering is not change tracked" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143051">bug 143051</a> from <a class="email" href="mailto:libreoffice@nisz.hu" title="NISZ LibreOffice Team <libreoffice@nisz.hu>"> NISZ LibreOffice Team</a> <pre>(In reply to Dieter from <a href="show_bug.cgi?id=143051#c3">comment #3</a>) > According to > <a href="https://help.libreoffice.org/7.3/en-GB/text/shared/01/02230100">https://help.libreoffice.org/7.3/en-GB/text/shared/01/02230100</a>. > html?&DbPAR=WRITER&System=WIN turning on/off bulleted & numbered list is not > part of change record We should add insert/delete images to that page, since <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - EDITING: "Record/track changes": image deletion isn't recorded" href="show_bug.cgi?id=59463">bug #59463</a> is fixed :). But yeah this is an enhancement request, since the Normal Office can do this, so we should be too. (In reply to Heiko Tietze from <a href="show_bug.cgi?id=143051#c4">comment #4</a>) > Reported by yourself in <a class="bz_bug_link bz_status_NEW " title="NEW - EDITING Track Changes: Writer does not show the change in number of deleted numbered paragraphs" href="show_bug.cgi?id=115523">bug 115523</a>. No, this one is about recording turning on/off on an existing paragraph, while that other is about previewing the result of a paragraph deletion in numbering (and 115524 is about previewing the result of a paragraph insertion into a list). The general problem is that barely any function in the bullets&numbering toolbar generates a change tracking entry - unlike the Normal Office does. I have some canned bugs that wait only for a bit of time to upload them, and those cover pretty much all those toolbar commands. > > (Having several META tickets for missing TC features makes no sense to me.) My work hypothesis is that cutting up meta bugs into small (< 10-20 bug) mini-metas is more useful to oversee where we are regarding properly implementing a feature (by reducing the scope of features), compared to mega-size meta bugs like <a class="bz_bug_link bz_status_NEW " title="NEW - [META] OOXML Chart object issues" href="show_bug.cgi?id=75057">bug 75057</a> or <a class="bz_bug_link bz_status_NEW " title="NEW - [META] DOCX (OOXML) table-related issues" href="show_bug.cgi?id=104444">bug 104444</a> or even <a class="bz_bug_link bz_status_NEW " title="NEW - [META] Tracking changes issues" href="show_bug.cgi?id=83946">bug 83946</a>. This complements cutting up generic "nothing works, everything is bad" type complaints like <a class="bz_bug_link bz_status_NEW " title="NEW - Multiple operations are not tracked as change in change control" href="show_bug.cgi?id=33082">bug 33082</a> into small, actionable edit/import/export bugs about well defined menu commands/object attributes, by wrangling together these feature-based bugs under the way broader meta topics. I may be wrong though.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>