🚫 Removing Collection Presets in v3 release #6234
Replies: 11 comments 7 replies
-
|
Actually, I find this feature quite useful and I cannot really see a reason to remove it, so I want to give some of my thoughts about this change.
I don't quite understand what's confusing about the collection-level preset tab, especially because there is a explanation text that describes it purpose kind of unambiguously. And I mean, even if there is a majority of users that misunderstands the purpose of the tab, wouldn't it be better to just rename the tab or make the explanation text more noticeable instead of removing the feature completely?
That sounds interesting, but I am unsure whether that's more intuitive, though. I mean, the main purpose of a preset is to automatically fill in the base url of the used API, which should be collection-specific in most cases, as you probably won't use the same base url for every collection. So I don't really see why the feature should be on app-level, as the only feasible reason for using an app-level preset would be to fill in some variable like Maybe I misunderstood the points you made or I am the only one who thinks like this, but just wanted to give some thoughts to that. If I misunderstood something or you want to address my points, feel free to correct me. :) |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't even aware of this feature, but now that I am, it is something I would use if it wasn't going away. |
Beta Was this translation helpful? Give feedback.
-
|
Make it optional instead of removing causes least confusion. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
One way to preserve the functionality but still dep the feature would be to have a |
Beta Was this translation helpful? Give feedback.
-
|
I make extensive use of this for similar purposes to @zFlxw, where different collections are used for different purposes. For instance, Azure API calls do not have the same root as the vendor APIs for our largest vendor, which is different as well from any of the many others we also use. It makes creating new requests far faster versus merely copying/pasting. And said largest vendor uses the same URLs for test AND production with the API key determining which one is accessed. A useful option could be to allow us to set a URL prefix on collection or folder levels, so a folder overrides or extends one, but I think the preset shouldn't go away even with that. On a similar note, I think it'd be helpful to have pre-execution scripts parsed/processed for generating code, as I found examples where a collection-level pre-script was rewriting the URL to include the base so each request only had the URL of |
Beta Was this translation helpful? Give feedback.
-
|
By "app level" is this a reference to a global preset or a reference to environments? I similarly want a way of having a base url that isn't the same across all my collections, but I usually use an environment for this which has the advantage of letting me change between sandbox, preprod, and dev urls pretty quickly, however there are variables that make sense to be part of the collection themselves. Example being we have a "date" field for several calls and its nice that we can set a default for this in the collection to something like January 1, 2010 and allow users to override that in the calls. We don't necessarily want to store that default in the environments because its not part of the environment and storing the defaults in every call is more difficult than having the collection default. Would the idea going forward be to use the Collection -> Vars tab? It seems to accomplish the same thing that presets do anyway but I am not sure if there are other differences between these that make them incompatible |
Beta Was this translation helpful? Give feedback.
-
|
We also make extensive use of the “Presets” feature. Each collection has its own “Base URL.” For the most part, this is a variable that is then specified in more detail in the environment. It would be a great shame if this feature were to be removed, especially since it already exists. |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand why this should be removed. We use this feature in every collection for the BaseURL. The feature should be extended to also allow setting the default HTTP-Method. |
Beta Was this translation helpful? Give feedback.
-
|
@helloanoop Is there any discussion on reversing this decision as with the other change that was proposed and cancelled? |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone, Thanks for all of your feedback. We have decided to revert our decision and not to remove this feature :) |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
In the upcoming v3 release of Bruno, we plan to remove Collection Presets.
❓ What Are Collection Presets?
Collection presets define default values applied when creating new requests within a collection. Currently, we support two types:
💡 Why Are We Deprecating This Feature?
They Are Confusing for Most Users
🔄 Migration Path
No action is required.
This change affects only a UX-level configuration that was used to pre-populate fields when creating a new request. Removing Collection Presets does not impact any existing requests or runtime behavior. Everything will continue to work as before.
📅 Deprecation Timeline
Beta Was this translation helpful? Give feedback.
All reactions