Bug 108342 - BASE, Editing: list field in table grid shows status row changed on opening form when it's first column
Summary: BASE, Editing: list field in table grid shows status row changed on opening f...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-06-05 12:37 UTC by Gerhard Weydt
Modified: 2023-07-06 19:43 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
test Base document (19.89 KB, application/vnd.sun.xml.base)
2017-06-05 12:37 UTC, Gerhard Weydt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Weydt 2017-06-05 12:37:59 UTC
Created attachment 133860 [details]
test Base document

If a table grid in a form contains a list field (with reference to another table) as first column, the field shows the status "row changed" when the form is opened in data-entry mode: a pencil is displayed, as after editing the row, instead of the triangle which is shown on a selected row. This only happens, when the list field is for the first column of the grid.
The attached base document contains the simplest version to reproduce this bug: two tables, table1.ref references table2.id; in the form a table grid containing the rows of table1 has a list field for this reference. The list field works correctly, but when the form is opened the wrong sign, the pencil, is displayed.
This happens only on opening the form. If you switch to another row and back, the triangle is displayed correctly. This also doesn't happen if you open the form for editing an then switch to the design mode. The pencil is also changed into a triangle if a button with the action "refresh row is pushed.
The attachment contains two forms, appropriately named, which have the list field in the first or the second column. The second example works correctly, the fisrt shows the bug. The second form was copied from the fist, only the columns have been interchanged.

In case someone thinks the example is badly constructed and we should use table2 as a "father" for table1: this is only due to the reduction to the simplest case. A realistic example would have the following relation: table0 1:n table n:1 table2, a classical n:m-relation, with table1 containing the references to the two other tables (it doesn't matter if table1 contains some other field: we would normally wish to show the list field in the first column). So this is not an "exotic" situation.

There is a work-around: Add a column with length 0 (and perhaps Enabled = No) before the list field.
The bug is assumed to be easily fixable, so in spite of a work-around it should be tackled soon.
Comment 1 Robert Großkopf 2017-06-06 06:53:47 UTC
Could confirm this buggy behavior. Works here up to 5.0.5, fails first with 5.1.0.3.

Note: Bug doesn't appear with 5.4.0.0beta1 - but another buggy behavior: Content of the listfield of the first column won't be shown when opening the form.

All tested with OpenSUSE 42.1 64bit rpm Linux
Comment 2 Robert Großkopf 2017-06-06 07:02:47 UTC
Could be related to the commit here:
https://bugs.documentfoundation.org/show_bug.cgi?id=90889
Comment 3 Julien Nabet 2017-06-08 19:40:34 UTC
On pc Debian x86-64 with LO Debian testing package (5.2.7.2), I could reproduce this.
However, I reproduce the behaviour indicated by Robert with master sources updated today. I noticed that the content isn't showed because the first left cell is selected in this case.

If you open the "ok form" and just left click once on a cell on right column, you can see it's blank too.
Comment 4 QA Administrators 2018-06-09 02:40:23 UTC Comment hidden (obsolete)
Comment 5 Robert Großkopf 2018-06-15 06:45:31 UTC
Couldn't reproduce the bug any more with LO 6.0.5.1 OpenSUSE 42.3 64bit rpm Linux. Seems it has been gone with the first LO 6.0 - have tested also with 5.4.6 where the bug already exists.

I will set this one to Worksforme.
Comment 6 Gerhard Weydt 2018-07-01 19:12:58 UTC
Robert is probably right in stating that this bug is not present in LibO 6.0. I also cannot reproduce it in 6.0.4.2.
B u t  it is there again in:
Version: 6.1.0.0.beta2 (x64)
Build-ID: 0f4d2060bc90b4008fbc8e6d9a49ec7eeea60b78
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: CL

and

Version: 6.2.0.0.alpha0+ (x64)
Build-ID: d8733e2c59f120acf9feddff04964becc3358621
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-06-26_11:09:03
Gebietsschema: de-DE (de_DE); Calc: CL

So I set the status back to NEW.
Comment 7 Xisco Faulí 2018-07-31 10:44:14 UTC
Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.
Comment 8 Robert Großkopf 2018-07-31 14:05:30 UTC
(In reply to Xisco Faulí from comment #7)
> Thanks for retesting with the latest version.
> Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been
> identified.

Hi Xisco,

a little bit to fast. See comment 6 → Bug is there again for LO 6.1.0.2. Just tested with OpenSUSE 24.3 64bit. So we have set it back to NEW.
Comment 9 Gerhard Weydt 2018-07-31 22:18:45 UTC
Hi Xisco,

Robert was faster than me.
But I may add that the bug also persists in

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 7119184f4b5441600f7b3eae7ec6771c094bbb7f
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-23_05:38:07
Locale: de-DE (de_DE); Calc: CL
Comment 10 Xisco Faulí 2018-08-02 14:45:07 UTC
I can reproduce it in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

but not in 

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

needs to be bisected with 5.1 repo... ( not in linux )
Comment 11 Aron Budea 2018-11-15 05:13:21 UTC
Bibisected to the following commit using repo bibisect-win32-5.1. Adding Cc: to Lionel Elie Mamane, please take a look sometimes.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=6c2f0c1001b0586b3092e80d63866ae018f09eb8
author		Lionel Elie Mamane <lionel@mamane.lu>	2015-07-22 16:26:31 +0200
committer	Lionel Elie Mamane <lionel@mamane.lu>	2015-07-22 16:35:28 +0200

ListBox in grid: properly set selection on change from model
Comment 12 QA Administrators 2021-06-22 03:37:36 UTC Comment hidden (obsolete)
Comment 13 Gerhard Weydt 2021-07-04 12:28:27 UTC
The bug is still present in:
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 93a3e2f86c27b06062708fe788963a0e49f3a90b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded
Comment 14 QA Administrators 2023-07-05 03:13:44 UTC Comment hidden (obsolete)
Comment 15 Gerhard Weydt 2023-07-06 19:43:13 UTC
Bug is still present in

Version: 7.6.0.0.beta1 (X86_64) / LibreOffice Community
Build ID: be55b15d98c5f059483845a183fcb5ea8023d27c
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded