Support for node status list and duration

Not sure I've completely understood this thread so if this is not relevant, please ignore.

My thought - and hopefully one that maintains the best possible backwards compatibility - would be to add a new status type. That way, the original status would continue to act just as it does now. And so would the status node.

Then you could have a completely separate "live status". You could extend the status node to be triggered on these or ignore them. So avoiding all of the issues regarding rolling back to a previous state - you wouldn't need to. But, a flow using a status node could easily be extended to deal with temporary status changes if you wanted to. But you wouldn't be forced to.

For custom nodes, the issuing of a "live status" would overwrite any existing actual status and, on timeout, would simply revert. There would not be any need to re-issue the old status (now current again) because the status node understands they are different and your flow handles it, not the node.

As I say, this feels that it should be 100% backwards compatible with minimal changes needed to core. It also keeps the 2 concepts somewhat separated which, in my weird brain at least, seems easier to comprehend.

So the workflow would be:

  1. Trigger a standard, static status if you want - using the current functions.
  2. On receipt of a suitable event or msg, trigger a "live status" using a new RED function to be created in core. That fn will have access to the current non-live status automatically via reference to the node data, see the next para for why that is important. When the live status times out, all it has to do is restore the visual to the current non-live status (if set), nothing else.

If your flow updates the standard status while the live status is active, then the current status function would still be triggered and any connected status node would also be triggered, however, the display would not update (that might need to be an option). But because the new live status function "knows" the current non-live status setting, as the timeout expires, it will automatically set the display to the correct status.

Not sure if any of that makes sense, it has been a very long week for me and my brain is a little burned out.