insomnia
insomnia copied to clipboard
Preserve request chaining when duplicating or importing workspaces
Expected Behavior
Let's say you have a folder A of chained requests.
/A
- r1
- r2 (depends on r1 response)
When you duplicate that folder (creating new folder B
), the chained links should update properly:
/A
- r1
- r2 (depends on r1 response)
/B
- r1
- r2 (depends on B/r1 response)
Actual Behavior
/A
- r1
- r2 (depends on r1 response)
When you duplicate that folder (creating new folder B
), the chained links don't update properly:
/A
- r1
- r2 (depends on r1 response)
/B
- r1
- r2 (depends on A/r1 response) <---- should depend on B/r1 response)
Reproduction Steps
Create a folder with 2 requests. The second request should have a variable that depends on the first response body. Duplicate it.
Is there an existing issue for this?
- [X] I have searched the issue tracker for this problem.
Additional Information
No response
Insomnia Version
2022.7.5
What operating system are you using?
macOS
Operating System Version
12.6
Installation method
Download from Insomnia site
Last Known Working Insomnia version
No response
This problem also affects environmental variables
/A
- r1
- r2 (depends on r1 response)
- env (depends on r2 response id)
/B
- r1
- r2 (depends on A/r1 response) <---- should depend on B/r1 response)
- env (depends on A/r2 response id)
The ids are globally unique, would it be possible to change this for each document?
In document A r1 has the id x
In document B r1 has the id y.
A possible solution would be for the requests and properties of the document to be unique only within it.
With this we can have more than one request with the same ID, but not in the same document
Any updates here?
Issue 5942
referenced above is still a pain when needing to share collections (export/import).
I have the same issue but noticed something strange.
If I export a collection and import it as a new collection on the same Insomnia instance I exported it, the reference IDs are maintained. However when I send the export file to a coworker and they import the collection the reference IDs are reassigned and the tags break.
@Stratum-Jeremy
When you export a collection that you export yourself, the IDs exist in the local database and therefore work perfectly.
Test:
- export collection,
- delete old collection,
- import. This way the error will occur
This bug is blocking to work with team, every member tries to fix same problem sometimes success sometimes failure. We choose to change tool.
This issue has been reported multiple times and there is a PR for it. Can someone give an update what is required for this to proceed?
Yes, this is a big problem for collaborative work. We will change the tool if this is not fixed soon.
Started trying to share Collections with team mates today and hit this issue, is there an ETA on resolution? Really kills the usefulness of the app if a junior can't import an API Collection to see how an API works.
Any chance to have this thing fixed? It's impossible to share collections
Any updates here? It's impossible to share collections
Switching software, this won't work.