Improvements for Full Imports

[arikorn]

Is this a feature relevant to companion itself, and not a specific module?

• [x] I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• [x] I have searched for similiar existing issues

Describe the feature

The main purpose of this issue is to consolidate and/or expand upon some issues with "Full Import" (mostly discussed in the recently merged PR #3708) with a goal of making sure I address them all in a future PR or two! Note that although these are largely motivated by the newer partial-reset functionality, it affects full reset functionality as well.

1. Allow the user to select connections. Currently connections must be imported with a full import whether-or-not a full reset is being performed (and despite the fact that a user could create an export file with no connections in it, which is effectively the same as the ability to deselect connections here.) The problem is that clearing the current connections before importing them will delete all of the module-related actions in all pages & triggers. To avoid this unwanted effect when using partial reset, Companion will not import any connections (or connection collections) that are currently in the active configuration/database

   Proposed solution part 1a: warn the user if they select pages or triggers but not connections (this is already done in the "Reset Configuration" button workflow.) ...or pages but not variables & triggers?... etc. A more advanced method might scan the pages and triggers to see if they reference connections... (@Julusian wrote: "Showing that an import will leave broken references may not be too bad to do actually, the challenge becomes how to show that in the ui, and how to help them fix it.")

   Proposed solution part 1b: When loading connections with partial reset, use the "merge" functionality from the single-page import flow (aka Buttons tab). Note that if the user is importing all of connections, pages, expression variables and triggers, (or if they contain no module-references) there is no need to request merge preferences.

2. Address internal object mismatches currently the database, import file and WebUI options each have different fields or different field names for the various components. This can make changing the code more brittle. (In particular in importFull we use three variables: config, data, and resetArgs with possibly overlapping function) Separately, perhaps data should be reorganized to keep collections with their components? @Julusian writes "The intention being to make it a more explicit multi-step transform so that the final step of performing the import isn't trying to match stuff up across 2/3 objects, but can just look at the one."

   Potential solution to issue 2: Perhaps write a "matching function" that resides in "ImportExport.ts" so it lives together with the "mismatched" objects. The function could also do some basic validation to ensure no new fields have been added (assertNever??)...

3. Import/Export should save data from the Settings tab (user-config). This is covered elsewhere (see PR #3538, for example) but mentioned here for completeness and because it needs to get done.

(Note: all of this should be compatible with, and perhaps the first step, in Julian's Import/Export workflows overhaul plans.)

Usecases

No response