Bug 138776 - FORMS: Defined fields altered partly to default and couldn't be set back to former properties
Summary: FORMS: Defined fields altered partly to default and couldn't be set back to f...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-12-09 13:21 UTC by surbun
Modified: 2021-05-16 04:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
File to show the bug (698.89 KB, application/pdf)
2020-12-09 13:21 UTC, surbun
Details
Sample file for testing purpose (153.82 KB, application/vnd.oasis.opendocument.database)
2020-12-12 09:04 UTC, surbun
Details

Note You need to log in before you can comment on or make changes to this bug.
Description surbun 2020-12-09 13:21:30 UTC
Created attachment 168002 [details]
File to show the bug

Hello,

Properties of defined fields are changed

- Integer changed to float

- text fields defined multiline changed to singleline

I joined a file to show the bug

I compare it to the build on 29/11/2020

Thanks

UBUNTU 20.04 LTS
Gnome 3.36
Comment 1 surbun 2020-12-11 05:05:05 UTC
Same bug in the last build (10/12/2020)
Comment 2 Xisco Faulí 2020-12-11 18:07:38 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 3 surbun 2020-12-12 09:04:21 UTC
Created attachment 168090 [details]
Sample file for testing purpose

(In reply to Xisco Faulí from comment #2)
> Thank you for reporting the bug. Please attach a sample document, as this
> makes it easier for us to verify the bug. 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' once the requested document is provided.
> (Please note that the attachment will be public, remove any sensitive
> information before attaching it. 
> See
> https://wiki.documentfoundation.org/QA/
> FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help
> on how to do so.)

Thanks for your reply.
As requested, here  sample file to enable you to test the bug.

BS
Comment 4 surbun 2021-01-05 05:32:30 UTC
Hello,

It seems to me that this bug has been, somehow, forgotten.

May be that in the next days, someone will try to see for it.

Thanks for your work

BS
Comment 5 Robert Großkopf 2021-01-05 08:27:38 UTC
Description of this bug is a little bit confusing. I will try:

Execute the form of the attached database file.
Field "id" in the table control will be shown with 2 decimal places.
Open the form for editing.
Right mouse click on the header of the table "id" → chose "Column".
Set in properties "Decimal accuracy" - 0.
Close the dialog (there is no button for save - it should be saved automatically).
Save the form.
Execute the form.
… and again there are 2 decimal places.

Same behavior for a textbox, which isn't part of the table control. Changing to multi line will be shown, also it will be shown when directly reopening the properties for such a field, but it won't be saved in the form.

Tested all this daily build from 2021-04-01, LO 7.2.0.0 alpha0+ with VCL:kf5 on OpenSUSE 15.2 64bit rpm Linux.
Comment 6 Robert Großkopf 2021-01-05 11:14:15 UTC
This buggy behavior doesn't appear in Versions like LO 7.0.4.2 or LO 7.1.0.1. So it's a regression.
Comment 7 surbun 2021-01-05 17:10:49 UTC
(In reply to Robert Großkopf from comment #6)
> This buggy behavior doesn't appear in Versions like LO 7.0.4.2 or LO
> 7.1.0.1. So it's a regression.

Hello,

I noticed the bug since the version just after the 7.2 alpha build dated 29th november 2020. (Page 2 in the 1st attached file)

Thanks for looking for a patch

BS
Comment 8 Robert Großkopf 2021-01-05 17:26:21 UTC
(In reply to surbun from comment #7)
> Hello,
> 
> I noticed the bug since the version just after the 7.2 alpha build dated
> 29th november 2020. (Page 2 in the 1st attached file)
> 
> Thanks for looking for a patch
> 
> BS

Why did you set this bug to UNCONFIRMED? I have confirmed it an then it has to be set to NEW, so other people could see: Here is a bug with a regression. Let us have a look witch part of code is the code, which changed LO to produce this bug.

Have set it back to NEW
Comment 9 surbun 2021-01-05 18:44:19 UTC
(In reply to Robert Großkopf from comment #8)
> (In reply to surbun from comment #7)
> > Hello,
> > 
> > I noticed the bug since the version just after the 7.2 alpha build dated
> > 29th november 2020. (Page 2 in the 1st attached file)
> > 
> > Thanks for looking for a patch
> > 
> > BS
> 
> Why did you set this bug to UNCONFIRMED? I have confirmed it an then it has
> to be set to NEW, so other people could see: Here is a bug with a
> regression. Let us have a look witch part of code is the code, which changed
> LO to produce this bug.
> 
> Have set it back to NEW

It was tagged as "unconfirmed". I wanted to change it to "confirmed" & I noticed that there's nothing corresponding to this tag. So I let it unchanged (unconfirmed)

Thanks for changing it to the right tag.

BS
Comment 10 surbun 2021-02-12 02:38:26 UTC
Hello,

I tried the dailybuild of the 10th and noticed that the bug is still there.

May be there's someone who can have a look to the codelines.

Thanks for your work

BS
Comment 11 surbun 2021-04-05 06:44:21 UTC
Hello,

It seems that the bug is no more there.

Thanks a lot for your work 

BS
Comment 12 Robert Großkopf 2021-04-05 07:32:49 UTC
Have tested it also with daily build from 2021-04-04. Seems the bug is gone.

I will set this one to WORKSFORME.