Importing Flows causes ui-base clash

[joepavitt]

Description

If I import flows from one Node-RED Editor to another, both containing Dashboard 2.0, then we get multiple instances of ui-base, which in turn results in our HTTP Server trying to run multiple Dashboard's on the same endpoint.

We need a way of ensuring that we only have one running ui-base node in Node-RED when imports take place.

Challenges:

• What do we do with any ui-group and ui-page config nodes that are mapped to the ui-base we would no longer use?
• Do we just delete the ui-base that we aren't using? What are the consequences of this?
• We may also end up with multiple ui-page instances clashing on their respective URLs too, for example, if only one ui-page existed in each Dashboard instance, then they're likely both using the default / endpoint

Epic/Story

No response

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[joepavitt]

The difference between D2.0 and D1.0 in this instance is that ui-page has an option for ui-base, where it then becomes possible to create more than one. Similarly, the configuration for UI Base is done by the user in Dashboard 2.0, so can result in different config options (e.g. name).

In Dashboard 1.0, this ui-base node is automatically created, and maintained by D1.0 logic, not by the user, so it doesn't clash as it's consistent across all instances of Dashboard 1.0

[joepavitt]

Also, our registration is all managed through ui-base, whereas in Dashboard 1.0, they have a standalone service for this.

[joepavitt]

A short term iteration on this is that we fail "cleanly" - currently we still have the horrible blue screen is a user tries to navigate to a non-existent Dashboard (whether that's due to failure to deploy, or from lack of configuration/setup)