tables
tables copied to clipboard
deleting one option of a multiple options column rather hides itself and other entries plus maybe reuses their former "base" for replacements and supplements
Steps to reproduce
- Create a table which has the multiple selection type in any column
- Add a row with multiple options in a cell which is part of that column
- Delete one of the options which were predefined in step 1 by deleting it from the selectable options in the edit menu
- Add a new option in the same edit menu mentioned in step 3
Expected behavior
The option should be instantly and permanently deleted in every row where this option has been chosen and the options in the edit menu aswell. A row with one or more remaining options should still show these. And when adding (another) option a "whole new" option should be created.
Actual behavior
The chosen option remains visible until one clicks somewhere else and then back on the table or view, however the adding of an option is instantly visible. (Regardless whether of looking at a view or the "main page" of the table; showing the data and the views.)
As soon as one option is removed from the edit menu of the multiple selection column all cells in the rows that had chosen this option can no longer be edited and the remaining options within the cells are no longer visible.
When another option will be added later at the same "position", it will automatically be re-added to the rows, that lost an option before. Even if the option got a completly new name. The cells become editable and visible again, but it can cause confusion, because every new option is treated as a replacement for the deleted one and not a supplement for the bunch of all the other options.
Tables app version
0.6.4
Browser
Firefox 120.0
Client operating system
No response
Operating system
Debian
Web server
Apache
PHP engine version
PHP 8.1
Database
MariaDB
Additional info
No response
I can reproduce this. Thanks for explaining the problem in detail @wsauerlich
Making this note here so I don't forget:
When another option will be added later at the same "position", it will automatically be re-added to the rows, that lost an option before. Even if the option got a completly new name. The cells become editable and visible again, but it can cause confusion, because every new option is treated as a replacement for the deleted one and not a supplement for the bunch of all the other options.
This happens because whenever we add a new a selectionOption
, we use the length of the existing array. The id for each option is gotten from getNextId()
, which is based on the length of the existing options. So the id
s for options are not unique, since an id that was deleted earlier can be later reinstated.
The first solution I can think of is to keep track of the maximum option id seen so far, and ensure that getNextId()
exceeds or starts from this value. I can think of a way to do this directly from the frontend, but my approach seems complicated and hacky.