Bug Hunting Session
Bug 93618 - cell value in table grid a date/time control incorrectly displayed
Summary: cell value in table grid a date/time control incorrectly displayed
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords: regression
Depends on:
Blocks:
 
Reported: 2015-08-24 10:59 UTC by Alex Kempshall
Modified: 2018-01-24 14:46 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstrates bug 93618 (17.05 KB, application/vnd.oasis.opendocument.database)
2015-08-24 11:01 UTC, Alex Kempshall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Kempshall 2015-08-24 10:59:19 UTC
With 5.0.0.5 Base I've started having problems with subforms

In my application I have a number of tables, two of which are Subscribers and Payments which are linked on a common column Subscriber_ID. There is a third table that is used to filter the data in the subscribers table only ever has one row in it.

I only have one form and when I use the form editor and then start the Form Navigator I see this -

Forms
	FormSearch
		FormDetails
			FormPayments 
                          

In the above my main form is FormSearch which is linked to the subform FormDetails by the common column Subscriber_ID. The subform FormDetails is itself linked to the subform FormPayments by the common column Subscriber_ID. The FormPayments contains a table called PaymentDetails.

This should work flawlessly as follows -

A1.
Open the form and see the last viewed subscriber details with the subscribers payment details populated in the PaymentDetails table.

A2.
Select a different subscriber from the drop down box in FormSearch, the contents of the sub form FormDetails changes to reflect the required subscriber and the contents of the PaymentDetails table changes to reflect the currently viewed subscriber's payment details.

With 5.0.0.5 I get this -

B1.
Open the form and see the last viewed subscriber details with the subscribers payment details populated in the PaymentDetails table. Except that the first cell in the table is empty, the rest of the data is correct.

B2.
Select a different subscriber from the drop down box in FormSearch, the contents of the sub form FormDetails changes to reflect the required subscriber and the contents of the PaymentDetails table changes to reflect the currently viewed subscriber's payment details. Except that the first cell now contains the data from the previously viewed subscriber, i.e. the cell contains the data that should have been displayed in the cell during step B1 above. The rest of the data is correct.

Alex
Comment 1 Alex Kempshall 2015-08-24 11:01:23 UTC
Created attachment 118111 [details]
Demonstrates bug 93618
Comment 2 Alex Thurgood 2015-08-24 13:21:37 UTC
Form appears to work correctly in

Version: 4.1.4.2
Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

OSX 10.10.4

There is no blank first cell in any of the payment detail table grids and the display updates accordingly with the chosen subscriber.


With Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale : fr-FR (fr.UTF-8)

I can confirm that first cell of table is displayed blank, but _only_the_first_time that the data for that subscriber is called up. In subsequent call ups for the same subscriber, the first cell value is displayed correctly. I can also confirm that the first cell of the grid, when changing the subscriber for the first time only, keeps the data value of the previous subscriber.

Confirming : regression
Comment 3 Alex Thurgood 2015-08-24 13:24:13 UTC
Also works correctly in 
Version: 4.3.5.2
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
Comment 4 Alex Thurgood 2015-08-24 13:33:59 UTC
Sounds oddly like a duplicate or recent bug that was fixed by Lionel and which introduced a regression which causes the blanking out of the value in the first cell.


