appsmith
appsmith copied to clipboard
[Feature]: Add options for labels in select columns in a table widget
Is there an existing issue for this?
- [X] I have searched the existing issues
Summary
The table widget now supports the Select
column type, which allows the column to contain both a label and a value. This could be useful for currency fields, foreign keys, or any other case where you want to display a different version of the column value. However, there is a problem with sorting.
With Select columns in a table widget, the label
is shown to the user while selecting an option, but then the value
is shown in the table widget, after the option has been selected. This is different from the behavior of a Select widget outside a table, which continues to show the label after an option has been selected.
Feature Request: To address this inconsistent behavior, and add support for sorting currency values, we should allow the user to choose:
-
Display as?
[label | value ]
-
Sort by?
[label | value ]
Why should this be worked on?
Multiple users have asked for a way to support a currency column in the table widget that both sorts and displays accurately. For now, users have to choose between displaying as a number (that sorts property) or as text with currency symbol (which sorts incorrectly).
https://github.com/appsmithorg/appsmith/issues/5632 https://discord.com/channels/725602949748752515/1076320585002532976 https://discord.com/channels/725602949748752515/1074651219588558868
It would be useful if it would still use the value
when interacting with table data programmatically, even if DisplayAs is set to label
.
@keyurparalkar @momcilo-appsmith should this be prioritized?
More generally the select widget is not consistent regarding label / value.
Let say I have a DB table car and a DB table color. Car has a FK to table color.
I want to create a table to edit cars. My table widget is populated with query:
SELECT id, brand, model, color_id FROM car;
with inline editing configured as https://app.appsmith.com/app/editable-table/cell-save-62d8f8d0e1c2ed505a0557cd.
In the color column I set the widget type to select.
I let value of properties Computed Value to {{currentRow.color_id}}
and set the Select properties options with data of this query:
SELECT id as value, name as label FROM color;
then here is current behavior:
- When displaying the table the column color shows the FK id. NOK Would expect to show the label of the color.
- When editing column color the dropdown shows the label values. This is OK
- When editing column color the value hold by currentRow.color is the id of the color. This is OK
- When editing column brand the value hold by currentRow.color is the id of the color. This is OK
Trying to solve this problem if I change Computed value property to display the color name with something like:
{{SelectColorQuery.data.find(color => color.value === currentRow["color_id"]).label}}
then I get the following behavior:
- When displaying the column color it shows the the label. This is OK
- When editing column color the dropdown shows the label values. This is OK
- When editing column color the value hold by currentRow.color is the id of the color. This is OK
- When editing column brand the value hold by currentRow.color is the color label. NOK
CC: @dilippitchika
Adding use case here: I wanted to have the user see the value on the column but when I access that column I wanted to get the ID of that column For example: User sees & selects employee name but when I access the column in code I get employee ID.
Adding use case here: I wanted to have the user see the value on the column but when I access that column I wanted to get the ID of that column For example: User sees & selects employee name but when I access the column in code I get employee ID.
Exactly the same scenario in my case. Would be very useful to be able to use the value, but see the label, just as it happens in the select widget.
This is a must-have feature in a fully normalized trasactional database: the ability to bind look-up data to fields that are dropdowns or multi-selects, where is displays the name/label on the front-end and saves the value (id) on the back-end.
This feature is a must have. I really don't want my users to see the values in the select field. This contacarates the idea of dropdown fields. Its like Enum without speaking values. Thanks for implementing this!
Thanks everyone for showing interest in this feature. We are currently working on introducing a new property to the table's select column which is displayAs
. With this property introduced, it will allow to do the following things:
- Setting
displayAs
to label, so that labels get displayed in each cell. Even while editing a cell, the option that will be selected from the drop down will indicate label. - When
displayAs
is label, select option's value property is going to get set in table data while editing the cell. - For the data that is present in each cell, we display them as follows for the select column type:
- When
displayAs
is set to label, we show empty values for missing labels in the widget - When
displayAs
is set to value, we show the computed value as it is even if labels are missing.
- When
- We expect that the computed value field represents the default value/display value.
- We expect that each computed value should be present in the select options.
Here is the Deploy preview link that you guys can try out: https://ce-26855.dp.appsmith.com/
Hello everyone, we are currently blocked on implementing the displayAs
property for select column type due to this bug. This bug is currently in implementation.
CC: @dilippitchika @Rishabh-Rathod
Hi, I'd like to know if there's been any development about this issue. The bug blocking it appears as completed. Like many noted, I also consider this feature a must, because it makes tables way more flexible. Thanks in advance for the implementation.
Hello @lau-st apologies, we haven't been able to prioritise this yet on our end. We will come back with an update soon.
Hey guys, this missing feature is blocking my project. :-(
Hi, I'd like to know if there's been any development about this issue. The bug blocking it appears as completed. Like many noted, I also consider this feature a must, because it makes tables way more flexible. Thanks in advance for the implementation.
Hi, I have the same question and issue as @lau-st and @oxamo @dilippitchika , is there any work planned on this topic? Thank you !
Another user asked for this feature.
Hi, For a relational database this is a must so that ids arent seen. Without this the table isnt useful for any edits. Thanks
Another user on Discord is facing this issue.
It limits the possibility to use table inline editing because now I need to provide a special form where and only where a user could add/edit values. Or consider using poor database design "label = value" but it can cause troubles in the future. It would be very nice of you if you make it possible to always display cells as labels, as well as in inline Select lists, but write values. https://discord.com/channels/725602949748752515/725609493974614076/1240548925539225621
Do we need to work on this issue? can we have the exact steps to reproduce the issue along with screenshots or a loom video ?
Please do work on it. What is not clear to you?
As a workaround solution:
- Hide the "value" column in the table.
- Set the "label" column type as Select.
- Set the column's Options source as the needed value-label object.
- In the update query refer to the "label" column as the new value (instead of the "value" column, which is the intuitive way). Further is business-as-usual.
Yes that work around works though it is a work around, it is not so intuitive and I believe this is a basic feature that should work for select widget. Actually it works for select widget outside of datatable I think.
In my understanding, this is linked to #26855 which is closed by now.
In #26855 , there was the following request:
is this PR ready for productive deployment and can it be merged into release? Can you please launch that process to close #21993 and #26188 ?
Could you maybe review that PR if it is suitable to close this issue ?
I don't feel comfortable enough to implement myself this fix I think.
Could you maybe review that PR if it is suitable to close this issue ?
I don't feel comfortable enough to implement myself this fix I think.
Sorry @benjamindonze , I did not mean you. I meant to ask if this PR could be included into the main software branch, e.g. by @daaliachhak17 .
Thanks it seems indeed now the behavior is what would be expected. Though I will have to fix all the workaround I was making by displaying a computed value beeing the label value which now doesn't work anymore my column displayed empty as the widget expect to find the value and not the label.
Just so you know this means this is not backward compatible with previous behavior
@jacquesikot Ah also it seems the search bar of the datatable now doesn't work with that solution. Indeed search seems to be applied on the value field though it should also search on the label field
I have opened an issue : #35406