Goal: Hello!! I am developing an application in Retool where I need to pre-fill fields with data obtained from an endpoint. Users can edit these fields and then save the changes by sending an updated request. One of the fields is "colors", where users can add new colors but cannot remove the existing ones. To make this intuitive, I separated this into two multiselect inputs: one that shows the current colors and is disabled, and another that allows selecting new colors, excluding the already selected ones.
Steps:
I create a request to an endpoint to obtain data and pre-fill the fields.
I set up two multiselect inputs for the "colors" field:
The first shows the current colors and is disabled.
The second is empty by default and shows all options, but disables the ones already selected in the first multiselect.
I configure a script that updates a variable with the modified information each time the fields change.
Users with edit permissions can select new colors without any issues.
Users with permissions to only use the application face issues when trying to select new colors; the options initially select but then immediately deselect.
Details:
I am using two multiselect components to manage the "colors" field.
The first multiselect is disabled and shows the already selected colors.
The second multiselect allows selecting new colors, excluding the ones already selected.
A script runs every time a field is modified, updating a variable with the updated data.
The issue occurs for users with limited permissions to use the application; they cannot select new options in the second multiselect. When they try to select an option, it initially selects but then immediately deselects.
I have consulted the Retool documentation but have not found a specific solution to this issue.
Very interesting issue, I haven't seen anything like this before It seems like you set up the component logic correctly. Very odd that the permission difference prevents it from working as intended.
My first guess would be that there might be something in your step "I configure a script that updates a variable with the modified information each time the fields change" where the application sees the users inputs to the second select component as editing the app and prevents this any chance you can share a screen shot of that script?
My other guess would be potentially to use another component, but I think it might hit the same issue.
Could you export your app via JSON and share that with me? So I can clone the application and test it out, thank you!
Also if you could share a video of the behavior with editor permissions and with the use only permissions? That would help a ton.
Thank you for the quick response! To clarify, I have a variable called updateVariationsList, which is an array where each element represents a product containing properties like year, colors, etc.
In the script, I update this variable when the colors input changes. Specifically, I:
Retrieve the actual colors of the modified product using the index i.
I think your suggestion about the permissions affecting how the application handles inputs might be correct. Could it be that the action of updating updateVariationsList is being blocked or restricted for users with limited permissions? I’m happy to provide a video of the behavior and export the app JSON if needed.
Thank you for the clarification and additional details!
The fact that the bug occurs when users with different permission levels try to use the UI makes me suspect that could be the issue.
If the users are not allowed to use the query/resource that updates the database with the form data then that could explain why it works fine for some users but not others.
Although, the changing of a variable such as updateVariationsList should not be something that permissions would limit.
We might need to help you with some live debugging during our office hours, as that will make it easier to see the behavior and test out different options for setting up the variable logic to properly take user input, add the input to the array of colors and then save this data via a Query to your database.
Looking at the last line of updateVariationsList.setValue(updateVariationsList.value); I feel like this is not the best practice, as you are setting a variable to be its own value
Another option would be re-working the logic:
Form displays a list of colors currently applied to the item (from an array you query from DB)
Form takes an array of all colors, uses the .filter() method to eliminate colors for the allColors array if they are found in the item.currentColors array you got from the database
A multi-select in the Form displays the colors array AFTER it has been filtered and users can select from any colors not already being applied in the locked list of already applied colors
After the user selects colors from the available options multi-select, a Query will run, were you combine the 'already' colors array with the 'new to add' colors array and insert the combined array of colors into your database to save.
This logic might work better, try testing it out in another app so you don't have to start from scratch we can take a look at the restricted behavior of different permission users during office hours and see if there is an easy tweak we can make. With the logic re-work as a backup if we can't fix the bug!