Enable commiting changes after script dry-run is completed #6598

New Issue

adam · 2025-12-29T19:42:49+01:00

adam commented

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

Originally created by @jahknem on GitHub (Jun 27, 2022).

NetBox version

v3.2.5

Feature type

New functionality

Proposed functionality

I'd like to have a commit button added to the log page of a script result. It should only appear/be clickable if the commit field has not been selcted. This commit button should add the changes to the database as though the commit field had been selected.

Use case

Currently when doing a dry run on a script, I have to uncheck the commit field. This means regardless of if the results are to my liking or not the changes do not get commited. This obviously is as intended. However it also forces the user to return to the input mask and enter their data a second time (except if it still in the browser cache, which is something that I would not want to rely on.)
My proposed change would enable users to first see the script ouput and logs before adding the the changes to the database. It is a quality of life change.

Database changes

No response

External dependencies

No response

Originally created by @jahknem on GitHub (Jun 27, 2022). ### NetBox version v3.2.5 ### Feature type New functionality ### Proposed functionality I'd like to have a commit button added to the log page of a script result. It should only appear/be clickable if the commit field has not been selcted. This commit button should add the changes to the database as though the commit field had been selected. ### Use case Currently when doing a dry run on a script, I have to uncheck the commit field. This means regardless of if the results are to my liking or not the changes do not get commited. This obviously is as intended. However it also forces the user to return to the input mask and enter their data a second time (except if it still in the browser cache, which is something that I would not want to rely on.) My proposed change would enable users to first see the script ouput and logs before adding the the changes to the database. It is a quality of life change. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature netbox status: backlog complexity: low labels 2025-12-29 19:42:50 +01:00

adam commented

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

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

I'd like to have a commit button added to the log page of a script result.

Each execution of a script is atomic. Depending on external factors that may be in play, a script which succeeds during its first run might fail immediately afterward. Thus, there is no mechanism available to "apply" the results of a script after the fact; it must be run again.

We can probably change up the workflow so that a script which is run without commit enabled yields the pre-populated form next to its results.

@jeremystretch commented on GitHub (Jun 28, 2022): > I'd like to have a commit button added to the log page of a script result. Each execution of a script is atomic. Depending on external factors that may be in play, a script which succeeds during its first run might fail immediately afterward. Thus, there is no mechanism available to "apply" the results of a script after the fact; it must be run again. We can probably change up the workflow so that a script which is run without commit enabled yields the pre-populated form next to its results.

adam commented

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

@DanSheps commented on GitHub (Jul 2, 2022):

I can fully get behind this, I too would like to be able to dry-run a script then when that succeeds simply re-run the form with the commit enabled.

I like the pre-population idea, however there may be other options available to us as well. Will definitely need some thought.

@DanSheps commented on GitHub (Jul 2, 2022): I can fully get behind this, I too would like to be able to dry-run a script then when that succeeds simply re-run the form with the commit enabled. I like the pre-population idea, however there may be other options available to us as well. Will definitely need some thought.

adam commented

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

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

How about locking the objects touched by the script for a predefined amount of time during which the results of the script may be inspected? If it is not commited during that time the changes would be reversed.
I can think of other cases where such a locking mechanism might me useful, like when editing a device with lots of interfaces in a netbox instance where lots of people have access.

@jahknem commented on GitHub (Jul 13, 2022): How about locking the objects touched by the script for a predefined amount of time during which the results of the script may be inspected? If it is not commited during that time the changes would be reversed. I can think of other cases where such a locking mechanism might me useful, like when editing a device with lots of interfaces in a netbox instance where lots of people have access.

adam commented

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

