Bug 91628 - BASE: Multiselection Option in Form List Control Broken or Disabled
Summary: BASE: Multiselection Option in Form List Control Broken or Disabled
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.4.3.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-26 03:32 UTC by Doug
Modified: 2021-06-06 05:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
screenshot of problem (392.08 KB, image/jpeg)
2015-06-10 23:05 UTC, ELSUPREMO1
Details
screen shot (61.03 KB, image/jpeg)
2018-06-05 13:21 UTC, Drew Jensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug 2015-05-26 03:32:45 UTC
In a Base form, can create list control to allow user to click on a list of possible database values, save the right value in the database field.

There is an property 'Multiselection' for the list box with a boolean choice of 'Yes' or 'No'.  This is not well documented and is believed to be for allowing a user to select more than one value from the list to be saved onto the database field.  Trying to use the 'Multiselection' option with the MySQL 'SET' data type.

PROBLEM:  When the 'Multiselection' option is toggled to 'Yes' and saved, nothing happens.  When the form is reopened in data access mode (outside edit mode) the 'Multiselection' option toggles back to 'No'.  That is, the property refuses to be activated and reverts automatically to 'No' contrary to editor inputs.

Problem replicated on LO 4.4.3/Windows 7 x32 (MySQL and HSQLDB backends) and on LO 4.4.3.2/OpenSuse 13.2 (HSQLDB backend)

TO REPRODUCE:
1.  Create database document
2.  Create form
3.  Create list box
4.  Set list box to 'Multiselection' property to 'Yes'
5.  Save and toggle to data access view (out of edit view)
6.  Toggle back to form edit mode, examine 'Multiselection' option.
7.  'Multiselection' option will be back to 'No'; functionality not enabled.
Comment 1 Robert Großkopf 2015-05-27 20:07:33 UTC
Can't confirm 'Multiselection' has gone back to 'No'. Shows 'Yes' here, but I don't know how I should chose more than one value. Have set Dropdown → No to see more than 1 Value, but cant chose more than one value.

My system: OpenSUSE 13.2 64bit rpm Linux, LO 4.4.3.2
Comment 2 Alex Thurgood 2015-05-29 13:48:48 UTC
Can not confirm that setting Multiple selection to Yes in listbox control properties doesn't work. I can set and unset in

Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Locale : fr_

and it sticks, whether I save the form or not between checking that the property is set.

On 5.1beta however, I get a nice little VCL crash...will report separately

OSX 10.10.3
Comment 3 Alex Thurgood 2015-05-29 13:50:58 UTC
Note that in my testing, the bound field to which the listbox was attached was not a SET, or ENUM type, but a CHAR, just in case that makes a difference.
Comment 4 ELSUPREMO1 2015-06-10 23:05:47 UTC
Created attachment 116452 [details]
screenshot of problem

Hi all,

I've confirened this on Windows 8. 
In edit mode and the list box properties (click control icon).
The "multiselection by default is "No"
Change to "yes" and click save.
Click design mode on/off icon.
The list box does not allow multiple selections of words (i.e. data). This should allow users to select multiple words of data.
Also, click design mode on/off icon again and the "multiselection reverts back to its default "No" instead of "yes". This is a problem.
Comment 5 QA Administrators 2017-05-22 13:39:03 UTC Comment hidden (obsolete)
Comment 6 Jean-Paul 2017-06-04 07:50:12 UTC
The bug is present, tested today with LO 5.3.3.2 under Windows 10 (x64), with unchanged  bug behavior.
Comment 7 QA Administrators 2018-06-05 02:38:32 UTC Comment hidden (obsolete)
Comment 8 Drew Jensen 2018-06-05 12:48:51 UTC
Multi-Select is only viable when the control is not connected to a data field.

You need to handle the list of strings, which you pass to the control either at design time (in which case you need to supply both the list of display strings and values to the control on two tabs) or run time (with a macro, say to decode what a field of type set would give you) and the database it is not automatic (even for a data type of set).

Unless that was added by the LibreOffice developers after the OO split.

I can give you an example with that. Which is to say that I just checked with 6.1 Beta that a list control worked as I expected it to (as described above) on a new form.
Comment 9 Drew Jensen 2018-06-05 12:59:21 UTC
That was not accurate, for all cases, in that above comment

The list box will automatically populate the list (with display and value rowset) from the database with multi-select enabled but not if it _also_ configured to update a field automatically.
Comment 10 Drew Jensen 2018-06-05 13:21:38 UTC
Created attachment 142539 [details]
screen shot

Here is a screen shot of a form with a multi-select list box working (just now with 6.1); The data form and list box control setup also - note that the target field is empty.
Comment 11 QA Administrators 2019-06-06 02:54:34 UTC Comment hidden (obsolete)
Comment 12 Robert Großkopf 2019-06-06 16:14:32 UTC
Have tested it again with LO 6.2.4.2 on OpenSUSE 15.

Multiselection could be chosen and works, if the listbox isn't connected to a database-field (which only saves one value).

Multiselection could be chosen and will be saved, but doesen't work, if the listbox is connected to a database-field. You could only select one value instead. Correct behaviour for the database, but it shouldn't be possible to chose Multiselection when connected to a database-field. No one of the internal database will have fields like ENUM or SET in MariaDB/MySQL.

Multiselection could be chosen. You could change from edit form to input data and then back - the property will be set back to "No". Seems something has recognized here there is no possibility for multiselection.

The only buggy behaviour I see: The property "Multiselection" must be disabled when connecting to a field of a database. 
An enhancement would be it shouldn't be disabled for a field like ENUM or SET. But in this case the possibility of sending more than one value to the field through GUI must also be implemented.
Comment 13 Robert Großkopf 2019-06-06 16:30:42 UTC
Have tested it now with SET-field of MariaDB, which would allow to set more than one value into the field. Seems the possibility isn't implemented to read and write more than one value into the field through the form. It will work in the table, but the field won't show any value if there are chosen 2 values.

ENUM-fields won't allow to save more than one value. So this fields will work well with Multiselection > No.

I would prefer to solve this bug by disabling the Mutiselection-property when a field of a database will be chosen in the properties of the field of the form.
Comment 14 Alex Thurgood 2019-06-06 17:58:34 UTC
FWIW, as far as I can recall, multiple selection data entry via UI form controls has never worked with mysql ENUM or SET bound fields, so this limitation dates back to OOo times.
Comment 15 QA Administrators 2021-06-06 05:27:10 UTC
Dear Doug,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug