The option to lock node positions in the designer

Core Development Feature Requests
1

I hate it when I accidentally shift something out of place. So have a setting to lock the nodes in place. The only way to move them would be when you place a new one from the palette. Or by holding down the ctrl key while clicking and dragging to move a node and have it snap to grid or hold shift and drag to move one to not snap to grid.

Just my thoughts.

Regards,

2

ctrl-z will undo the move for you of course...

3

There is already a snap-to-grid option in the view settings dialog.

4

I know that. The holding ctrl or shift is ancillary to the main locking idea.

5

I like this proposal except for the idea that a setting would lock all node positions at once. Instead, it would be nice to be able to select one or more nodes and use a keyboard shortcut to lock or unlock the positions of just those nodes. Probably a lot of programming effort for a small benefit, but something possibly worth considering if a major overhaul of the flow editor is in the works.

6

I'm not sure how they've done it under the hood, but I'd imagine that you'd just need to add one more meta property to the node objects and an extra if ... and (is !locked) to the click and drag event. If I were a better programmer, I'd try it myself. I just might anyways, but the results won't be pretty.

7

To throw in my own unprompted input: Perhaps this could be further augmented by allowing nodes to be given a "parent" node to which they are anchored and the ability to lock a node to a relative position to the parent. This would be downright amazing if used in conjunction with comment nodes. (My mental image is of a comment node being used to label a functional group and also serve as the handle to drag it around by.)

8

@JayDickson This sounds a lot like a suggestion I made a couple of years ago, https://groups.google.com/forum/#!topic/node-red/_qn6mwHFX9g. At the time there seemed to be an interest in improving the (self-) documentation of flows, but not in that particular approach.

9

Dave and I talked through this idea a bit today over a coffee. It has come up a handful of times and there are certainly use interesting use cases for it.

But of course, the devil is in the details and there are a wide range of uses cases to consider.

Here's what we came up with as a starter for the approach. I will say up front, this doesn't mean we'll drop what we're working on to deliver this. But having a thought through design is the first step to it happening at some point in the future.

This is focused on the user experience of the feature rather than any specifics of how it would be implemented.

  1. A node that is 'locked' cannot be moved.
    • if you select multiple nodes including a locked one, the selection cannot be moved
    • if a locked node is imported, it can be moved during the initial import, but once placed, it cannot move
  2. Double-clicking on the node will open its edit dialog, but the Done button is unavailable.
    • this allows a user to examine a node's configuration but not change it
    • somewhere in the edit dialog is a toggle to lock/unlock the node. Unlocking the node will enable the Done button. If the node is then relocked, the Done button remains active to save any changes.
  3. A Flow can be locked.
    • this will lock all nodes in the flow and the flow's properties.
    • double-clicking on a node in a locked flow will open its edit dialog, with the Done button unavailable
    • the dialog will not provide an unlock option - that must be done at the flow level

Some open questions:

  1. can a locked node be copy/pasted?
  2. can a locked node be exported?
  3. should a node have any visual indication that its locked?
    • Maybe something that only appears when the node is selected (similar to the Link node behaviour)
  4. should there be a keyboard-click combo that allows a locked node to be moved?

Some other half-baked thoughts:

  1. should there be a specific 'unlock-nodes' (name very much tbd) permission - this would allow for a setup where one user (lets call them, Teacher) can setup some flows with missing pieces, and another user (lets call them Student) can fill in those missing parts without being able to modify the existing parts.
10

all these suggestions look great !
Open questions:
1- yes, a locked node should be copiable
2- yes, a locked node should be exportable
3- yes, either a small lock icon as a badge or a different color/style for the stroke
4- yes

Unlock-nodes permission: this seem like a good idea as well !

:smiley:

11

Wow! This has taken on a life of its own (like NR :slightly_smiling_face:). The original idea was just to lock the position of a node in the editor window. Locking the configuration dialog and other features opens up a lot of possibilities. :+1:

12

If a flow can be locked, and that locks the properties, should that also apply to the debug state?
I can see where in a lesson you might want to start with a locked flow, but still be able to toggle debug nodes on and off.

13

Similarly whether a locked Inject node can be triggered or not....

How about...

  1. a locked debug node can be toggled, but doing so doesn't change the node's config in the editor - ie you can't persist that change.
  2. a locked inject node can be triggered
1 Like
14

Please keep those little things as intuitive for user as possible. This kind of hidden treasures are cool only if they dont harm the main purpose of editor - being supportive for users to bring their ideas to real life.
I think the locking by group might be useful if there is option to unlock things with one click procedure. By struggle with lock here and other lock somewhere else will be just losing the focus from main thing - to create your desired solution. :wink:

15

Absolutely. I don't see 'regular' users as the main audience for this feature, so it needs to be unobtrusive.

16

I was just envisioning the locking mechanism as a way to prevent accidental modification, not as a security feature.

17

If I import a flow (say from flows.nodered.org) and someone has locked several of the nodes... I would then have to go round unlocking them all before I could do something... uurgh. But then in the teacher/pupil scenario you wouldn't want unlocking... but how can teacher A share with teacher B.

Dare I say... what about subflows... I guess things "locked" inside subflows would have no effect out side the subflow.

18

Yup - that's understood. But as you can see, there are other use-cases for us to consider!

19

Anotehr thing to think about, would/should you be able to add a wire to the input or output of a locked node/flows?

20

Ah yes.... Forgot to cover that.

  1. A locked node may have wires added or removed,
  2. A possible exception: a wire joining two locked nodes may not be deleted

We are not going to introduce locking of individual wires - the flow file format does not support wire properties and this won't be the feature that leads us to change that.