@github-actions[bot] commented on GitHub (Sep 12, 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 (Sep 12, 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

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

@github-actions[bot] commented on GitHub (Nov 16, 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 (Nov 16, 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

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

@BarbarossaTM commented on GitHub (Apr 22, 2023):

I'd also like to have this as we're starting to lean further on custom scripts to move business logic into NetBox.

I'd wished for a button like Run for real or Re-run with same values multiple times, which I guess would be the lowest hanging approach we could take (without digging very much into this). I'm open to take a stab at this if you want :-)

@BarbarossaTM commented on GitHub (Apr 22, 2023): I'd also like to have this as we're starting to lean further on custom scripts to move business logic into NetBox. I'd wished for a button like `Run for real` or `Re-run with same values` multiple times, which I guess would be the lowest hanging approach we could take (without digging very much into this). I'm open to take a stab at this if you want :-)

adam commented

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

@jeremystretch commented on GitHub (Apr 24, 2023):

The scope of the work here is just to enable re-running a script with the same form values; no changes should be made to the commit toggle. @BarbarossaTM happy to assign this to you. (Please be sure to base your work off of v3.5.)

@jeremystretch commented on GitHub (Apr 24, 2023): The scope of the work here is just to enable re-running a script with the same form values; no changes should be made to the commit toggle. @BarbarossaTM happy to assign this to you. (Please be sure to base your work off of v3.5.)

adam commented

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

@BarbarossaTM commented on GitHub (Apr 24, 2023):

To be sure: I'd start hacking on this based on the develop branch, which I assume is what you'd want me to do @jeremystretch?

@BarbarossaTM commented on GitHub (Apr 24, 2023): To be sure: I'd start hacking on this based on the `develop` branch, which I assume is what you'd want me to do @jeremystretch?

adam commented

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

@jeremystretch commented on GitHub (Apr 24, 2023):

We're in a bit of transitional period at the moment: v3.4.9 will be released in the next day or two, followed very shortly by v3.5.0. If you plan to start now, you should base your work off of the feature branch, which will be merged into develop just ahead of the v3.5 release.

@jeremystretch commented on GitHub (Apr 24, 2023): We're in a bit of transitional period at the moment: v3.4.9 will be released in the next day or two, followed very shortly by v3.5.0. If you plan to start now, you should base your work off of the `feature` branch, which will be merged into `develop` just ahead of the v3.5 release.

adam commented

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

@jeremystretch commented on GitHub (May 2, 2023):

@BarbarossaTM you're welcome to begin work on this using the develop branch now that v3.5.0 has been released.

@jeremystretch commented on GitHub (May 2, 2023): @BarbarossaTM you're welcome to begin work on this using the `develop` branch now that v3.5.0 has been released.

adam commented

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

@BarbarossaTM commented on GitHub (May 3, 2023):

Thanks @jeremystretch, I've penciled this task for this week, will go for develop then.

@BarbarossaTM commented on GitHub (May 3, 2023): Thanks @jeremystretch, I've penciled this task for this week, will go for `develop` then.

adam commented

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

@jeremystretch commented on GitHub (May 25, 2023):

@BarbarossaTM are you still planning to work on this?

@jeremystretch commented on GitHub (May 25, 2023): @BarbarossaTM are you still planning to work on this?

adam commented

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

@BarbarossaTM commented on GitHub (May 25, 2023):

Sorry was pretty swamped the last weeks and am doing on-call this week. I still have this on my list, if however someone were to have spare cycles right now, I'm happy to hand this over. Otherwise I'll try to prioritize this for next week.

@BarbarossaTM commented on GitHub (May 25, 2023): Sorry was pretty swamped the last weeks and am doing on-call this week. I still have this on my list, if however someone were to have spare cycles right now, I'm happy to hand this over. Otherwise I'll try to prioritize this for next week.

adam commented

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

@BarbarossaTM commented on GitHub (Jun 13, 2023):

So, finally got a chance to look into this.

From what I can gather from scripts.py we need to store the request and data somewhere, so we can re-use it on a consecutive run.

We could extend the DB model to hold that data for every script run, however that could become quite some amount of data, especially when folks upload files (using FileVars). So before I start hacking anything, I'd like to touch base if we agree on this path forward as it has quite some drawbacks.

The obvious remediation for this would be a scheduler which purges request data from the DB after a fairly low time frame (15m, 1h, 1d?), so we don't collect too much bloat.

Any thoughts @jeremystretch?

@BarbarossaTM commented on GitHub (Jun 13, 2023): So, finally got a chance to look into this. From what I can gather from `scripts.py` we need to store the `request` and `data` somewhere, so we can re-use it on a consecutive run. We could extend the DB model to hold that data for every script run, however that could become quite some amount of data, especially when folks upload files (using `FileVar`s). So before I start hacking anything, I'd like to touch base if we agree on this path forward as it has quite some drawbacks. The obvious remediation for this would be a scheduler which purges request data from the DB after a fairly low time frame (15m, 1h, 1d?), so we don't collect too much bloat. Any thoughts @jeremystretch?

adam commented

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

@8ctorres commented on GitHub (May 28, 2024):

Hi! Just to chime in on this one. I do this exact thing for my NetBox users.

We have a few scripts that make changes to devices and circuits, and then the script returns the rendered configuration for that device, and the workflow the users follow is:

1st - Run the script without committing changes. The script makes the changes, returns the new rendered configuration, and doesn't save the changes.
2nd - Take the rendered configuration, go make whatever physical changes to the device (plug/unplug whatever cable) and then apply the new config
3rd - Check everything works as it should
4th - Run the same script again, with the same inputs, but this time committing the changes so they get saved to NetBox.

Step 4 is a bit tedious since it means the user has to go back and type in the same inputs again, and is also prone to human errors. What I do is, I generate a link to the script page that includes all of the attributes and their values, and print it in the output log of the script with the name "CLICK HERE TO RUN AGAIN" (it supports Markdown so it shows up as a hyperlink). When they click that, it takes them to the script input page but everything is already populated with the correct values, they only have to check the "commit" checkbox and hit "run".

The code is really simple:

    link = self.request.path + "?"
    for d in data:
        if type(data[d]) == str or type(data[d]) == int:
            # For basic types, make it url safe
            link = link + d + "=" + urllib.parse.quote_plus(str(data[d])) + "&"
        else:
            # For Netbox types, use object ID
            link = link + d + "=" + (str(data[d].id) + "&" 
    log_line = "[CLICK HERE TO RUN AGAIN](" + link[:-1] + ")"
    self.log_info(log_line)

It's admittely a bit of a hack, and an actual button with this functionality would look better and also be less prone to errors, but it is a way to get around this issue.

@8ctorres commented on GitHub (May 28, 2024): Hi! Just to chime in on this one. I do this exact thing for my NetBox users. We have a few scripts that make changes to devices and circuits, and then the script returns the rendered configuration for that device, and the workflow the users follow is: 1st - Run the script without committing changes. The script makes the changes, returns the new rendered configuration, and doesn't save the changes. 2nd - Take the rendered configuration, go make whatever physical changes to the device (plug/unplug whatever cable) and then apply the new config 3rd - Check everything works as it should 4th - Run the same script again, with the same inputs, but this time committing the changes so they get saved to NetBox. Step 4 is a bit tedious since it means the user has to go back and type in the same inputs again, and is also prone to human errors. What I do is, I generate a link to the script page that includes all of the attributes and their values, and print it in the output log of the script with the name "CLICK HERE TO RUN AGAIN" (it supports Markdown so it shows up as a hyperlink). When they click that, it takes them to the script input page but everything is already populated with the correct values, they only have to check the "commit" checkbox and hit "run". The code is really simple: ``` link = self.request.path + "?" for d in data: if type(data[d]) == str or type(data[d]) == int: # For basic types, make it url safe link = link + d + "=" + urllib.parse.quote_plus(str(data[d])) + "&" else: # For Netbox types, use object ID link = link + d + "=" + (str(data[d].id) + "&" log_line = "[CLICK HERE TO RUN AGAIN](" + link[:-1] + ")" self.log_info(log_line) ``` It's admittely a bit of a hack, and an actual button with this functionality would look better and also be less prone to errors, but it is a way to get around this issue.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6598