Download it now!
Bug 125990 - FILEOPEN DOCX Deleted non-numbered paragraph gets numbering from subsequent numbered paragraph
Summary: FILEOPEN DOCX Deleted non-numbered paragraph gets numbering from subsequent n...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Track-Changes
  Show dependency treegraph
 
Reported: 2019-06-18 15:07 UTC by NISZ LibreOffice Team
Modified: 2019-08-12 13:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word (19.20 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-06-18 15:07 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer (174.81 KB, image/png)
2019-06-18 15:08 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2019-06-18 15:07:31 UTC
Created attachment 152275 [details]
Example file from Word

In the attached file there are some deleted change tracked, numbered paragraphs. If the numbered paragraph is deleted with the preceding one in one step in Word, the preceding paragraph gets the numbering setting too.


Steps to reproduce:
    1. Create some numbered paragraphs in Word
    2. Enable change tracking and delete them along the previous paragraph
    3. Save the file and open it in Writer

Actual results:
The preceding paragraph gets numbered formatting.

Expected results:
The preceding paragraph stays unnumbered.

LibreOffice details:
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 99971d009e9c96d1d47aec14ecfbfeaa06dc140d
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-06-18_03:59:27
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL

Bibisected to: 
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=cbd894925e6b9869baedcd6476484c14d3a3df87 

author
László Németh <nemeth@numbertext.org>
2019-05-22 16:30:02 +0200
committer
László Németh <nemeth@numbertext.org>
2019-05-24 15:09:00 +0200
 
tdf#125319 DOCX track changes: don't change numbering
Comment 1 NISZ LibreOffice Team 2019-06-18 15:08:01 UTC
Created attachment 152276 [details]
Screenshot of the original document side by side in Word and Writer
Comment 2 raal 2019-06-18 15:10:48 UTC
Confirm with Version: 6.4.0.0.alpha0+
Build ID: ee4823e16e5fece068ee123b9c3e29834cd38763
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Comment 3 Commit Notification 2019-08-01 07:44:14 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/1aac73a1fb260e4c76a483a68f003913fdd2c4bb%5E%21

tdf#125990 change tracking: remove text join workaround

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.
Comment 4 Xisco Faulí 2019-08-02 13:02:00 UTC
Verified in

Version: 6.4.0.0.alpha0+
Build ID: 620fff54ca9cd04459cc5d963ef94d4438129fe4
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

Fixed by
https://gerrit.libreoffice.org/plugins/gitiles/core/+/1aac73a1fb260e4c76a483a68f003913fdd2c4bb

Two questions:
1. Should we create a unittest for it?
2. Should it be backported to 6.3 ?
Comment 5 László Németh 2019-08-05 10:00:34 UTC
@Xisco: thanks for the verification.

> Two questions:
> 1. Should we create a unittest for it?

I think, we need to test only the remaining format change during paragraph joininig, ie. partial paragraph deletion. I am working on it.

> 2. Should it be backported to 6.3 ?

It would be fine. I don't like the idea to use the reverted FinalizeImport workaround only in 6.3. Also I would be glad to the backport of the related DOCX and other change tracking fixes, if it's not too late for them. It would be a nice improvement for 6.3 (the first LibreOffice version, that is usable for working with legal texts, ie. big amount of changing numbered list in a mixed environment), and we could get more valuable feedback during the timeline of our project.
Comment 6 Xisco Faulí 2019-08-09 08:58:00 UTC
(In reply to László Németh from comment #5)
> @Xisco: thanks for the verification.
> 
> > Two questions:
> > 1. Should we create a unittest for it?
> 
> I think, we need to test only the remaining format change during paragraph
> joininig, ie. partial paragraph deletion. I am working on it.
> 
> > 2. Should it be backported to 6.3 ?
> 
> It would be fine. I don't like the idea to use the reverted FinalizeImport
> workaround only in 6.3. Also I would be glad to the backport of the related
> DOCX and other change tracking fixes, if it's not too late for them. It
> would be a nice improvement for 6.3 (the first LibreOffice version, that is
> usable for working with legal texts, ie. big amount of changing numbered
> list in a mixed environment), and we could get more valuable feedback during
> the timeline of our project.

Hi László Németh,
Would you mind backporting the needed commit to 6-3 branch in gerrit ? You know better than anyone what needs to be backported
Comment 7 László Németh 2019-08-12 13:01:34 UTC
(In reply to Xisco Faulí from comment #6)
> Would you mind backporting the needed commit to 6-3 branch in gerrit ? You
> know better than anyone what needs to be backported

Xisco: Hi, I'm going to check it, thanks!