Allow overriding debug node defaults (e.g. "Also send to console") via settings.js

[gregorius]

@dceejay

almost in violent agreement

Just as clarification:

• the concept of "alias nodes" is something I think would be good for the project. Why? because alias nodes are like the "alias" command in linux/unix, ie. it's easily understood and transportable.

• no, the current solution isn't the one I think should be implemented, i.e. an introspective flow that modifies the internals of the editor isn't easily understood. And by extension, folks passing flows around to create alias nodes ... no no, that's not the correct approach

• yes, there should be an frontend API for defining alias nodes, something like RED.nodes.registry.addAliasNode("debug to console", { console: true }, RED.nodes.registry.getNodeType("debug")) so that it's clear how to define alias nodes

• no, I don't care whether any of this happens but just as the flow visualisation in the forum took 1.5 years, I can still have a dream!

• yes, I would create the PR for the API if there is a clear "yes we like this but call the API xyz", i.e., RED.nodes.registry.addAliasNode.

• yes, I definitely think that visually having a new node (instead of replacing the existing node) is a simpler concept for an end user to understand and work with. Remember: it won't just be the debug node ... then the switch node ... the link node .... etc. So a general solution will be needed anyway.

[dceejay]

Well yes - not sure linux alias is that well know outside of command line world...

And I'm really not sure that adding another node is any simpler to understand than adding a line to settings.js to change an existing one... as we do already for setting timeouts etc,

but ... let's see what other thoughts there are out there.

[gregorius]

Ah you can’t have it both ways - alias concept unknown but comfortable modifying a settings.js file using a text editor on a server.

Who is the target user? I see replacing default values something that non-terminal users should be able to perform without asking an admin user, i.e just as the alias command requires no admin rights.

[knolleary]

To be super clear - defaults get applied when the node is dragged into the workspace. From then on, its configuration gets edited normally. The discussion is how to change the default that gets applied. If the user changes the default override in the settings file, it would only apply to newly added nodes from that point on - it doesn't retrospectively change anything.

An approach that allows defaults to be overridden via the settings file addresses the immediate need and doesn't introduce lots of new concepts into the Node-RED sphere. That makes it far easier to just get done, but doesn't stop any future discussion around alias nodes or whatever the in-editor approach could be.

[TotallyInformation]

@dceejay

Yes - but no... the server side can see all the settings - but only some are passed through to the client/editor side - which is where the defaults for a new node are generally set when you drag on a node - so need to be overridden there... I think... happy to be wrong..

OK, reasonable point. You can, of course, pass the settings through in the registration but that does require more boilerplate code for sure.

Even so, a standard set in advance of any core code changes might still be helpful.

@dceejay

a separate key area in settings.js

Certainly reasonable, for sure. Might need some thought as to how that works in conjunction with nodes that already have settings under a different property. Both Dashboard and UIBUILDER do and I'm sure some others. Feels like it should be OK but it would be good to get a few people to think things through.

Also worth thinking about clashing node names in different packages. We know this happens occasionally. Obviously you can't have both packages installed at the same time but some people may want to switch between such packages - would it be an issue given that they will likely have different settings? That's why I mentioned having an outer property for the npm name.

@gregorius

So the old or original default values are replaced?

Surely not "old" ones since they will have been deployed and so should have values saved? It would surely only apply to new nodes added to a flow?

Though thinking about it, is it possible that some nodes don't save values on deploy and always rely on defaults if a user hasn't changed them? I don't think so, but I've never thought to test that. OK, Nick has answered that one.

@dceejay

so ideally they don't want the "old default" option... so an alias wouldn't suit them.
(and I'm not trying to stop your alias's working - in theory we could have changed defaults and/or alias's on top if there was a reason to - eg a 3rd party node author declined to implement.

It is possible to remove nodes though via settings.js isn't it? So, in theory, an admin could control that. Not especially nice though. I prefer your idea.

@dceejay

not sure linux alias is that well know outside of command line world

Available in PowerShell as well. Aliases in that sense are a Shell thing.

@gregorius

Ah you can’t have it both ways

But of course we want to!

Actually, I think both ideas have merit. Though as well as an API, I'd personally want to set aliases in settings.js as well - which actually does follow the Linux/PS idea as you set permanent aliases in your profile by editing the file.

I was going to say that I thought the default overrides idea was more important in my view. But again, Nick as really already covered the priority part.

[dceejay]

I have raised the simplest possible PR here - Allow a nodes defaults to be overridden by settings.js file by dceejay · Pull Request #5591 · node-red/node-red · GitHub
fingers-crossed.

[TotallyInformation]

Couple of comments added.