id: 123 becomes id: {exact: 123 }.render_config permission for the applicable object type.ALLOW_TOKEN_RETRIEVAL config parameter has been removed./api/dcim/cable-terminations/ REST API endpoint is now read-only. Cable terminations must be set on cables directly via the /api/dcim/cables/ endpoint.is_staff has been removed from the User model./api/extras/object-types/ REST API endpoint has been removed. (Use /api/core/object-types/ instead.)model in payload data. (Reference object_type instead, which includes the parent app label.)core.models.contenttypes has been removed (replaced in v4.4 by core.models.object_types).load_yaml() and load_json() utility methods have been removed from the base class for custom scripts.Most object list filters within the UI have been extended to include optional lookup modifiers to support more complex queries. For instance, filters for numeric values now include a dropdown where a user can select "less than," "greater than," or "not" in addition to the default equivalency match. The specific modifiers available depend on the type of each filter. Plugins can register their own filtersets using the register_filterset() decorator to enable this new functionality.
(Note that this feature does not introduce any new filters. Rather, it makes available in the UI filters which already exist.)
This release introduces a new version of API token (v2) which implements several security improvements. HMAC hashing with a cryptographic pepper is used to authenticate these tokens, obviating the need to store plaintexts. The new tokens also employ a non-sensitive key which can be shared to identify tokens without divulging their plaintexts. We've also adopted the standard "bearer" HTTP header format, as shown below.
# v1 token header
Authorization: Token <TOKEN>
# v2 token header
Authorization: Bearer nbt_<KEY>.<TOKEN>
Note that v2 token keys are prefixed with the fixed string nbt_, which can be used to aid in secret detection.
Backward compatibility with legacy (v1) tokens is retained in this release. However, users are strongly encouraged to begin using only v2 tokens, as support for legacy tokens will be removed in NetBox v4.7.
An optional owner foreign key field has been added to most models. This enables the assignment of objects to a new Owner model, which represents a set of users and/or groups. Through this relationship, we can now convey ownership of objects within NetBox natively, without needing to rely on the assignment of tags or custom fields.
(Note that ownership differs significantly in function from tenancy. Ownership determines the parties responsible for the maintenance of an object, whereas as tenancy conveys an operational dependency.)
The previous many-to-one mapping of front to rear ports has been expanded to support bidirectional mappings. The rear_port and rear_port_position fields on the FrontPort model have been replaced with an intermediary PortMapping model, which supports any number of assignments between front port/position pair and a rear port/position pair. This change unlocks the ability to model complex inline devices that swap individual fiber pairs between cables.
Cables can now be assigned profiles which determine how they are treated for path tracing. A profile indicates the number of discrete parallel channels or lanes carried by the cable among its endpoints. For example, a 1-to-4 breakout cable has four lanes, shared at one end via a common termination and split out at the other end to four separate terminations. Profiles, when assigned, enable NetBox to more accurately trace a specific connection within a cable, rather than the cable as a whole.
The assignment of cable profiles is optional: Cable tracing will continue to operate as before for cables with no profile assigned.
render_config permission, which is now required to render a device or virtual machine configurationstart_on_boot choice field for virtual machinescolor field for device type power outletsALLOW_TOKEN_RETRIEVAL config parameter)enabled boolean field to API tokenscomments field to all subclasses of OrganizationalModelrender_config permission to view a rendered device/VM configuration in the UI/api/authentication-check/ REST API endpoint for validating authentication tokensPrimaryModel, OrganizationalModel, and NestedGroupModel to the plugins API, as well as their respective base classes for various resourcesis_staff from the User modelGFKSerializerField for representing generic foreign keys in API serializers/api/extras/object-types/model key from webhook payload datacore.models.contenttypesload_yaml() and load_json() utility methods from the BaseScript classBaseModel as the global base class for modelsowner foreign key field./api/dcim/cable-terminations endpoint is now read-only./api/authentication-check/ endpoint to test REST API credentialscircuits.CircuitGroup
comments fieldcircuits.CircuitType
comments fieldcircuits.VirtualCircuitType
comments fielddcim.Cable
profile choice fielddcim.FrontPort
rear_port and rear_port_position fieldspositions integer fieldrear_ports list for port mappingsdcim.InventoryItemRole
comments fielddcim.Manufacturer
comments fieldmoduletype_count integer fielddcim.ModuleType
module_count integer fielddcim.PowerOutletTemplate
color fielddcim.RackRole
comments fielddcim.RackType
rack_count integer fielddcim.RearPort
front_ports list for port mappingsipam.ASNRange
comments fieldipam.RIR
comments fieldipam.Role
comments fieldipam.VLANGroup
comments fieldtenancy.ContactRole
comments fieldusers.Token
enabled boolean fieldvirtualization.ClusterGroup
comments fieldvirtualization.ClusterType
comments fieldvirtualization.VirtualMachine
start_on_boot choice fieldvpn.TunnelGroup
comments field