Provide a generalized "event" system for acting on model-changes #8780

New Issue

adam · 2025-12-29T20:41:05+01:00

adam commented

2025-12-29 20:41:05 +01:00

Originally created by @arthanson on GitHub (Oct 27, 2023).

Originally assigned to: @arthanson on GitHub.

NetBox version

v3.5.6

Feature type

New functionality

Proposed functionality

Refactor and extend the current webhook handler to a more generalized eventing system. There is a proposal #11827 to allow scripts to be run depending on object changes which is similar to how webhooks work. This would make the system more generalized so that these events (signals) can do one or more actions (send webhook or run script) with the ability to more easily add more in the future.

Proposed changes

add login/logout to the events_queue (not processed by webhooks) but useful for future events
change webhooks_worker.py to events_worker.py and process_webhooks to process_event this will just call a series of functions defined in settings.py pipeline to process events. One will be defined for webhooks, another for script running. This also allows future processors to easily plug into here.
change the webhooks list and detail page to be events with an action type (webhook, script)
Change the edit page to have a dropdown for action (call webhook or run script) and HTMX to switch the form below for HTTP Request (as it is now for webhook) or a script selector for Script type.
Make a migration to map current webhook table to new events table - the signal object type and CRUD selection and type of action would be in the new event model. The post-details would be in the webhooks table.

Note: This would make a script (and all future event types) only run for the object change if the transaction succeeds - which seems to be the correct method.

From previous Issue #11827:

Establish a mechanism by which a custom script can "attach" to one or more signals, so that the script automatically runs when the signal is received. This will likely need to be done programmatically as scripts are discovered. It should be possible to associate a script with a particular arbitrary signal and optionally only to certain senders for that signal.

We'll need to devise a way to automatically discover scripts, as scripts are currently only loaded as needed (e.g. in response to UI/API requests). Special consideration must also be paid to the execution workflow, to ensure that a catastrophic script error does not interfere with the triggering behavior.

For registration, it may be sufficient to call get_scripts() upon NetBox initialization, and execute a prescribed class method on each discovered script to handle its signal attachment. We'll also need to devise a convention for declaring receiver methods on each script.

Use case

Often it is desirable to automatically execute a custom script in response to the creation, modification, or deletion of a NetBox object (similar to how webhooks function).

Makes the code more DRY with this extension and existing webhooks code.

Also makes it more easily extensible in the future as there are probably more action types beyond webhooks and scripts that would make sense in the future.

Database changes

Need a new events table, new script-event table and modify the existing webhooks table.

External dependencies

No response

Originally created by @arthanson on GitHub (Oct 27, 2023). Originally assigned to: @arthanson on GitHub. ### NetBox version v3.5.6 ### Feature type New functionality ### Proposed functionality Refactor and extend the current webhook handler to a more generalized eventing system. There is a proposal #11827 to allow scripts to be run depending on object changes which is similar to how webhooks work. This would make the system more generalized so that these events (signals) can do one or more actions (send webhook or run script) with the ability to more easily add more in the future. **Proposed changes** * add login/logout to the events_queue (not processed by webhooks) but useful for future events * change webhooks_worker.py to events_worker.py and process_webhooks to process_event this will just call a series of functions defined in settings.py pipeline to process events. One will be defined for webhooks, another for script running. This also allows future processors to easily plug into here. * change the webhooks list and detail page to be events with an action type (webhook, script) * Change the edit page to have a dropdown for action (call webhook or run script) and HTMX to switch the form below for HTTP Request (as it is now for webhook) or a script selector for Script type. * Make a migration to map current webhook table to new events table - the signal object type and CRUD selection and type of action would be in the new event model. The post-details would be in the webhooks table. **Note:** This would make a script (and all future event types) only run for the object change if the transaction succeeds - which seems to be the correct method. **From previous Issue #11827:** Establish a mechanism by which a custom script can "attach" to one or more [signals](https://docs.djangoproject.com/en/4.1/topics/signals/), so that the script automatically runs when the signal is received. This will likely need to be done programmatically as scripts are discovered. It should be possible to associate a script with a particular arbitrary signal and optionally only to certain senders for that signal. We'll need to devise a way to automatically discover scripts, as scripts are currently only loaded as needed (e.g. in response to UI/API requests). Special consideration must also be paid to the execution workflow, to ensure that a catastrophic script error does not interfere with the triggering behavior. For registration, it may be sufficient to call get_scripts() upon NetBox initialization, and execute a prescribed class method on each discovered script to handle its signal attachment. We'll also need to devise a convention for declaring receiver methods on each script. ### Use case Often it is desirable to automatically execute a custom script in response to the creation, modification, or deletion of a NetBox object (similar to how webhooks function). Makes the code more DRY with this extension and existing webhooks code. Also makes it more easily extensible in the future as there are probably more action types beyond webhooks and scripts that would make sense in the future. ### Database changes Need a new events table, new script-event table and modify the existing webhooks table. ### External dependencies _No response_

adam added the status: accepted type: feature labels 2025-12-29 20:41:05 +01:00

adam closed this issue

2025-12-29 20:41:06 +01:00

adam referenced this issue

2025-12-29 22:27:08 +01:00

[PR #8780] [CLOSED] Closes #6582: Allow available-ips to specify network bits #13391

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#8780