Export/import is implemented as backup/restore and causes loss of data

[gh-andre]

Expected Behavior

When the user clicks the Import from File button that is placed contextually in an empty collection, or, likewise, when the user navigates to a collection Import/Export menu selection and selects Import Data / From File, this implies that data will be imported into the collection in the current context.

Furthermore, while importing, it's reasonable to expect that Insomnia would warn the user that the data being imported may overwrite parts of the existing collection and whether the user wants to do that, leave new data alone or just abort the import and sort it out manually before attempting another import.

Actual Behavior

The import functionality in most applications out there implies that some external data will be brought into the application or a different application area and adapted for the importing application or that area.

Insomnia implements Export/Import as if it's a Backup/Restore and ignores contextually-placed import buttons and menus and uses various identifiers saved in the imported file to read data into the original collection. So, from the context, it appears that even though the pop-up said import was successful, nothing was imported.

Behind the scenes, Insomnia reads data into the original collection without any regard to any modifications of that collection and silently wipes out existing data. Given that Insomnia follows the new trend of eliminating explicit load/save functionality, there is absolutely no way to preserve that lost data. It's just gone.

Reproduction Steps

• Create a test request collection ABC. Don't use any actual collections.
• Add a couple of requests.
• Export ABC as v4 YAML.
• Rename ABC to XYZ in collection settings and edit collection description.
• Create an empty collection EMPTY
• Within EMPTY, click Import from File and select exported YAML for ABC.
• A pop-up is presented that the file was imported successfully and gives some stats.
• The collection EMPTY remains empty, as if the import fails.
• Switch to the dashboard.
• XYZ was reverted to ABC by import and the new description and all request modifications are gone.

Is there an existing issue for this?

• [X] I have searched the issue tracker for this problem.

Additional Information

There's a recent issue for this and I apologize for creating this one, but I wanted to provide more context. If you want to close this one as a duplicate, I understand. Here it is:

https://github.com/Kong/insomnia/issues/4246

This issue was created as a result of this discussion with @develohpanda:

https://github.com/Kong/insomnia/issues/4034#issuecomment-988302605

The least Insomnia can do is to compare time stamps and warn the user that the collection that is being restored from exported data has been modified after it was exported. This won't cost much development, but will give people a chance to learn that their data is about to be overwritten.

If you choose to keep current functionality, I suggest to rename it to Backup/Restore because it doesn't have much to do with Export/Import. If you choose to keep Export/Import, which would be desirable, imported data should be adapted for the collection into which it is being imported. This should include importing into other areas, such as importing into the Debug collection of a design document.

Insomnia Version

2021.6.0

What operating system are you using?

Windows

Operating System Version

Windows 10 Pro Version 21H2 build 19044.1387

Installation method

website download

Last Known Working Insomnia version

No response

[erwinw]

Completely agree. Trying to get a local collection into one shared with the team (you know, after paying money to start using the product with a team) has been a vale of tears. The only way I finally managed is by manually editing the "exported" original file and changing the IDs in there. A real pain :-(

[cwilper]

Thanks @erwinw for the suggested workaround to divorce the export's ids with the originals.

I wrote this to do it with sed and jq, by prepending all original ids with zeroes in the export.

cat export.json | jq . \
  | sed 's|"_id": "\(...\)_|"_id": "\1_0|g' \
  | sed 's|"id": "pair_|"id": "pair_0|g' \
  | sed 's|"parentId": "\(...\)_|"parentId": "\1_0|g' > fixed-export.json

[gh-andre]

This is a copy of my comment from issue #4274, just to add to the workaround above.

For those who just want to move collections/documents between projects, there's another way.

• Create an empty target project
• Go to the source project
• Click triple dots in the collection/document you want to move and click Duplicate
• Change the name to your liking, select the target project and click Duplicate

This copies collections/documents/environments to the target project. Check that the copy is good and delete the original from the source project.

I also find this hack useful for committing exported YAML into the repository - duplicating collections/documents to a transient project before exporting what goes into the repository helps with subsequent check-out/import because it won't overwrite the original collection.

[nreavesHRC]

I just encounter this issue as well. At the very least a rollback feature would be helpful to avoid loss of data when importing from file.