Preserve request chaining when duplicating or importing workspaces

[Rcuz8]

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?

• 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

[PedroLuisBrilhadori]

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

[rezamanshouri]

Any updates here?

Issue 5942 referenced above is still a pain when needing to share collections (export/import).

[Stratum-Jeremy]

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.

[PedroLuisBrilhadori]

@Stratum-Jeremy

When you export a collection that you export yourself, the IDs exist in the local database and therefore work perfectly.

Test:

1. export collection,
2. delete old collection,
3. import.
   This way the error will occur

[efeevren]

This bug is blocking to work with team, every member tries to fix same problem sometimes success sometimes failure. We choose to change tool.

[bwaidelich]

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?

[Yocker95k]

Yes, this is a big problem for collaborative work. We will change the tool if this is not fixed soon.

[UnicodeTreason]

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.