Event enum (#8573)

* Add enumeration for stock events * Update function def * Refactor build events * Plugin events * Update order events * Overdue order events * Add documentation * Revert mkdocs.yml * Stringify event name * Enum cleanup - Support python < 3.11 - Custom __str__ * Add unit tests * Fix duplicated code * Update unit tests * Bump query limit * Use proper enums in unit tests
2025-06-15 19:45:46 +00:00 · 2024-11-29 12:05:05 +11:00
parent 390828d166
commit dd9a6a8a2d
21 changed files with 472 additions and 58 deletions
--- a/docs/docs/extend/plugins/event.md
+++ b/docs/docs/extend/plugins/event.md
@ -15,6 +15,151 @@ When a certain (server-side) event occurs, the background worker passes the even
 {% include 'img.html' %}
 {% endwith %}

+## Events
+
+Events are passed through using a string identifier, e.g. `build.completed`
+
+The arguments (and keyword arguments) passed to the receiving function depend entirely on the type of event.
+
+!!! info "Read the Code"
+    Implementing a response to a particular event requires a working knowledge of the InvenTree code base, especially related to that event being received. While the *available* events are documented here, to implement a response to a particular event you will need to read the code to understand what data is passed to the event handler.
+
+## Generic Events
+
+There are a number of *generic* events which are generated on certain database actions. Whenever a database object is created, updated, or deleted, a corresponding event is generated.
+
+#### Object Created
+
+When a new object is created in the database, an event is generated with the following event name: `<app>_<model>.created`, where `<model>` is the name of the model class (e.g. `part`, `stockitem`, etc).
+
+The event is called with the following keywords arguments:
+
+- `model`: The model class of the object that was created
+- `id`: The primary key of the object that was created
+
+**Example:**
+
+A new `Part` object is created with primary key `123`, resulting in the following event being generated:
+
+```python
+trigger_event('part_part.created', model='part', id=123)
+```
+
+### Object Updated
+
+When an object is updated in the database, an event is generated with the following event name: `<app>_<model>.saved`, where `<model>` is the name of the model class (e.g. `part`, `stockitem`, etc).
+
+The event is called with the following keywords arguments:
+
+- `model`: The model class of the object that was updated
+- `id`: The primary key of the object that was updated
+
+**Example:**
+
+A `Part` object with primary key `123` is updated, resulting in the following event being generated:
+
+```python
+trigger_event('part_part.saved', model='part', id=123)
+```
+
+### Object Deleted
+
+When an object is deleted from the database, an event is generated with the following event name: `<app>_<model>.deleted`, where `<model>` is the name of the model class (e.g. `part`, `stockitem`, etc).
+
+The event is called with the following keywords arguments:
+
+- `model`: The model class of the object that was deleted
+- `id`: The primary key of the object that was deleted (if available)
+
+**Example:**
+
+A `Part` object with primary key `123` is deleted, resulting in the following event being generated:
+
+```python
+trigger_event('part_part.deleted', model='part', id=123)
+```
+
+!!! warning "Object Deleted"
+    Note that the event is triggered *after* the object has been deleted from the database, so the object itself is no longer available.
+
+## Specific Events
+
+In addition to the *generic* events listed above, there are a number of other events which are triggered by *specific* actions within the InvenTree codebase.
+
+The available events are provided in the enumerations listed below. Note that while the names of the events are documented here, the exact arguments passed to the event handler will depend on the specific event being triggered.
+
+### Build Events
+
+::: build.events.BuildEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Part Events
+
+::: part.events.PartEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Stock Events
+
+::: stock.events.StockEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Purchase Order Events
+
+::: order.events.PurchaseOrderEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Sales Order Events
+
+::: order.events.SalesOrderEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Return Order Events
+
+::: order.events.ReturnOrderEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+### Plugin Events
+
+::: plugin.events.PluginEvents
+    options:
+        show_bases: False
+        show_root_heading: False
+        show_root_toc_entry: False
+        show_source: True
+        members: []
+
+## Samples
+
 ### Sample Plugin - All events

 Implementing classes must at least provide a `process_event` function:
@ -40,12 +185,3 @@ Overall this function can reduce the workload on the background workers signific
        show_root_toc_entry: False
        show_source: True
        members: []
-
-
-## Events
-
-Events are passed through using a string identifier, e.g. `build.completed`
-
-The arguments (and keyword arguments) passed to the receiving function depend entirely on the type of event.
-
-Implementing a response to a particular event requires a working knowledge of the InvenTree code base, especially related to that event being received.