Add javascript support for custom scripts to dynamically populate/modify on user input on demand #6559

Originally created by @tom0010 on GitHub (Jun 11, 2022).

NetBox version

v3.2.4

Feature type

New functionality

Proposed functionality

I'd like to propose support for javascript/typescript support when using custom scripts so that the custom script webpage can be dynamically updated when a user is editing the form, such as checkboxes or selection boxes.
I have some scripts that can potentially become very large and lengthly depending on the users requirements, however it may become overwhelming to users if the page is extremely long.
Some more info here: https://netdev-community.slack.com/archives/C01P0FRSXRV/p1652955534907109?thread_ts=1652951978.388159&cid=C01P0FRSXRV

Use case

~~Better UX for the end user.~~

Edit:
We are leveraging Netbox scripts for user inputs and to execute code from a nice UI, we couple this with either some Ansible or Python code to do this. We have some scripts that actually require multiple inputs, these inputs can become very big and therefore become quite long in the Netbox script. The length of the script/page is not really an issue from a UI point of view, providing the user is required to input all of the said data. However, in some cases, there are times where a user only needs to input X amount of data, let's say they want to implement a "primary" site. Primary could be viewed as default in the script page with the option to add a "secondary" site with a button. Upon a user clicking a button, that would build the javascript page to "show" the "secondary inputs for the end user.

Another example could be for the user to show just the "required" fields from a Netbox script.

Main reason behind this is to have a better UI as I already said, however with the current Netbox scripts if a user that is building the script creates a big Netbox script they may become too overwhelming for the end user in some cases. This change would make the Netbox scripts for friendly for the end users.

Database changes

~~Not sure.~~
I don't think there are any, I think this would just be leveraging javascript/typscript on top of the existing codebase in the scripts templates upon build.

External dependencies

None, I don't think.

Originally created by @tom0010 on GitHub (Jun 11, 2022). ### NetBox version v3.2.4 ### Feature type New functionality ### Proposed functionality I'd like to propose support for javascript/typescript support when using custom scripts so that the custom script webpage can be dynamically updated when a user is editing the form, such as checkboxes or selection boxes. I have some scripts that can potentially become very large and lengthly depending on the users requirements, however it may become overwhelming to users if the page is extremely long. Some more info here: https://netdev-community.slack.com/archives/C01P0FRSXRV/p1652955534907109?thread_ts=1652951978.388159&cid=C01P0FRSXRV ### Use case ~~Better UX for the end user.~~ Edit: We are leveraging Netbox scripts for user inputs and to execute code from a nice UI, we couple this with either some Ansible or Python code to do this. We have some scripts that actually require multiple inputs, these inputs can become very big and therefore become quite long in the Netbox script. The length of the script/page is not really an issue from a UI point of view, providing the user is required to input all of the said data. However, in some cases, there are times where a user only needs to input X amount of data, let's say they want to implement a "primary" site. Primary could be viewed as default in the script page with the option to add a "secondary" site with a button. Upon a user clicking a button, that would build the javascript page to "show" the "secondary inputs for the end user. Another example could be for the user to show just the "required" fields from a Netbox script. Main reason behind this is to have a better UI as I already said, however with the current Netbox scripts if a user that is building the script creates a big Netbox script they may become too overwhelming for the end user in some cases. This change would make the Netbox scripts for friendly for the end users. ### Database changes ~~Not sure.~~ I don't think there are any, I think this would just be leveraging javascript/typscript on top of the existing codebase in the scripts templates upon build. ### External dependencies None, I don't think.

adam added the type: feature status: needs owner pending closure labels 2025-12-29 19:42:20 +01:00

adam closed this issue

adam commented

@jeremystretch commented on GitHub (Jun 12, 2022):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jeremystretch commented on GitHub (Jun 12, 2022): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

adam commented

2025-12-29 19:42:21 +01:00

@tom0010 commented on GitHub (Jun 13, 2022):

Hey @jeremystretch let me try to provide more info to fulfil that.
I'm afraid I don't know the code well enough to understand what changes would be needed to actually solve the feature request I am raising, but I hope that with the info I'm providing in the edited OP will be enough. If not, please let me know what else you'd like me to provide :)

