How can I prevent user to create multiple config nodes / function nodes?
don't let them access the editor...
1 Like
.. that really very "restrictive" - a bit less would be good.
The use need to edit other function nodes in the package.
There is no way to restrict what a user does when they open the editor. They can add whatever nodes they want to the workspace with whatever config nodes they need.
Can you expand on your actual use case? Do you have a custom node that should only have one instance of in the workspace? You mention the Function node - so is this a more general requirement to restrict the use of any type of node?
If we can understand more about what you are trying to achieve, it would help us think about what could be done to support that in the future.
I have 4 types of nodes "config node" | "household" | "playerGroup" | "singlePlayer". In an household there might be multiple groups (ok) and multiple players (OK) but it is only one household.
For 2 of them I would like to restrict multiple creation:
a) config node, defining port and ip address for a http server.
The server is launched when node is deployed. There should only be one.
The server needs to listen to /notify - that's why I cant use httpNode.
b) a function node "household". This nodes creates 4 event listener.
One node is sufficient - any additional deployed node would only increase the number of listeners - but provide no additional value.
Is the use case understandable?
Hey @hklages!
Can you clarify why the restriction of only one config node/household is necessary? More often I think most people naturally assume that one alone serves their needs and you achieve what you're describing through that UX but could one could imagine a power user hosting an instance that services multiple households? It requires a little more legwork in the household node in that it has to allow for selecting which household is intended but since most will only have one it can be prepopulated with the sole config.
Are you concerned with performance implications of people creating multiple event listeners via multiple household nodes? If they are subscription based (vs polling based) there isn't any significant impact. If you are very concerned one could build it in such a way that the listener mechanisms are part of a config node's service and the household node connects to those listeners rather than instancing their own. Maybe a reframing of "household" to "household events" node would be clear at that point/
If I am understanding you correctly does this make sense and seem appropriate? What sorts of concerns would you have in that case?
Thanks for you answer!
... could one could imagine a power user hosting an instance that services multiple households?
That's not supported by Sonos. Different household means different local networks and vice versa. And my node only works in one local network (no cloud, no vpn).
... If you are very concerned one could build it in such a way that the listener mechanisms are part of a config node's service and the household node connects to those listeners rather than instancing their own.
That's a very good point. I will do that. So the point "restrict user to create multiple function nodes" is solved.
So the problem is reduced to: How to restrict creation of multiple config nodes?
My current solution is to give default name and give advice to the user.
I tried to make the name field invisible, read only, hidden but then multiple config nodes with the same name (different id) might be created.
One more question.
Are config nodes always deployed before function nodes?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
