Bug 160882 - Forms: Controls inside a table control, which could be activated by dropdown, are writable when set to "readonly"
Summary: Forms: Controls inside a table control, which could be activated by dropdown,...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Form-Controls
  Show dependency treegraph
 
Reported: 2024-05-01 06:45 UTC by Robert Großkopf
Modified: 2024-05-16 13:23 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2024-05-01 06:45:29 UTC
Download
https://bugs.documentfoundation.org/attachment.cgi?id=193905

Open the form.
There is a table control with different controls inside.
Control for "BirthDate" could be dropped down, control for "Hobby" is a combobox, control for "Town_ID" is a listbox.
All this boxes have been disabled. There shouldn't be allowed to change data.

Normal way to do this with standalone controls is to set he fields "readonly". But when setting "readonly" to this columns you could choose other values and change the entries.
You couldn't see the difference in GUI, because all fields inside a table control won't be shown greyed out when disabled.

Controls, which are set to "readonly" shouldn't allow to input new values.
Controls, which are set to "disabled" should be shown greyed out as they were shown for separate controls.

This behavior appears in all LO-versions, no regression I think.

Tested with
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 1 Stéphane Guillou (stragu) 2024-05-16 07:37:17 UTC
Tell me if this is correct:

1. Open the form in Edit mode
2. Right-click on on the Table Control's column headers > Column... > Set to "Enabled = Yes" and "Read-only = Yes"
3. Exit Design mode
4. Try changing the values in the controls that the column contains.

Result: value can be changed in the controls that the column contains

Expected: shouldn't be able to change the values because it is set to "readonly" - just like for individual controls.

Makes sense to me.

An interesting question would be: how do these settings interact with the Table Control's settings?

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 658a212585c56540a17c41111e6829716d4ef4e3
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded
Comment 2 Stéphane Guillou (stragu) 2024-05-16 07:42:03 UTC
(In reply to Robert Großkopf from comment #0)
> This behavior appears in all LO-versions, no regression I think.
I just tested 7.0.0.3 and back then, only Combobox and Listbox could be changed even though the column is set to readonly.
Now, in a recent daily build, I can change Combobox, Listbox and Date. But could be could just be an unrelated change in the GTK date-picker.
Comment 3 Robert Großkopf 2024-05-16 09:41:55 UTC
(In reply to Stéphane Guillou (stragu) from comment #2)
> (In reply to Robert Großkopf from comment #0)
> > This behavior appears in all LO-versions, no regression I think.
> I just tested 7.0.0.3 and back then, only Combobox and Listbox could be
> changed even though the column is set to readonly.
> Now, in a recent daily build, I can change Combobox, Listbox and Date. But
> could be could just be an unrelated change in the GTK date-picker.

You are right. Tested with LO 6.4.7.2 and the data couldn't be changed when set to readonly. So this is a regression.
Fist happens with 
Version: 7.1.0.3 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
here.

Combobox and listbox could be changed when set to readonly. This is a very old bug - might be it is inherited by OOo.

Should we split this bug into 2 bugs?
Comment 4 Stéphane Guillou (stragu) 2024-05-16 12:26:24 UTC
(In reply to Robert Großkopf from comment #3)
> You are right. Tested with LO 6.4.7.2 and the data couldn't be changed when
> set to readonly. So this is a regression.
Actually, I just had another look and the field was still read-only: the date can't be changed. We can pop up the date picker, but clicking a date has no effect, so still matches the "read only" definition in my opinion.
Comment 5 Robert Großkopf 2024-05-16 12:53:41 UTC
(In reply to Stéphane Guillou (stragu) from comment #4)
> (In reply to Robert Großkopf from comment #3)
> > You are right. Tested with LO 6.4.7.2 and the data couldn't be changed when
> > set to readonly. So this is a regression.
> Actually, I just had another look and the field was still read-only: the
> date can't be changed. We can pop up the date picker, but clicking a date
> has no effect, so still matches the "read only" definition in my opinion.

Have tested this again: Read only for the date control. Could choose a new date, could save a new date. All with LO 24.2.3.2 on OpenSUSE 15.6. Using KDE here.

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 6 Stéphane Guillou (stragu) 2024-05-16 13:23:20 UTC
(In reply to Robert Großkopf from comment #5)
> Have tested this again: Read only for the date control. Could choose a new
> date, could save a new date. All with LO 24.2.3.2 on OpenSUSE 15.6. Using
> KDE here.
My bad, I didn't realise one needs to double-click a date to change the value.
Yes, I can change the value even though the column is in read-only mode.
Reported and bibisected in 161133.