@tom0010 commented on GitHub (Jun 13, 2022): Hey @jeremystretch let me try to provide more info to fulfil that. I'm afraid I don't know the code well enough to understand what changes would be needed to actually solve the feature request I am raising, but I hope that with the info I'm providing in the edited OP will be enough. If not, please let me know what else you'd like me to provide :)

adam commented

@kkthxbye-code commented on GitHub (Jun 13, 2022):

I think we need to consider if we want to support specific use cases for dynamic control of the form, or if we just want to allow the user to pass javascript to the frontend (typescript is probably not going to happen as it would require a transpilation step).

My initial thought was to add an option to custom script fields to dynamically hide/show fields based on the value of other fields. I'm unsure of the feasibility of the implementation, but should probably be possible without too much effort.

@kkthxbye-code commented on GitHub (Jun 13, 2022): I think we need to consider if we want to support specific use cases for dynamic control of the form, or if we just want to allow the user to pass javascript to the frontend (typescript is probably not going to happen as it would require a transpilation step). My initial thought was to add an option to custom script fields to dynamically hide/show fields based on the value of other fields. I'm unsure of the feasibility of the implementation, but should probably be possible without too much effort.

adam commented

2025-12-29 19:42:21 +01:00

@tom0010 commented on GitHub (Jun 13, 2022):

My initial thought was to add an option to custom script fields to dynamically hide/show fields based on the value of other fields. I'm unsure of the feasibility of the implementation, but should probably be possible without too much effort.

This is was exactly what I was thinking.

@tom0010 commented on GitHub (Jun 13, 2022): > My initial thought was to add an option to custom script fields to dynamically hide/show fields based on the value of other fields. I'm unsure of the feasibility of the implementation, but should probably be possible without too much effort. This is was exactly what I was thinking.

adam commented

@MalfuncEddie commented on GitHub (Jul 12, 2022):

I asked for this in the discussion forum
https://github.com/netbox-community/netbox/discussions/9702

Hi,

This might be a bit out there but it would be really really nice if this is possible.
I only started netbox scripting a couple of days ago and reading through the documentation (https://docs.netbox.dev/en/stable/customization/custom-scripts/#objectvar) I see that you can filter with query_params.

Is it possible to link objectvar fields.

Eg:
A script that gets certain vm's of a tenant and do some scripting on it and send it to an 3rd party api.

First field would be:
Select the tenant

Second field select the VM's
--> it would be nice if the query_params would make it so that it only shows the vm's of the tenant selected in the first field.

    class Meta:
        name = "Generate report for tenant"
        description = "Generate report for tenant"

    tenant = ObjectVar(model=Tenant)
    vms =  MultiObjectVar(model=Contact,query_params=<see variable tenant> )

To make this work it might be easier to create a "custom wizard" of thje ability to have the filter tab on the custom script page would be nice

@MalfuncEddie commented on GitHub (Jul 12, 2022): I asked for this in the discussion forum https://github.com/netbox-community/netbox/discussions/9702 Hi, This might be a bit out there but it would be really really nice if this is possible. I only started netbox scripting a couple of days ago and reading through the documentation (https://docs.netbox.dev/en/stable/customization/custom-scripts/#objectvar) I see that you can filter with query_params. Is it possible to link objectvar fields. Eg: A script that gets certain vm's of a tenant and do some scripting on it and send it to an 3rd party api. First field would be: Select the tenant Second field select the VM's --> it would be nice if the query_params would make it so that it only shows the vm's of the tenant selected in the first field. ```class GenerateReport(Script): class Meta: name = "Generate report for tenant" description = "Generate report for tenant" tenant = ObjectVar(model=Tenant) vms = MultiObjectVar(model=Contact,query_params=<see variable tenant> ) ``` To make this work it might be easier to create a "custom wizard" of thje ability to have the filter tab on the custom script page would be nice

adam commented

@kkthxbye-code commented on GitHub (Jul 12, 2022):

@MalfuncEddie - This is already supported and explained in the documentation you linked:

It is also possible to reference the value of other fields in the form by prepending a dollar sign ($) to the variable's name.

region = ObjectVar(
    model=Region
)
site = ObjectVar(
    model=Site,
    query_params={
        'region_id': '$region'
    }
)

@kkthxbye-code commented on GitHub (Jul 12, 2022): @MalfuncEddie - This is already supported and explained in the documentation you linked: > It is also possible to reference the value of other fields in the form by prepending a dollar sign ($) to the variable's name. ``` region = ObjectVar( model=Region ) site = ObjectVar( model=Site, query_params={ 'region_id': '$region' } ) ```

adam commented

@MalfuncEddie commented on GitHub (Jul 13, 2022):

@kkthxbye-code tnx for the info. I've got custom script that work a lot better now. Funny thing is that now it is finished I am also hitting the "it would be nice if a checkbox could hide/unhide certain inputs" fase :)

@MalfuncEddie commented on GitHub (Jul 13, 2022): @kkthxbye-code tnx for the info. I've got custom script that work a lot better now. Funny thing is that now it is finished I am also hitting the "it would be nice if a checkbox could hide/unhide certain inputs" fase :)

adam commented

@github-actions[bot] commented on GitHub (Oct 22, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Oct 22, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@tom0010 commented on GitHub (Oct 22, 2022):

@kkthxbye-code any chance this can be reviewed? You said you didn’t think it would be that much effort to implement.

@tom0010 commented on GitHub (Oct 22, 2022): @kkthxbye-code any chance this can be reviewed? You said you didn’t think it would be that much effort to implement.

adam commented

@jeremystretch commented on GitHub (Jan 5, 2023):

@kkthxbye-code can you take another look at this? I'm not clear on what work needs to be done (if any).

@jeremystretch commented on GitHub (Jan 5, 2023): @kkthxbye-code can you take another look at this? I'm not clear on what work needs to be done (if any).

adam commented

@kkthxbye-code commented on GitHub (Jan 5, 2023):

@jeremystretch - I've been tinkering with it for a while, but keep running into issues with our frontend js. I'll give it another shot this weekend hopefully, and if I'm still not getting any progress I might throw in the towel and implement something in a plugin instead.

The idea boils down to dynamically disabling/enabling form fields based on other fields. A contrived example:

    object_type_choice = (
        ('Virtual Machine', 'vm'),
        ('Physical Device', 'device'),
    )

    object_type = ChoiceVar(choices=object_type_choice)
    device = ObjectVar(
        model=Device,
        depends_on={
            'object_type': 'device'
        }
    )
    vm = ObjectVar(
        model=VirtualMachine,
        depends_on={
            'object_type': 'vm'
        }
    )

When loading the form only the object_type would be visible, choose Virtual Machine in the dropdown and the vm field is enabled etc. I'm not really certain of the final design, there's a lot to consider, like if we should support all field types, if we should support negation in the conditions etc. It all depends on how much the js fights me.

Happy to hear any and all input/ideas.

@kkthxbye-code commented on GitHub (Jan 5, 2023): @jeremystretch - I've been tinkering with it for a while, but keep running into issues with our frontend js. I'll give it another shot this weekend hopefully, and if I'm still not getting any progress I might throw in the towel and implement something in a plugin instead. The idea boils down to dynamically disabling/enabling form fields based on other fields. A contrived example: ``` object_type_choice = ( ('Virtual Machine', 'vm'), ('Physical Device', 'device'), ) object_type = ChoiceVar(choices=object_type_choice) device = ObjectVar( model=Device, depends_on={ 'object_type': 'device' } ) vm = ObjectVar( model=VirtualMachine, depends_on={ 'object_type': 'vm' } ) ``` When loading the form only the `object_type` would be visible, choose Virtual Machine in the dropdown and the vm field is enabled etc. I'm not really certain of the final design, there's a lot to consider, like if we should support all field types, if we should support negation in the conditions etc. It all depends on how much the js fights me. Happy to hear any and all input/ideas.

adam commented

@davidgwatkins commented on GitHub (Jan 28, 2023):

@kkthxbye-code Any progress in your JS fight? This would be huge!

@davidgwatkins commented on GitHub (Jan 28, 2023): @kkthxbye-code Any progress in your JS fight? This would be huge!

adam commented

@github-actions[bot] commented on GitHub (Jun 17, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 17, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@github-actions[bot] commented on GitHub (Jul 18, 2023):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 18, 2023): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

adam commented

@balpoint commented on GitHub (Jul 18, 2023):

Was really looking forward to this being implemented one day :(

@balpoint commented on GitHub (Jul 18, 2023): Was really looking forward to this being implemented one day :(

adam commented