Allow basic widget ordering of widgets in a subflow

[Steve-Mcl]

NOTE

This PR merges into an earlier fix branch so to minimise review confusion, the simple fix in PR #1758 whould be reviewed and merged first.

Description

Allow user to manually enter sorting order when a widget is in a subflow (similar to how width and height are handled)

Screenshot examples:

Number

Chart

Other Nodes

They all follow same pattern

Related Issue(s)

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

• Includes a DB migration? -> add the area:migration label

[colinl]

Is this to allow ordering of widgets within the subflow or within the group?

[joepavitt]

It will allow any nodes, that are used in a subflow, to have their order set, which defines their position in their assigned group, even after being added to a subflow

[colinl]

So does that mean that if a subflow contains multiple widgets that the widgets will not have to be adjacent in the group? Currently the subflow itself appears as a single entity in the dashboard panel. Is that going to disappear?

Also does this mean that if a group contains a number of subflows and a widget is added at the start, that all the widgets in following subflows would have to be manually incremented or will node-red do that automatically?

[joepavitt]

So does that mean that if a subflow contains multiple widgets that the widgets will not have to be adjacent in the group?

Not sure yet, I haven't dove into the PR to experiment.

Also does this mean that if a group contains a number of subflows and a widget is added at the start, that all the widgets in following subflows would have to be manually incremented or will node-red do that automatically?

Manually required.

[joepavitt]

Working excellently

[colinl]

I am trying to work out how one would use this feature. If I have a group with a number of widgets in it, and a subflow with some widgets, and I and I want to position the subflow widgets between to existing widgets, how would I know what numbers to use for the order, and would the code automatically move all the later widgets down?

Also does this have an impact on third party ui nodes?

[joepavitt]

and a subflow with some widgets, and I and I want to position the subflow widgets between to existing widgets, how would I know what numbers to use for the order, and would the code automatically move all the later widgets down?

This only impacts the ordering within the subflow. There is an issue currently, once a node moves inside a subflow, the order of those widgets (within the subflow) cannot be changed. This PR resolves that.

[joepavitt]

Also does this have an impact on third party ui nodes?

I believe the same logic applied to the core nodes would also need to be applied to third-party nodes, within their own code bases. Although @Steve-Mcl can confirm.

[colinl]

This only impacts the ordering within the subflow

I asked that earlier and the answer was

It will allow any nodes, that are used in a subflow, to have their order set, which defines their position in their assigned group, even after being added to a subflow

That appears to say that the order is the order in the group, not in the subflow. Perhaps the question I asked then was unclear.

WRT third party nodes have you checked for unforeseen consequences if a third party node is included in a subflow?

[joepavitt]

That appears to say that the order is the order in the group, not in the subflow. Perhaps the question I asked then was unclear.

That was my mistake. Upon review, it just controls the order within the subflow, which I think makes more sense. The ordering of that subflow is still then possible via the right-side ordering tooling.

WRT third party nodes have you checked for unforeseen consequences if a third party node is included in a subflow?

There is no change for third-party nodes vs. how they operate now.

[colinl]

OK, I will try to test it out, if I can find a few minutes.