[Refactor] Stock tracking audit (#13101)

* Add "event_type" and "notes" support to AuditLog model

* Register history entries for stock items

* record stock edited events as normal updates

* Remove legacy tracking entry generation code

* Updated unit tests for all stock event types

* remove legacy endpoints

* remove legacy tables from UI

* Updated docs

* Data migration

* Remove old models

* Update docs

* Updated playwright tests

* Fix broken links

* Update CHANGELOG.md

* Cache CID value

* Fix migration tests

* Increase query threshold for unit test

* Fix bug and add regression test

* mark migration as one-way

* flush events in the correct order

* improve prefetch

* Adjust row rendering

docs/docs/concepts/audit.md

@@ -36,7 +36,6 @@ To keep the audit log focused and performant, some changes are intentionally *no
 
 - **Derived fields** - Internal or calculated fields (such as tree structure fields, cached pricing values and metadata) are excluded.
 - **Data import** - Changes made using the [data import](./data_import.md) tool are not recorded.
-- **Stock items** - Changes to stock items are tracked separately using [stock tracking](../stock/tracking.md).
 - **Unsupported models** - Only the models listed below are audited.
 
 ### Audited Models
@@ -45,6 +44,21 @@ The following models are currently audited. Where a model has a *parent*, change
 
 {{ audited_models() }}
 
+### Events
+
+Some models record named *events* in the audit log, in addition to field changes. An event describes *what happened* to an item (for example, an operation which affects multiple fields, or multiple items), and may include:
+
+- **Event type** - The type of event (displayed in place of the action in the audit log table)
+- **Notes** - Optional notes provided by the user when the event was recorded
+- **Deltas** - Additional information about the event, such as quantities or references to related objects. References to related objects are recorded as they were at the time of the event.
+
+An event may be recorded even if no fields of the item were changed.
+
+For example, stock operations (such as moving, counting or shipping stock) are recorded as [stock tracking](../stock/tracking.md) events against each affected stock item.
+
+!!! warning "Disabling the Audit Log"
+    Events are recorded in the audit log, and are subject to the same settings as all other audit entries. If the audit log is disabled, events are **not** recorded - this includes **all stock tracking history**.
+
 ### Viewing Change History
 
 #### Detail Pages
@@ -60,9 +74,10 @@ For example, the history panel for a purchase order shows changes made to the or
 The *History* panel is only displayed if **all** of the following conditions are met:
 
 - The audit log is enabled (via the `Enable Audit Log` system setting)
-- The user is a *staff* user
 - The user has enabled the *Show Change History* user setting
 
+The entries displayed in the *History* panel are filtered by the permissions of the user (see [Permissions](#permissions) below).
+
 {{ image("concepts/audit_user_setting.png", "Show change history setting") }}
 
 #### Admin Center
@@ -79,10 +94,12 @@ The audit log table can be filtered by action, user, date range and model type:
 
 Access to the audit log is restricted:
 
-- The audit log (including the `/api/audit/` API endpoint) is only available to *staff* users.
-- Audit entries are additionally filtered by the user's [role permissions](../settings/permissions.md). A user can only view audit entries for models which they have permission to view.
+- Audit entries are filtered by the user's [role permissions](../settings/permissions.md). A user can only view audit entries for models which they have permission to view.
 - Some models (e.g. attachments and parameters) require the user to also have permission to view the *parent* model.
+- The history of some models (e.g. global settings) is only available to *staff* users.
 - The remote IP address associated with each entry is only visible to staff users.
+- References to related objects (recorded against [events](#events)) are hidden if the user does not have permission to view the related model.
+- The *Audit Log* panel in the Admin Center is only available to staff users.
 
 ### Data Retention
 

docs/docs/manufacturing/output.md

@@ -41,7 +41,7 @@ The following options are available when creating a new build output:
 
 ### Specifying Serial Numbers
 
-Refer to the [serial number generation guide](../stock/tracking.md#generating-serial-numbers) for further information on serial number input.
+Refer to the [serial number generation guide](../stock/traceability.md#generating-serial-numbers) for further information on serial number input.
 
 ### Creating Outputs Without Serial Numbers
 

docs/docs/plugins/mixins/validation.md

@@ -150,7 +150,7 @@ Validation of the Part IPN (Internal Part Number) field is exposed to custom plu
 
 ### Batch Codes
 
-[Batch codes](../../stock/tracking.md#batch-codes) can be generated and/or validated by custom plugins.
+[Batch codes](../../stock/traceability.md#batch-codes) can be generated and/or validated by custom plugins.
 
 #### Validate Batch Code
 
@@ -184,7 +184,7 @@ The `generate_batch_code` method can be implemented to generate a new batch code
 
 Requirements for serial numbers can vary greatly depending on the application. Rather than attempting to provide a "one size fits all" serial number implementation, InvenTree allows custom serial number schemes to be implemented via plugins.
 
-The default InvenTree [serial numbering system](../../stock/tracking.md#serial-numbers) uses a simple algorithm to validate and increment serial numbers. More complex behaviors can be implemented using the `ValidationMixin` plugin class and the following custom methods:
+The default InvenTree [serial numbering system](../../stock/traceability.md#serial-numbers) uses a simple algorithm to validate and increment serial numbers. More complex behaviors can be implemented using the `ValidationMixin` plugin class and the following custom methods:
 
 #### Serial Number Validation
 

docs/docs/sales/return_order.md

@@ -145,7 +145,7 @@ Receiving a line item performs the following actions on the underlying stock ite
 * Sets the stock item status (defaulting to *Quarantined*)
 * Removes the *Customer* reference from the stock item
 * Clears any outstanding sales order allocations against the stock item
-* Adds a tracking entry recording the return
+* Records a [stock tracking](../stock/tracking.md) event for the return
 
 !!! info "Partial Returns"
     If a customer returns less than the full quantity of a non-serialized stock item, InvenTree automatically splits the returned quantity into a new stock item, leaving the remainder of the original stock item untouched (e.g. still recorded as sold to the customer).

docs/docs/stock/adjust.md

@@ -12,7 +12,7 @@ Stock adjustments can be accessed in any stock items table using the "Stock Opti
 
 ### Move Stock
 
-Multiple stock items can be moved to a new location in a single operation. Each item is moved to the selected location, and a stock tracking entry is added to the stock item history.
+Multiple stock items can be moved to a new location in a single operation. Each item is moved to the selected location, and a [stock tracking](./tracking.md) event is recorded against each stock item.
 
 {{ image("stock/stock_move.png", "Stock Move") }}
 

docs/docs/stock/disassemble.md

@@ -44,7 +44,7 @@ The original stock item is never deleted as a result of disassembly - its quanti
 If the stock item being disassembled has other stock items [installed](../manufacturing/allocate.md#allocating-tracked-stock) within it (for example, tracked components that were installed during a build order), these installed items **must** be accounted for during disassembly:
 
 - Each installed item is matched against a BOM line item, based on the component part (including any [substitute](../manufacturing/bom.md#substitute-bom-line-items) or [variant](../part/index.md#assembly) parts allowed for that line)
-- Matched installed items are *uninstalled* directly, rather than being discarded and re-created - this preserves the original stock item, including its own tracking history, batch code, and purchase price
+- Matched installed items are *uninstalled* directly, rather than being discarded and re-created - this preserves the original stock item, including its own stock tracking history, batch code, and purchase price
 - The quantity requested for the matching BOM line is reduced by the quantity already covered by the installed item(s). A new stock item is only created for any remaining quantity - if the installed items fully cover the required quantity, no new stock item is created for that line
 - Any installed item which does *not* match one of the selected BOM lines is still uninstalled (it cannot be left "installed" inside a smaller or non-existent parent), but its quantity is **not** subtracted from any line
 
@@ -65,10 +65,10 @@ If the original stock item has a recorded purchase price, and no explicit *Unit
 
 Disassembling a stock item generates a full audit trail:
 
-- A `Disassembled into components` entry is added to the tracking history of the original stock item
-- Each newly created component stock item receives a `Created from disassembly` tracking entry, referencing the original stock item
+- A `Disassembled into components` event is added to the [stock tracking history](./tracking.md) of the original stock item
+- Each newly created component stock item records a `Created from disassembly` event, referencing the original stock item
 - The *batch code* and source *purchase order* of the original stock item are copied directly to each generated component
-- If the original stock item was generated by a build order, that build order cannot be directly copied to the new component (since the component was not actually built by that order) - instead, it is recorded as a reference within the `Created from disassembly` tracking entry
+- If the original stock item was generated by a build order, that build order cannot be directly copied to the new component (since the component was not actually built by that order) - instead, it is recorded as a reference within the `Created from disassembly` event
 
 ### Purchasing Bundled Items
 

docs/docs/stock/index.md

@@ -44,9 +44,9 @@ Refer to the [traceability](./traceability.md) page for more information on how
 
 ## Stock Tracking
 
-Every time a *Stock Item* is adjusted, a *Stock Tracking* entry is automatically created. This ensures a complete history of the *Stock Item* is maintained as long as the item is in the system.
+Every time a *Stock Item* is adjusted, a stock tracking event is automatically recorded in the [audit log](../concepts/audit.md). This ensures a complete history of the *Stock Item* is maintained.
 
-Each stock tracking historical item records the user who performed the action. [Read more about stock tracking here](./tracking.md).
+Each stock tracking event records the user who performed the action. [Read more about stock tracking here](./tracking.md).
 
 ## Stock Locations
 

docs/docs/stock/tracking.md

@@ -4,47 +4,56 @@ title: Stock Tracking
 
 ## Stock Tracking
 
-Stock tracking entries record the history of stock item adjustments, including the user who performed the action, the date of the action, and the quantity change. This allows users to maintain a complete history of stock item movements and adjustments over time.
+Stock tracking records the history of stock item adjustments, including the user who performed the action, the date of the action, and the changes made to the stock item (e.g. quantity or location). This allows users to maintain a complete history of stock item movements and adjustments over time.
+
+Stock tracking history is recorded in the [audit log](../concepts/audit.md) - each stock operation is recorded as a named [event](../concepts/audit.md#events) against each affected stock item.
 
 ### Tracking Events
 
-Stock tracking entries are created automatically whenever a stock item is adjusted, either through manual adjustments or through automated processes such as order fulfillment or build completion.
+Stock tracking events are recorded automatically whenever a stock item is adjusted, either through manual adjustments or through automated processes such as order fulfillment or build completion.
 
-Some examples of events that may trigger stock tracking entries include:
+Some examples of operations that record stock tracking events include:
 
 - Manual stock adjustments (e.g. correcting inventory counts)
 - Creation of new stock items (e.g. receiving new inventory)
 - Allocation of stock items to orders (e.g. shipping items against sales orders)
 - Consumption of stock items during build processes (e.g. using items to complete a build order)
 
-### Tracking Entry Types
+### Tracking Event Types
 
-Each stock tracking entry records a specific *type*, indicating which event triggered it:
+Each stock tracking event records a specific *type*, indicating which operation triggered it:
 
 {{ statuscodes("StockHistoryCode") }}
 
+!!! info "Legacy Event Types"
+    The *Legacy stock tracking entry*, *Edited stock item* and *Assigned serial number* event types are only present in stock history recorded by older versions of InvenTree. Edits to a stock item (e.g. changing the status) are now recorded as regular updates in the audit log, and serial numbers are recorded as part of the creation of the stock item.
+
 ## Viewing Stock Tracking History
 
-There are multiple ways to view the stock tracking history for a particular stock item or part via the user interface.
+Stock tracking events are recorded in the [audit log](../concepts/audit.md), along with any other changes made to a stock item. Each event records the user who performed the action, any notes provided, and additional information about the event (such as the quantity added or removed, or the order which the item was received against).
 
-### Stock Item Tracking History
+!!! warning "Audit Log Required"
+    Stock tracking history is recorded in the audit log. If the audit log is disabled (via the `Enable Audit Log` system setting), **no stock tracking history is recorded**. Refer to the [audit log documentation](../concepts/audit.md#settings) for more information.
 
-The stock tracking history for a particular stock item can be viewed on the *Stock Item Detail* page, under the *Stock Tracking* tab:
+### Stock Item History
 
-{{ image("stock/stock_item_tracking_history.png", title="Stock tracking tab") }}
+The stock tracking history for a particular stock item is displayed in the *History* panel of the *Stock Item Detail* page:
 
-This view displays all tracking entries associated with the particular stock item.
+{{ image("stock/stock_item_history.png", "Stock item history") }}
 
-### Part Tracking History
+Each entry displays the type of event, along with any changes made to the stock item, and any additional information recorded against the event (such as notes, quantities, or links to related orders and stock items).
 
-Additionally, the stock tracking history for a particular part can be viewed on the *Part Detail* page, under the *Stock History* tab:
+### Part History
 
-{{ image("stock/part_tracking_history.png", title="Part stock tracking history") }}
+The history of all stock items for a particular part is displayed in the *History* panel of the *Part Detail* page, along with any changes made to the part itself:
 
-This view displays all tracking entries associated with any stock item linked to the particular part.
+{{ image("stock/part_stock_history.png", "Part stock history") }}
+
+!!! info "Show Change History"
+    The *History* panel is only displayed if the *Show Change History* user setting is enabled. Refer to the [audit log documentation](../concepts/audit.md#viewing-change-history) for more information.
 
 !!! info "Deleted Stock Items"
-    Even if a stock item is deleted from the system, the associated stock tracking entries are retained for historical reference. They will be visible in the part tracking history, but not in the stock item tracking history (as the stock item itself has been deleted).
+    Even if a stock item is deleted from the system, the associated history is retained for historical reference. It is visible in the history of the part, but not in the history of the stock item (as the stock item itself has been deleted).
 
 ## Installed Stock Items
 
@@ -73,9 +82,7 @@ Additionally, installed items are automatically uninstalled when the parent item
 
 ## Stock Tracking Settings
 
-There are a number of configuration options available for controlling the behavior of stock tracking functionality in the [system settings view](../settings/global.md):
+Stock tracking history is recorded in the audit log, and is subject to the [audit log settings](../concepts/audit.md#settings). For example, old stock tracking history can be automatically removed using the {{ globalsetting("AUDIT_LOG_DELETE_OLD_ENTRIES", short=True) }} setting.
 
-| Name | Description | Default | Units |
-| ---- | ----------- | ------- | ----- |
-{{ globalsetting("STOCK_TRACKING_DELETE_OLD_ENTRIES") }}
-{{ globalsetting("STOCK_TRACKING_DELETE_DAYS") }}
+!!! info "Audit Log Retention"
+    The *Delete Old Stock Tracking Entries* and *Stock Tracking Deletion Interval* settings have been removed. The retention of stock tracking history is now controlled by the audit log settings.