I have requirement to programmatically identify changes in node-red editor that are not yet deployed. Manually we can see that node-red displays a blue circle over the nodes that are not deployed. In order to automate and perform certain action based on pending changes, I need to do this programmatically.
In documentation, an event is mentioned workspace:dirty, but its usage is not explained anywhere (client side/server side), and how to access it at workspace level in code. Any help/suggestions are welcome.
@knolleary ... what would be the best place to put this check. I do not want to write it in HTML of each node to check for dirty, as that way it will not cover the pre-built nodes. Is there a single place from where I can capture the state?
Thanks @knolleary ... My use case is a to extend Node-Red to multiple users/tenants. So from my application UI, I dynamically spin up Node-Red docker containers backed by persistent volumes for individual users who are granted Node-Red access in my app (To avoid users overwriting/messing up each others flows).
Now I can not have too many containers as it consumes lot of cloud resources. So I have decided to terminate those containers when user session ends. Thus I have written code which will calculate time remining before JWT token expires.
I now want to alert users 5 minutes before the session expires and their container terminates (there is no token refresh implemented yet), so as to not lose any changes. Thus I need to know if the workspace is in dirty state to show a pop-up and alert user to save the changes.
@knolleary writing a plugin just to show an alert seems a bit too much work. I gave it a thought and if I alter my approach as below:
calculate token expiry in my app -> make a REST call to custom Node Red Admin API endpoint using RED.httpAdmin.post (not sure where to write this) -> within post call use RED.notify
Will this work?
If I can get a count of logged in users from Node Red then if count(users logged in) === 0 then I will terminate instances.
Kindly suggest if any of above is feasible!!
Agree that this would likely be the best approach and would also be potentially reusable.
The plugin is a separate js file that is part of the package your node comes in and is declared in the package.json file under the node-red section if I remember correctly.
I think that you would need to collect this yourself via middleware on the node-red admin ExpressJS instance. the httpAdminMiddleware setting in settings.js should allow you to insert some code to capture unique users as long as you can think of a way to identify them. I'm not sure if adminAuth passes anything useful or whether you would need a custom function for adminAuth (sorry, lost track of whether you are already doing that). If you use a custom function for adminAuth, you might not need the extra middleware.
Assuming you can find some information to identify unique users and so keep a count (and we haven't thought about the process(es) for user logout/session-expiry handling), you then have the issue of making that available to the Editor. That might need the middleware again to provide a custom API (not hard to do). Then the editor could query that?
@TotallyInformation ... Thanks for the response. For 1st approach, I know it can be done for a node/custom nodes, but it would still not work with pre-built nodes that comes with Node-Red. Hence was looking for a common place from where info could be gathered for all nodes in all tabs (within a workspace).
For 2nd Approach - I am thinking, probably to keep track of session when I am dynamically creating container (may be through DB) and get the active user count from there rather than going to Node-Red.
Yes, that is probably the best approach. It is trivial to set up a small node.js service that acts as an API that node-red can query. So having a common Docker container containing even just a SQLite db along with the simple API to return the value would probably be plenty.