Plugin events pipeline registration

[natm]

NetBox version

v3.7.2

Feature type

New functionality

Proposed functionality

3.7.0 introduced the events pipeline described in https://github.com/netbox-community/netbox/issues/14132

This involves making an entry in EVENTS_PIPELINE=[] within configuration.py, it would be more ergonomic if plugins could register for events by declaring intent within their configuration.

For example:

from netbox.plugins import PluginConfig

class FooBarConfig(PluginConfig):
    name = 'foo_bar'
    verbose_name = 'Foo Bar'
    description = 'An example NetBox plugin'
    version = '0.1'
    author = 'Jeremy Stretch'
    author_email = 'author@example.com'
    base_url = 'foo-bar'
    required_settings = []
    default_settings = {
        'baz': True
    }
    events_pipeline_registrations = [
         "foobar.mymodule.custom_event_handler"
    ]
    django_apps = ["foo", "bar", "baz"]

config = FooBarConfig

events_pipeline_registrations would be optional to allow for backwards compatibility and default to []

It would allow plugins which require access to the events pipeline to have entries added into EVENTS_PIPELINE automatically. This reduces complexity on those installing Netbox plugins which need events access.

https://linear.app/netboxlabs/issue/BIZ-6/

Use case

Simplify access to the events pipeline for plugins, reduce configuration complexity.

Database changes

No response

External dependencies

No response

[jeffgdotorg]

@arthanson does ordering matter in the EVENTS_PIPELINE list? Do we anticipate needing a mechanism to shape the smushing together of the per-plugin list with the one in configuration.py?

[jeffgdotorg]

This feature is essential for the evolution of plugins into more self-contained units, but it also requires a change to the plugin API that we cannot introduce at a micro-version boundary (3.7.2 -> 3.7.3). The soonest our semantic versioning contract would permit it is v4.0.

In the meantime, we can consider alternative approaches that don't involve changes to the plugin API.

[jeffgdotorg]

Getting this issue out ot triage jail. We should revisit once the dust has settled from 4.0b1 and consider whether to take on the full implementation in v4.1, or look for an alternative approach that can be done within an existing release train without violating the plugin API's semver.