Edit Variables values manually in interface

[bbbco]

• Insomnia Version: 6.0.2
• Operating System: Linux Mint 19

Details

I'd like to arbitrarily modify/edit the values of variables when I use them inside the interface. Currently, if I want to modify them, I have to do so inside the manage environments section. However, if I click on the variable inside the interface, it shows an "Edit Variable" dialog with a read-only text field of the current value. I'd like to be able to modify this value. Of course, I understand that when you consider sub-environments, the question come up, where should the new value be applied to (base env, or one of the sub envs?). I imagine another option would be made available in the dialog allowing the user to choose what to do.

[soderluk]

I have thought about the same thing. I have different ID's that I want to use as the {{ id }} field, and whenever I create a new item in the db, I'd like to edit the new ID in the next GET /read/{{ id }} request that I'm going to use. Now the edit variable popup doesn't really do what it says, but it gives the option to change a variable.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bbbco]

Bump. Any traction on this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soderluk]

This would be a good feature, anyone taking this up?

[natebrunette]

This would be great. I would assume it would edit whichever value it's pulling from. So in the case of sub-environments, it would modify the sub-environment if the variable exists, otherwise the base.

[spider4216]

I wanted to create feature request to offer possibility to edit variables in modal dialog and suddenly found that other users have already created this issue. For me this feature will be very useful. Edit variable in modal dialog will be able to make manage variables function more friendly and conveniently

[nkl90]

This is a very useful feature, please add it!

[KennethWussmann]

@bbbco I would like to implement this feature.

But I could need some guidance from a contributor 😃
I couldn't find a clean way of getting the environment id of the variable being edited in the VariableEditor.
Only the name of the environment which is not unique.
Thanks.

[gschier]

There is a map of environment names generated here:

https://github.com/getinsomnia/insomnia/blob/bba03d0eab34e29ec4f9fdb2d6dca4f82ddc1225/packages/insomnia-app/app/common/render.js#L217-L241

There are some problems with it though, like it does not work with nested variables (#1288). We can likely ignore this one for now and just not show the ability to edit if we cannot infer the environment.

Here's a suggestion for how you might go about it:

1. Modify the keySource map to include both name and id.
2. In the variable editor component, add another field for the variable's pre-rendered value
3. Provide a <PromptButton> beside the new field to rename the value in it's environment
4. Show a confirmation dialog to the user to make it clear which environment is being modified
5. Make the modifications

In my opinion, step 5 is the scary part. It would be very easy for a bug to accidentally wipe out a user's environment.

Let me know what you think!

[gschier]

Also, as usual, don't worry about the UI/UX too much if you don't want to. If you can put together a barebones UI, I can tweak things after.

[KennethWussmann]

Hey! Thanks for the suggestions.

Okay I can add the id to the keySource, but it will always only be possible to edit root-level variables like:

{
  "USER_ID": "123"
}

and not something like:

{
  "PARAM": {
    "USER_ID": "123"
  }
}

Because the keySource only holds the root-level variables with the corresponding environment:
https://github.com/getinsomnia/insomnia/blob/bba03d0eab34e29ec4f9fdb2d6dca4f82ddc1225/packages/insomnia-app/app/common/render.js#L222
Would be fine for me, but maybe contradictory for the user that he can edit the values for {{ USER_ID }} but not for {{ PARAM.USER_ID }}.

I think nested variables might not be that big of a problem, when the field to edit a variable value is completely un-rendered and just contains plain {{VARIABLE}} expressions:

Actually, I don't know where the confirmation dialog should go. I think the Edit Variable modal is fairly easy to understand and the environment that's being edited is written right above the input field. Maybe it should say something like Save instead of Done and with a Cancel button (on the left). So, only pressing Save would override something in the environment.

Modification should not break something, because only root-level entries of the JSON can be edited and not sub-objects. Or are you scared of something I'm not aware of?

[gschier]

Ya, I wouldn't worry about nested variables for now.

I hesitate having a cancel/save button where the Done button is because all other dialogs (eg. environment editor) saves as you type. Having this one work differently would likely be confusing even though it makes sense in isolation.

What about something like having the save button inline with where you change the value? We might not actually need a confirmation dialog to start either. We could always add it later if needed.

Modification should not break something, because only root-level entries of the JSON can be edited and not sub-objects. Or are you scared of something I'm not aware of?

It's just a general worry. Data loss is the worst thing that can possibly happen in an app and even a slight chance of messing something up should be taken with great caution. Proper unit tests should be able to ensure this doesn't happen 👍

[alexsimpson440dev]

Anymore traction on this?

[bbbco]

indeed ... how is this feature looking?

[rafaelchampion]

Any news on this?

[claudioluciano]

Any news on this?

[subnetmarco]

I want to address this feature request in the near future, I started a thread in this other conversation: #3551 (comment)