Still really new to this, but trying to figure out how we can add some locking to prevent multiple users from overwriting the same flow. This would be for small teams who maybe be working/viewing "team flows". I know there is a warning popup, but wanting to do something more - for example somehow tracking who has which flow open in an editor to provide a message: "User Joe currently has this flow locked - do you want to override his lock?" Then I would flip the "lock-owner" and if Joe comes back from lunch we would alert him that his lock has been broken (ie someone has saved a modified flow on top of the copy he has).
We will try to create many subflows to minimize these conflicts, but still possible.
Also, is it possible to provide subflows that are readonly to the users? In fact, I would like to provide customized mongo nodes without them being able to even view the connection strings.
at the moment, none of what you describe is possible. But there are some bits in the roadmap that will address some of it.
Improving the multi-user experience - nothing specific is in the plan, but I recognise this as an area that needs improving. Whether that involves locking of flows, or more real-time collaboration, I don't know.
Exportable Subflows - this is work that is currently in progress and will hopefully make an appearance in 1.2. It provides a way to export a subflow to make it easier to share - adding in more metadata about the subflow. One of the options when exporting the subflow is being able to 'seal' it. When it gets imported, the user would not be able to open up the subflow template to see its internal details - it would appear just like any other node in the palette.
The user would still be able to see the raw JSON of the subflow - so mongo connection strings etc would still be readable at that level.
But building on that is a design discussion around encrypting the subflow contents. However this poses a different set of challenges around how the decryption is handled. This is being discussed here: https://github.com/node-red/designs/pull/26
Thanks for the quick reply! Am I correct that all the flows are currently serialized into a single json file?
I'm hoping to version individual flows/subflows so that is one thing I'd love to see modified. We may attempt to fork and go our own way. I really LOVE the NodeRed UI and base functionality so far, but in our use case the inability to "share" is a big problem. These guys are used to sharing a giant Excel file with hundreds of formulas that they modify on a fairly frequent basis.
You are right - the default file store puts all flows in a single file.
Having an option to split them out is also on the backlog.
But the storage layer is pluggable - you could create your own storage plugin that stores flows in separate files - https://nodered.org/docs/api/storage/
