diff --git a/docs/administration/management-commands.md b/docs/administration/management-commands.md index 8fe0f0a26..763a33511 100644 --- a/docs/administration/management-commands.md +++ b/docs/administration/management-commands.md @@ -28,8 +28,6 @@ python3 netbox/manage.py nbshell ## populate_image_sizes -!!! info "This command was introduced in NetBox v4.6.4." - Populate the cached file size for image attachments that predate the `image_size` field. Running this once after upgrading is recommended for deployments with many existing attachments on a remote storage backend (such as S3). It is safe to run on a live system and may be re-run; any file that cannot be read is skipped and retried on the next run. ``` diff --git a/docs/configuration/graphql-api.md b/docs/configuration/graphql-api.md index 3fed0482b..f1a1dce1e 100644 --- a/docs/configuration/graphql-api.md +++ b/docs/configuration/graphql-api.md @@ -2,8 +2,6 @@ ## GRAPHQL_DEFAULT_VERSION -!!! note "This parameter was introduced in NetBox v4.5." - Default: `1` Designates the default version of the GraphQL API served by `/graphql/`. To access a specific version, append the version number to the URL, e.g. `/graphql/v2/`. @@ -30,8 +28,6 @@ The maximum number of queries that a GraphQL API request may contain. ## GRAPHQL_MAX_QUERY_DEPTH -!!! note "This parameter was introduced in NetBox v4.6.1." - Default: `None` (no limit) The maximum allowed depth of any GraphQL query. When set to a positive integer, requests containing queries that exceed this depth will be rejected. Leaving this parameter unset (or setting it to `None` or `0`) disables query depth enforcement. diff --git a/docs/configuration/miscellaneous.md b/docs/configuration/miscellaneous.md index 9469257c3..ead4d402d 100644 --- a/docs/configuration/miscellaneous.md +++ b/docs/configuration/miscellaneous.md @@ -125,8 +125,6 @@ The maximum size (in bytes) of an incoming HTTP request (i.e. `GET` or `POST` da ## STREAMING_EXPORTS -!!! note "This parameter was introduced in NetBox v4.6." - Default: `False` When set to `True`, CSV bulk exports are returned as a streaming HTTP response, emitting rows to the client as they are rendered rather than buffering the entire dataset in memory first. This can significantly reduce memory usage and time-to-first-byte for very large exports. diff --git a/docs/configuration/required-parameters.md b/docs/configuration/required-parameters.md index b9a72518e..1ba3ac99d 100644 --- a/docs/configuration/required-parameters.md +++ b/docs/configuration/required-parameters.md @@ -25,8 +25,6 @@ ALLOWED_HOSTS = ['*'] ## API_TOKEN_PEPPERS -!!! info "This parameter was introduced in NetBox v4.5." - [Cryptographic peppers](https://en.wikipedia.org/wiki/Pepper_(cryptography)) are employed to generate hashes of sensitive values on the server. This parameter defines the peppers used to hash v2 API tokens in NetBox. You must define at least one pepper before creating a v2 API token. See the [API documentation](../integrations/rest-api.md#authentication) for further information about how peppers are used. ```python diff --git a/docs/configuration/security.md b/docs/configuration/security.md index 044e6c4a5..5a85e0437 100644 --- a/docs/configuration/security.md +++ b/docs/configuration/security.md @@ -168,9 +168,6 @@ Default: `True` When enabled, only authenticated users are permitted to access any part of NetBox. Disabling this will allow unauthenticated users to access most areas of NetBox (but not make any changes). -!!! info "Changed in NetBox v4.0.2" - Prior to NetBox v4.0.2, this setting was disabled by default. - --- ## LOGIN_TIMEOUT diff --git a/docs/configuration/system.md b/docs/configuration/system.md index 40c535792..6227dd446 100644 --- a/docs/configuration/system.md +++ b/docs/configuration/system.md @@ -86,8 +86,6 @@ Email is sent from NetBox only for critical events or if configured for [logging ## HOSTNAME -!!! info "This parameter was introduced in NetBox v4.4." - Default: System hostname The hostname displayed in the user interface identifying the system on which NetBox is running. If not defined, this defaults to the system hostname as reported by Python's `platform.node()`. @@ -96,8 +94,6 @@ The hostname displayed in the user interface identifying the system on which Net ## HTTP_CLIENT_IP_HEADERS -!!! info "This parameter was introduced in NetBox v4.6.1." - Default: ```python @@ -142,7 +138,7 @@ A list of IP addresses recognized as internal to the system, used to control the example, the debugging toolbar will be viewable only when a client is accessing NetBox from one of the listed IP addresses (and [`DEBUG`](./development.md#debug) is `True`). -!!! info "New in NetBox v4.6" +!!! info "Enabling the toolbar for all clients" Setting this parameter to an empty list will enable the toolbar for all requests provided debugging is enabled: ```python diff --git a/docs/features/context-data.md b/docs/features/context-data.md index 7b2ff9cec..9735458c9 100644 --- a/docs/features/context-data.md +++ b/docs/features/context-data.md @@ -93,7 +93,7 @@ A profile's schema may be authored directly in NetBox or populated from an exter ## Pre-rendered Caching -!!! info "New in NetBox v4.7" +!!! info "This feature was introduced in NetBox v4.7." NetBox pre-renders each device's and virtual machine's merged context data and stores it on the object itself, so most reads can return the result without recomputing the full set of applicable contexts. The cache is initially populated during upgrade (the upgrade script runs the `rebuild_config_context_cache` management command) and is thereafter kept current automatically: whenever an upstream change is detected — a config context being created, modified, or deleted; a device/VM's scope-relevant attribute changing (site, role, tenant, tags, cluster, etc.); or a related object being re-routed in a way that changes which contexts apply — NetBox marks the affected caches invalid and enqueues a non-blocking [background job](./background-jobs.md) to repopulate them. diff --git a/docs/features/cooling.md b/docs/features/cooling.md index a894a2d77..5b212ebd8 100644 --- a/docs/features/cooling.md +++ b/docs/features/cooling.md @@ -1,5 +1,7 @@ # Cooling +!!! info "This feature was introduced in NetBox v4.7." + As part of its DCIM feature set, NetBox supports modeling data center cooling infrastructure, from facility plant down to the coolant connections on individual devices. This is used to document liquid- and hybrid-cooled environments (chillers, cooling distribution units, manifolds, rear-door heat exchangers, and cold-plate servers) as a source of truth. ## Model Overview diff --git a/docs/features/resource-ownership.md b/docs/features/resource-ownership.md index a50984f5a..89aa47593 100644 --- a/docs/features/resource-ownership.md +++ b/docs/features/resource-ownership.md @@ -1,7 +1,5 @@ # Resource Ownership -!!! info "This feature was introduced in NetBox v4.5." - Most objects in NetBox can be assigned an owner. An owner is a set of users and/or groups who are responsible for the administration of associated objects. For example, you might designate the operations team at a site as the owner for all prefixes and VLANs deployed at that site. The users and groups assigned to an owner are referred to as its members. !!! note diff --git a/docs/integrations/graphql-api.md b/docs/integrations/graphql-api.md index a7f05ee0f..abb1dc12c 100644 --- a/docs/integrations/graphql-api.md +++ b/docs/integrations/graphql-api.md @@ -51,9 +51,6 @@ For more detail on constructing GraphQL queries, see the [GraphQL queries docume ## Filtering -!!! note "Changed in NetBox v4.3" - The filtering syntax fo the GraphQL API has changed substantially in NetBox v4.3. - Filters can be specified as key-value pairs within parentheses immediately following the query name. For example, the following will return only active sites: ``` @@ -139,8 +136,6 @@ The alternative approach is cursor-based pagination, which operates using absolu To ensure consistent ordering, objects will always be ordered by their primary keys when cursor-based pagination is used. -!!! note "Cursor-based pagination was introduced in NetBox v4.5.2." - Both pagination strategies support an optional `limit` parameter specifying the maximum number of objects to include in the response. The [`MAX_PAGE_SIZE`](../configuration/miscellaneous.md#max_page_size) configuration parameter (default `1000`) sets a hard ceiling on this value; if no limit is specified, up to `MAX_PAGE_SIZE` records are returned. When `MAX_PAGE_SIZE` is set to `0` or `None`: diff --git a/docs/integrations/rest-api.md b/docs/integrations/rest-api.md index c31d58212..bc179dd8a 100644 --- a/docs/integrations/rest-api.md +++ b/docs/integrations/rest-api.md @@ -253,8 +253,6 @@ Similarly, you can opt to omit only specific fields by passing the `omit` parame GET /api/dcim/sites/?omit=circuit_count,device_count,virtualmachine_count ``` -!!! note "The `omit` parameter was introduced in NetBox v4.5.2." - Strategic use of the `fields` and `omit` parameters can drastically improve REST API performance, as the exclusion of fields which reference related objects reduces the number and complexity of underlying database queries needed to generate the response. !!! note @@ -669,9 +667,27 @@ Note that there is no requirement for the attributes to be identical among objec !!! note The bulk update of objects is an all-or-none operation, meaning that if NetBox fails to successfully update any of the specified objects (e.g. due a validation error), the entire operation will be aborted and none of the objects will be updated. -### Concurrent Update Protection +### Errors in Bulk Operations -!!! info "This feature was introduced in NetBox v4.6." +!!! info "This feature was introduced in NetBox v4.7." + +When a bulk creation or update fails validation, the response identifies each offending object by its index within the submitted list, so that a client can correct and resubmit only the objects which actually failed. (The operation itself remains all-or-none: No objects are written unless every object validates.) + +```json +{ + "detail": "1 of 3 objects failed validation.", + "errors": [ + { + "index": 1, + "errors": { + "slug": ["This field may not be blank."] + } + } + ] +} +``` + +### Concurrent Update Protection To guard against the lost-update problem when multiple clients modify the same object, NetBox returns a weak `ETag` response header on detail-view responses (`GET`, `POST`, `PATCH`, `PUT`) for individual objects. Clients may supply this value back on a subsequent `PATCH` or `PUT` request via the `If-Match` request header. If the object's current ETag does not match any of the values supplied, the server rejects the request with a `412 Precondition Failed` response and includes the current ETag in the response so the client can retry. @@ -693,8 +709,6 @@ A literal `If-Match: *` value matches any current ETag and may be used to assert ### Adding and Removing Tags -!!! info "This feature was introduced in NetBox v4.6." - In addition to replacing an object's tag set wholesale via the `tags` field, taggable models accept two write-only fields, `add_tags` and `remove_tags`, which apply only the specified additions or removals without disturbing existing tags. This is convenient when concurrent clients each manage a distinct subset of an object's tags. ```no-highlight diff --git a/docs/models/dcim/cable.md b/docs/models/dcim/cable.md index 2fe16de79..f72493848 100644 --- a/docs/models/dcim/cable.md +++ b/docs/models/dcim/cable.md @@ -23,8 +23,6 @@ The cable's operational status. Choices include: ### Profile -!!! note "This field was introduced in NetBox v4.5." - The profile to which the cable conforms. The profile determines the mapping of termination between the two ends and enables logical tracing across complex connections, such as breakout cables. Supported profiles are listed below. * Straight (single position) diff --git a/docs/models/dcim/interface.md b/docs/models/dcim/interface.md index f6d6cf767..1f1741882 100644 --- a/docs/models/dcim/interface.md +++ b/docs/models/dcim/interface.md @@ -35,6 +35,8 @@ The type of interface. Interfaces may be physical or virtual in nature, but only ### Channels +!!! info "This field was added in NetBox v4.7." + For a channelized (breakout) interface, the number of physical channels into which the interface is divided. For example, a 40GE interface broken out into four 10GE channels would have `channels` set to four. Each channel is modeled as a channel subinterface bound to this interface via its [channel ID](#channel-id). A single physical cable terminates to the channelized (parent) interface, occupying one connector shared by all of its channels; NetBox traces a distinct cable path for each channel subinterface. Only one layer of channelization is supported: an interface cannot be both channelized and itself bound to a channel. @@ -55,7 +57,7 @@ The [virtual routing and forwarding](../ipam/vrf.md) instance to which this inte The [MAC address](./macaddress.md) assigned to this interface which is designated as its primary. -!!! note "Changed in NetBox v4.2" +!!! note "MAC address is a property" The MAC address of an interface (formerly a concrete database field) is available as a property, `mac_address`, which reflects the value of the primary linked [MAC address](./macaddress.md) object. ### WWN diff --git a/docs/models/dcim/module.md b/docs/models/dcim/module.md index 4573004cf..cbc16cbd7 100644 --- a/docs/models/dcim/module.md +++ b/docs/models/dcim/module.md @@ -6,6 +6,8 @@ Similar to devices, modules are instantiated from [module types](./moduletype.md ## Moving Modules +!!! info "This feature was introduced in NetBox v4.7." + An installed module can be moved to a different module bay after creation. The destination bay must be enabled and unoccupied. Moving a module relocates its entire subtree: the components installed by the module, the module bays belonging to it, and any child modules installed within those bays. Component names, labels, and module bay positions derived from the module type's templates (for example, names containing `{module}`) are re-resolved for the destination bay. A component is renamed only when its current name matches exactly one of the module type's templates as resolved for the source bay; components whose names do not match any template resolution (including manually renamed components) are preserved as-is. All resulting names are validated against the destination device before the move is applied. A move is rejected when a template-derived name, label, or position would exceed the destination field's maximum length. A move is also rejected when a component's current value matched a template for the source bay but that template cannot be resolved for the destination bay's nesting depth. diff --git a/docs/models/dcim/modulebaytype.md b/docs/models/dcim/modulebaytype.md index 7652ebecb..c86ef1964 100644 --- a/docs/models/dcim/modulebaytype.md +++ b/docs/models/dcim/modulebaytype.md @@ -1,5 +1,7 @@ # Module Bay Types +!!! info "This feature was introduced in NetBox v4.7." + Module bay types are user-defined labels that can be assigned to [module bays](./modulebay.md) and [module types](./moduletype.md) to restrict which modules may be installed into which bays. This is useful for modeling chassis hardware where not every bay accepts every type of line card. When **both** a module bay and the module type being installed have at least one bay type assigned, NetBox will check for a non-empty intersection. If the two sets share no bay types in common, the installation will be rejected as incompatible. diff --git a/docs/models/dcim/platform.md b/docs/models/dcim/platform.md index 3400294e6..60a57894c 100644 --- a/docs/models/dcim/platform.md +++ b/docs/models/dcim/platform.md @@ -12,8 +12,6 @@ The assignment of platforms to devices and virtual machines is optional. ## Parent -!!! "This field was introduced in NetBox v4.4." - The parent platform class to which this platform belongs (optional). ### Name diff --git a/docs/models/ipam/iprange.md b/docs/models/ipam/iprange.md index 760dde699..e242c07ed 100644 --- a/docs/models/ipam/iprange.md +++ b/docs/models/ipam/iprange.md @@ -44,8 +44,6 @@ The IP range's operational status. Note that the status of a range does _not_ ha ### Mark Populated -!!! note "This field was added in NetBox v4.3." - If enabled, NetBox will treat this IP range as being fully populated when calculating available IP space. It will also prevent the creation of IP addresses which fall within the declared range (and assigned VRF, if any). ### Mark Utilized diff --git a/docs/models/ipam/service.md b/docs/models/ipam/service.md index 50579ce6b..3bd4a2237 100644 --- a/docs/models/ipam/service.md +++ b/docs/models/ipam/service.md @@ -4,9 +4,8 @@ An application service represents a layer seven application available on a devic To aid in the efficient creation of application services, users may opt to first create an [application service template](./servicetemplate.md) from which service definitions can be quickly replicated. -!!! note "Changed in NetBox v4.4" - - Previously, application services were referred to simply as "services". The name has been changed in the UI to better reflect their intended use. There is no change to the name of the model or in any programmatic NetBox APIs. +!!! note "Naming" + Application services are referred to simply as "services" in the name of the model and throughout NetBox's programmatic APIs. Only the UI uses the longer name, which better reflects their intended use. ## Fields @@ -15,10 +14,6 @@ To aid in the efficient creation of application services, users may opt to first The parent object to which the application service is assigned. This must be one of [Device](../dcim/device.md), [VirtualMachine](../virtualization/virtualmachine.md), or [FHRP Group](./fhrpgroup.md). -!!! note "Changed in NetBox v4.3" - - Previously, `parent` was a property that pointed to either a Device or Virtual Machine. With the capability to assign services to FHRP groups, this is a unified in a concrete field. - ### Name A service or protocol name. diff --git a/docs/models/ipam/servicetemplate.md b/docs/models/ipam/servicetemplate.md index 84d0bf80b..0c9090377 100644 --- a/docs/models/ipam/servicetemplate.md +++ b/docs/models/ipam/servicetemplate.md @@ -2,9 +2,9 @@ Application service templates can be used to instantiate [application services](./service.md) on [devices](../dcim/device.md) and [virtual machines](../virtualization/virtualmachine.md). -!!! note "Changed in NetBox v4.4" +!!! note "Naming" - Previously, application service templates were referred to simply as "service templates". The name has been changed in the UI to better reflect their intended use. There is no change to the name of the model or in any programmatic NetBox APIs. + Application service templates are referred to simply as "service templates" in the name of the model and throughout NetBox's programmatic APIs. Only the UI uses the longer name, which better reflects their intended use. ## Fields diff --git a/docs/models/virtualization/virtualmachine.md b/docs/models/virtualization/virtualmachine.md index f8786796c..001f37659 100644 --- a/docs/models/virtualization/virtualmachine.md +++ b/docs/models/virtualization/virtualmachine.md @@ -46,9 +46,6 @@ The location or host for this VM. At least one must be specified: - **Device only**: The VM runs directly on a physical host device without a cluster (e.g. containers). The site is automatically inferred from the device's site. - **Cluster + Device**: The VM belongs to a cluster and is pinned to a specific host device within that cluster. The device must be a registered host of the assigned cluster. -!!! info "New in NetBox v4.6" - Virtual machines can now be assigned directly to a device without requiring a cluster. This is particularly useful for modeling VMs running on standalone hosts outside of a cluster. - ### Platform A VM may be associated with a particular [platform](../dcim/platform.md) to indicate its operating system. If a virtual machine type defines a default platform, it will be applied when the VM is created unless an explicit platform is specified. diff --git a/docs/models/virtualization/vminterface.md b/docs/models/virtualization/vminterface.md index 726060c05..d4b54d332 100644 --- a/docs/models/virtualization/vminterface.md +++ b/docs/models/virtualization/vminterface.md @@ -31,7 +31,7 @@ If not selected, this interface will be treated as disabled/inoperative. The [MAC address](../dcim/macaddress.md) assigned to this interface which is designated as its primary. -!!! note "Changed in NetBox v4.2" +!!! note "MAC address is a property" The MAC address of an interface (formerly a concrete database field) is available as a property, `mac_address`, which reflects the value of the primary linked [MAC address](../dcim/macaddress.md) object. ### MTU diff --git a/docs/plugins/development/background-jobs.md b/docs/plugins/development/background-jobs.md index d225c414a..192fdae8f 100644 --- a/docs/plugins/development/background-jobs.md +++ b/docs/plugins/development/background-jobs.md @@ -41,8 +41,6 @@ This is the human-friendly names of your background job. If omitted, the class n ### Logging -!!! info "This feature was introduced in NetBox v4.4." - A Python logger is instantiated by the runner for each job. It can be utilized within a job's `run()` method as needed: ```python diff --git a/docs/plugins/development/config-templates.md b/docs/plugins/development/config-templates.md index 61a4b5067..8f8bb2477 100644 --- a/docs/plugins/development/config-templates.md +++ b/docs/plugins/development/config-templates.md @@ -1,5 +1,7 @@ # Jinja Config Templates +!!! info "This feature was introduced in NetBox v4.7." + NetBox uses [Jinja](https://jinja.palletsprojects.com/) to render [configuration templates](../../features/configuration-rendering.md). Plugins can extend this rendering pipeline in two complementary ways: 1. **Register custom filters** — make new template filters available by name in every config template. diff --git a/docs/plugins/development/event-rule-actions.md b/docs/plugins/development/event-rule-actions.md index f795ffa02..2be9bccd6 100644 --- a/docs/plugins/development/event-rule-actions.md +++ b/docs/plugins/development/event-rule-actions.md @@ -1,5 +1,7 @@ # Event Rule Actions +!!! info "This feature was introduced in NetBox v4.7." + [Event rules](../../models/extras/eventrule.md) dispatch to an *action* when a matching event occurs, such as sending a webhook request or running a script. Plugins can register their own action types to extend the list of actions an event rule can perform, by subclassing NetBox's `EventRuleAction` class. ```python title="event_rules.py" diff --git a/docs/plugins/development/filtersets.md b/docs/plugins/development/filtersets.md index 36e6346c5..ca0947122 100644 --- a/docs/plugins/development/filtersets.md +++ b/docs/plugins/development/filtersets.md @@ -6,8 +6,7 @@ Filter sets define the mechanisms available for filtering or searching through a To support additional functionality standard to NetBox models, such as tag assignment and custom field support, the `NetBoxModelFilterSet` class is available for use by plugins. This should be used as the base filter set class for plugin models which inherit from `NetBoxModel`. Within this class, individual filters can be declared as directed by the `django-filters` documentation. An example is provided below. -!!! info "New in NetBox v4.5: FilterSet Registration" - NetBox v4.5 introduced the `register_filterset()` utility function. This enables plugins to register their filtersets to receive advanced functionality, such as the automatic attachment of field-specific lookup modifiers on the filter form. Registration is optional: Unregistered filtersets will continue to work as before, but will not receive the enhanced functionality. +The `register_filterset()` utility function enables plugins to register their filtersets to receive advanced functionality, such as the automatic attachment of field-specific lookup modifiers on the filter form. Registration is optional: Unregistered filtersets will continue to work as before, but will not receive the enhanced functionality. ```python # filtersets.py diff --git a/docs/plugins/development/forms.md b/docs/plugins/development/forms.md index d5488c3a3..227ffa506 100644 --- a/docs/plugins/development/forms.md +++ b/docs/plugins/development/forms.md @@ -212,6 +212,8 @@ In addition to the [form fields provided by Django](https://docs.djangoproject.c ## Static Choice Fields +!!! info "This feature was introduced in NetBox v4.7." + These fields render a standard HTML `