tables icon indicating copy to clipboard operation
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

Open wsauerlich opened this issue 7 months ago • 2 comments

Steps to reproduce

  1. Create a table which has the multiple selection type in any column
  2. Add a row with multiple options in a cell which is part of that column
  3. Delete one of the options which were predefined in step 1 by deleting it from the selectable options in the edit menu
  4. 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

wsauerlich avatar Nov 27 '23 23:11 wsauerlich

I can reproduce this. Thanks for explaining the problem in detail @wsauerlich

enjeck avatar Apr 14 '24 12:04 enjeck

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 ids 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.

enjeck avatar Apr 14 '24 13:04 enjeck