As for the repeat display of the cell value of the preceding record in in the first cell, I don't remember whether this was linked or not to the original bug, but I seem to recall it was.
Comment 5 Lionel Elie Mamane 2015-08-24 13:36:59 UTC
(In reply to Alex Thurgood from comment #4)
> Sounds oddly like a duplicate or recent bug that was fixed by Lionel and
> which introduced a regression which causes the blanking out of the value in
> the first cell.
> 
> 
> As for the repeat display of the cell value of the preceding record in in
> the first cell, I don't remember whether this was linked or not to the
> original bug, but I seem to recall it was.

I'd be grateful if you could find back this bug, and retest this one with a version where it is fixed.
Comment 6 Alex Thurgood 2015-08-24 14:09:05 UTC
(In reply to Lionel Elie Mamane from comment #5)


> 
> I'd be grateful if you could find back this bug, and retest this one with a
> version where it is fixed.


Had a trawl, but no dice, I saw mjayfrancis had bibisected the earlier bug report pointing back to your commit, but damned if I can find it again now...
Comment 7 Alex Thurgood 2015-08-24 14:18:13 UTC
(In reply to Alex Thurgood from comment #6)
> (In reply to Lionel Elie Mamane from comment #5)


> > I'd be grateful if you could find back this bug, and retest this one with a
> > version where it is fixed.
> 
> 
> Had a trawl, but no dice, I saw mjayfrancis had bibisected the earlier bug
> report pointing back to your commit, but damned if I can find it again now...

Bug 92725
Comment 8 Alex Thurgood 2015-08-24 14:27:14 UTC
In 

Version: 5.1.0.0.alpha1+
Build ID: ad1f0d1f1a195a00cf2ec2848745fdc6186bfbb1
Locale: fr-FR (fr.UTF-8)

I can still reproduce the problem reported here.
Comment 9 Alex Thurgood 2015-08-24 14:32:27 UTC
Bug 93390 is the bug where mjayfrancis bibisected 

commit 3b9e66fdcade5a222a9dc99ad74627473b1fd4e7

as altering the behaviour of the display of numeric data in grid controls
Comment 10 mag4 2015-10-14 08:39:50 UTC
Hi, we also have the same problem upgrading to version 5.0.2.2 on Debian Testing.
It seems to us that only the date/time cells are affected ...
Regards!

Guido
Comment 11 Lionel Elie Mamane 2015-10-14 12:58:30 UTC
(In reply to Alex Kempshall from comment #0)


> A2.
> Select a different subscriber from the drop down box in FormSearch,

I assume you mean "and click the button 'Search Subscriber'".

> the contents of the sub form FormDetails changes to reflect the required
> subscriber and the contents of the PaymentDetails table changes to reflect
> the currently viewed subscriber's payment details.

Cannot reproduce in my development tree, in which I just fixed bug 93390. Assuming this is the same bug as bug 93390. If you can reproduce in any future version (released or nightly) where bug 93390 is fixed, please reopen.

*** This bug has been marked as a duplicate of bug 93390 ***
Comment 12 Alex Kempshall 2015-10-15 11:26:21 UTC
Just tried the nightly build -

libreoffice-5-0~2015-10-15_00.30.07_LibreOfficeDev_5.0.4.0.0_Linux_x86_rpm.tar.gz

the cell is now populated.

However, it's populated with the wrong contents. Using the supplied database bug93618.


Assuming the last subscriber viewed in a previous session was 730 when stepping through subscribers in the following order the date in the first cell of the payment details should be 

Subscriber id:     Date    

730                24/12/13
828                12/12/13
829                10/08/14
830                01/07/13
1339               20/02/14
1340               24/02/14

What I'm seeing is 


Subscriber id:     Date    

730                24/12/13
828                24/12/13
829                12/12/13
830                10/08/14
1339               01/07/13
1340               20/02/14


Alex
Comment 13 Lionel Elie Mamane 2015-10-16 12:40:54 UTC
(In reply to Alex Kempshall from comment #12)
> Just tried the nightly build -
> 
> libreoffice-5-0~2015-10-15_00.30.07_LibreOfficeDev_5.0.4.0.0_Linux_x86_rpm.
> tar.gz
 
> the cell is now populated.
 
> However, it's populated with the wrong contents.

Thanks for testing so fast! That's really helpful. I have a tentative fix. Hope to commit today.
Comment 14 Commit Notification 2015-10-16 13:13:31 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6c329cc55af00fec99ada5cac15b2d4752b7474

tdf#93618 teach DbCellControl about "Date"/"Time" as known value property

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Alex Kempshall 2015-10-19 09:44:21 UTC
Did a git pull on master, compiled and tested.

Looks good to me.

Thanks

Alex
Comment 16 Julien Nabet 2015-10-19 10:04:25 UTC
Thank you for your feedback, let's put this one to VERIFIED then.
Comment 17 Commit Notification 2015-10-20 12:42:01 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=de79c5838412a89313777e61c6cdc2ac01f9980a&h=libreoffice-5-0

tdf#93618 teach DbCellControl about "Date"/"Time" as known value property

It will be available in 5.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2015-10-27 05:57:20 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e9e8066d1182e513394749615ae5254b4944e6b&h=libreoffice-5-0-3

tdf#93618 teach DbCellControl about "Date"/"Time" as known value property

It will be available in 5.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Julien Nabet 2015-10-27 06:28:42 UTC
Let's simplify a bit
Comment 20 itsupport 2015-11-17 12:33:31 UTC
Had similar bug.
Tested with 5.0.3 (Comment 18 said it was pushed in 5.0.3) : bug still here
Tested with daily (5.0.4dev) : bug fixed
Hopefully, it will be in 5.0.4 :)
Comment 21 Lionel Elie Mamane 2015-11-17 14:01:18 UTC
(In reply to itsupport from comment #20)
> Had similar bug.
> Tested with 5.0.3 (Comment 18 said it was pushed in 5.0.3) : bug still here
> Tested with daily (5.0.4dev) : bug fixed
> Hopefully, it will be in 5.0.4 :)

Yes, there was a mistake. The fix was put in the 5.0.3 branch, but after 5.0.3 was tagged/compiled, so too late. The fix will definitely be in 5.0.4.
Comment 22 mag4 2015-12-14 08:11:45 UTC
Hi, upgrading to version 5.0.4 on Debian Testing fix the bug.
Thank you and regards!

Guido