-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a generalized "event" system for acting on model-changes #14132
Labels
status: accepted
This issue has been accepted for implementation
type: feature
Introduction of new functionality to the application
Milestone
Comments
arthanson
added
the
type: feature
Introduction of new functionality to the application
label
Oct 27, 2023
jeremystretch
added
the
status: under review
Further discussion is needed to determine this issue's scope and/or implementation
label
Oct 30, 2023
jeremystretch
added
status: accepted
This issue has been accepted for implementation
and removed
status: under review
Further discussion is needed to determine this issue's scope and/or implementation
labels
Nov 1, 2023
jeremystretch
added a commit
that referenced
this issue
Dec 4, 2023
jeremystretch
added a commit
that referenced
this issue
Dec 4, 2023
jeremystretch
added a commit
that referenced
this issue
Dec 4, 2023
Merged
jeremystretch
added a commit
that referenced
this issue
Jan 3, 2024
jeremystretch
added a commit
that referenced
this issue
Jan 3, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
status: accepted
This issue has been accepted for implementation
type: feature
Introduction of new functionality to the application
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
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
The text was updated successfully, but these errors were encountered: