[Feature-Request] request-level environment variables

[lrotermund]

Hi, is it possible to specify variables for the URL at the level of a request environment? We would like to start using Bruno in the team, if we customize IDs in REST URIs, which is the rule, then they should not be updated in the .bru, but rather be quickly replaceable as request-level environment variables.

Sorry if this already exists in the documentation or as an issue, I searched both for a long time but found nothing specific.

Edit, 2023-11-10:
As I haven't heard anything about this, I assume it doesn't exist yet, so I've turned it into a feature request.

What does not work at the moment?
=> Quick and easy management of environment variables at the request level, without writing them to a .bru file.

How might this feature be implemented?

• Handle request level environment variables like normal variables, i.e. simply using {{var_name}}
• Request-level environment variables override global variables.
• They could be placed in the Vars tab like pre- and post-request variables.
• Unlike pre- and post-request variables, they are not synchronised in the .bru file, but behave like global secret environment variables.

Unfortunately I only have a basic knowledge of Electron, I work more in the Go & PHP backend. If I have the time, I can try to submit a merge request, but I doubt it will be implemented correctly or "nicely". Maybe someone else here has more skills than me.

Here is a screenshot that perhaps shows better what I mean by the request-level environment variable:

[David-Lannion]

This issue seems quite related with #292

[helloanoop]

Request Variables implementation has been updated in Bruno.

They are scoped to be access only within the context of the specific request.

When a variable is accessed, the following precedence is used to determine which value is used:

• Collection Variables
• Environment Variables
• Folder Variables
• Request Variables
• Runtime Variables

Runtime variables get the highest precedence.

We’re closing this issue, but feel free to reopen it if you have further feedback on this behavior.