multiselect input type and hiding core nodes?

[edwmurph]

i am on a team considering using this for an internal tool for a large enterprise. could support for either of these features be considered?

• new multiselect input type for custom nodes
  • it would help to restrict the inputs using an enum on certain custom nodes from the UI
  • multiselect would also help to improve our current workaround of using a comma delimited string input
• hiding the "Javascript Function" node
  • we don't want users to be writing custom javascript and are currently hiding this node using css

also if either of these are simple to implement, I would be interested in contributing if you could point me in the right direction, thanks!

[ivanmiletic]

Hi @edwmurph based on the questions:

1.1. & 1.2. We were thinking about it, at the moment we are in process of enhancing table/switch/expression editing fields. It is not a priority but we might have opportunity to do it in the next couple of months

2. Not in the scope, but you will be able to achieve it with a new "Views"/Modifier role concept. It will give you capability to select what is editable/configurable in the graph, example you to allow power users to have full access to the graph but other users to have limited editing capabilities.

For example you have a graph with 10 nodes, but you want to limit certain groups of users to only have access to 2 tables, and not even that, you might say 1 table is editable and configurable but second one is just editable (they can't even add/update/remove columns).

It is in Draft PR: #22

[edwmurph]

Thanks for the updates! These features would be a significant improvement to our workflow. Please let me know if there's anything I can do to help move this forward!

[jackfrankland]

@ivanmiletic

1.1. & 1.2. We were thinking about it, at the moment we are in process of enhancing table/switch/expression editing fields. It is not a priority but we might have opportunity to do it in the next couple of months

Can you please clarify what you mean by this functionality? Would this mean that, in a table, rather than match on a free text string, we would be able to set the enum vales, and allow the user to select from a dropdown?

[ivanmiletic]

Hi @jackfrankland yes, that is correct - we are planning to add Enums / Select in columns at some point over next couple of months - even more advanced such as to point column config to some endpoint that has a list of value,labels. In this case users will see a select with labels but under the hood it will store values. This will useful if you have some UUID / unique code but you want to display human readable text to customers

[edwmurph]

@ivanmiletic Any update on this?

This library has proven to be a great fit for my team's use case, and we are really impressed with its capabilities. The ability for custom nodes to have a dropdown input would make a significant different for our users.

The UX/input we are looking for is similar to the decision node: