Bug 129989 - Inserting a row in a table resets list numbers
Summary: Inserting a row in a table resets list numbers
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Add-Delete
  Show dependency tree / graph
 
Reported: 2020-01-14 09:55 UTC by devinebob
Modified: 2020-03-17 09:03 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description devinebob 2020-01-14 09:55:45 UTC 
Description:
In a table in Writer where a row contains a numbered list, inserting a row will affect the list.


Steps to Reproduce:
1. Create table
2. Insert a row
3. Create a numbered list in row
4. Insert new row

Actual Results:

Before insert:
|----------------------------|
|  1) foo                    |
|----------------------------|

After insert of new row:
|----------------------------|
|  1)                        |
|----------------------------|
|  2) foo                    |
|----------------------------|

Expected Results:

Before insert:
|----------------------------|
|  1) foo                    |
|----------------------------|

After insert of new row:
|----------------------------|
|                            |
|----------------------------|
|  1) foo                    |
|----------------------------|


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.10
CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 1 Dieter 2020-01-14 14:23:53 UTC 
Thank you for reporting the bug. It seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 2 Xavier Van Wijmeersch 2020-01-14 16:53:20 UTC 
i can reproduce with

Version: 6.3.4.2
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Version: 6.5.0.0.alpha0+
Build ID: 16e7ca76ae873fe953b483f4c34aa9e5610addf8
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 3 Dieter 2020-01-14 16:57:34 UTC 
(In reply to Xavier Van Wijmeersch from comment #2)
> i can reproduce with
> 
> Version: 6.3.4.2

> Version: 6.5.0.0.alpha0+

=> NEW
Comment 4 Timur 2020-03-17 08:51:36 UTC 
This is a wrong confirmation of a bug by "I reproduce" instead of deciding if this is a bug and why. Dieter, don't confirm if not sure. 

I don't agree this is a bug, but normal behavior in LO all the way from OO, same as in MSO. 
If numbering is applied in a table, we want it to be added for a new row. 
Other you may used static numbers. 

So I mark NotABug.
Comment 5 Heiko Tietze 2020-03-17 09:01:41 UTC 
(In reply to Timur from comment #4)
> If numbering is applied in a table, we want it to be added for a new row. 

The row is not a static object, you can add columns, rows, pivot things etc. If numbering was applied to #2 it can be somewhere else after turning things upside down. As a consequence you wont have access to the numbering properties, at least it's unclear where the attribute starts and how it works. The "number per table" approach is much easier to understand.
Comment 6 Heiko Tietze 2020-03-17 09:03:38 UTC Comment hidden (off-topic)