v1.4 Alpha, Beta, Release Candidate Feedback

[bryanculver]

👋

Thank you for checking out our alpha and beta releases of v1.4! We're excited to hear what you think about another great release.

Please feel free to comment below on any questions you may have pertaining to v1.4, either in general or the alphas and betas specifically.

If you do happen to catch a bug in any version, do not hesitate to open a bug 🐛.

Releases

• v1.4.0-alpha.1 (2022-06-13)
• v1.4.0-alpha.2 (2022-07-12)
• v1.4.0-beta.1 (2022-07-30)
• v1.4.0-rc.1 (2022-08-10)

Release Overview

Added

Custom Field Slugs (#1962)

Custom fields now have a distinct slug field. The custom field name attribute should be considered deprecated, and will be removed in a future major release (see also #824.) Additionally, the label attribute, while currently optional in the database, will become mandatory in that same future release as a consequence. When migrating from an earlier Nautobot release to version 1.4 or later, the slug and label for all existing custom fields will be automatically populated if not previously defined.

A new version of the /api/extras/custom-fields/ REST API endpoints has been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior (name required, slug and label optional; if unspecified, the slug and label will receive default values based on the provided name). A REST API client can request API version 1.4, in which case the updated API will require slug and label parameters in place of name.

Additionally, REST API serialization of custom field data is itself now versioned. For all object endpoints that include custom field data under the custom_fields key, REST API versions 1.3 and earlier will continue the previous behavior of indexing the custom_fields dictionary by fields' name values, but when REST API version 1.4 or later is requested, the custom_fields data will be indexed by slug instead.

For technical reasons of backwards-compatibility, the database (ORM) and GraphQL interfaces continue to access and store object custom field data exclusively under the name key; this will change to use the slug in a future major release. Again, watch #824 for plans in that regard.

Custom Template (CSS, HTML, JavaScript) on Job Forms (#1865)

Jobs can now specify a template_name property and provide a custom template with additional JavaScript and CSS to help with user input on the Job submission form.

You can refer to the Job class metadata attribute documentation on how to build and define this template.

Dark Mode UI (#729)

Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.

The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage.

Improved Filter Coverage for DCIM, Virtualization Models

• DCIM: #1729
• Virtualization: #1735

The DCIM, Virtualization FilterSets have been updated with over 150 new filters, including hybrid filters that support filtering on both pk and slug (or pk and name where slug is not available). A new filter class NaturalKeyOrPKMultipleChoiceFilter was added to nautobot.utilities.filters to support filtering on multiple fields of a related object. See the Best Practices documentation for more information.

Job Hooks (#2103)

Jobs can now be configured to run automatically when a change event occurs on a Nautobot object. Job hooks associate jobs to content types and actions to run jobs when a create, update or delete action occurs on the selected content type. A new job base class JobHookReceiver was introduced that jobs must subclass to be associated with a job hook. See the Job Hooks documentation for more information.

Job Re-Runs (#1875)

JobResult records now save the arguments with which the Job was called, allowing for easy re-execution of the Job with the same arguments as before. A "re-run" button has been added to the JobResult list view and detail view.

Location Data Model (#1052)

To locate network information more precisely than a Site defines, you can now define a hierarchy of Location Types (for example, Building ← Floor ← Room) and then create Locations corresponding to these types within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to Location representing a specific building, wing, floor, room, etc. as appropriate to your needs.

Info:
At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.

Object Detail Tabs (#1000)

A plugin may now define extra tabs which will be appended to the object view's list of tabs.

You can refer to the plugin development guide on how to add tabs to existing object detail views.

Parent Interfaces and Bridge Interfaces (#1455)

Interface and VMInterface models now have parent_interface and bridge keys. An interface of type Virtual can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge interface type has also been added, but the bridge interface property is not restricted to interfaces of this type.)

Rackview UI - Add Option to Truncate Device Name (#1119)

Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py via defining UI_RACK_VIEW_TRUNCATE_FUNCTION. Default behavior is to split on . and return the first item in the list.

"Save SVG" link presents the same view as what is currently displayed on screen

Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.

REST API Enhancements (#1463)

• For all models that support Relationships, their corresponding list and detail REST API endpoints now include the option to include data on their associated Relationships and related objects by specifying include=relationships as a query parameter.
• Relationship associations on a model can be edited by a PATCH to the appropriate nested value, such as "relationships" -> <relationship-slug> -> "source" or "relationships" -> <relationship-slug> -> "destination".
• For implementers of REST API serializers (core and/or plugins), a new nautobot.extras.api.serializers.NautobotModelSerializer base class has been added. Using this class guarantees support for relationships, custom fields, and computed fields on the serializer, and provides for a streamlined developer experience.

Status Field on Interface, VMInterface Models (#984)

Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".

A new version of the /dcim/interfaces/* REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".

Visit the documentation on REST API versioning for more information on using the versioned APIs.

Notes (#767)

Primary and Organizational models now support notes. A notes tab has been added to the Object Detail view for all models that inherit the Primary or Organizational base abstract models.

Warning:
Any plugin that inherits from one of these two models and uses the ViewTestCases.PrimaryObjectViewTestCase or ViewTestCases.OrganizationalObjectViewTestCase for their test will need to add the NotesObjectView to the objects URLs. See Plugin Development for more details.

Notes can also be used via the REST API at endpoint /api/extras/notes or per object at the object's /notes endpoint.

Info:
For implementers of REST API views (core and/or plugins), a new nautobot.extras.api.views.NautobotModelViewSet base class has been added. Use of this class ensures that all features from PrimaryModel or OrganizationalModel are accessible through the API. This includes custom fields and notes.

Changed

Dynamic Groups of Dynamic Groups (#1614)

Dynamic Groups may now be nested in parent/child relationships. The Dynamic Group edit view now has a "Child Groups" tab that allows one to make other Dynamic Groups of the same content type children of the parent group. Any filters provided by the child groups are used to filter the members from the parent group using one of three operators: "Restrict (AND)", "Include (OR)", or "Exclude (NOT)". This allows for logical parenthetical grouping of nested groups by the operator you choose for that child group association to the parent.

Warning:
The default behavior of Dynamic Groups with an empty filter ({}) has been inverted to include all objects matching the content type by default instead of matching no objects. This was necessary to implement the progressive layering of child filters similarly to how we use filters to reduce desired objects from basic list view filters.

Renamed Mixin Classes (#2135)

A number of mixin classes have been renamed for improved self-consistency and clarity of usage. The former names of these mixins are still available for now as aliases, but inheriting from these mixins will raise a DeprecationWarning, and these aliases will be removed in a future major release.

Former Name	New Name
AddRemoveTagsForm	TagsBulkEditFormMixin
CustomFieldBulkCreateForm	CustomFieldModelBulkEditFormMixin
CustomFieldBulkEditForm	CustomFieldModelBulkEditFormMixin
CustomFieldFilterForm	CustomFieldModelFilterFormMixin
CustomFieldModelForm	CustomFieldModelFormMixin
RelationshipModelForm	RelationshipModelFormMixin
StatusBulkEditFormMixin	StatusModelBulkEditFormMixin
StatusFilterFormMixin	StatusModelFilterFormMixin

Strict Filter Validation by Default (#1736)

Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.

A new configuration setting, STRICT_FILTERING has been added. It defaults to True, enabling strict validation of filter parameters, but can be set to False to disable this validation.

Warning:
Setting STRICT_FILTERING to False can result in unexpected filtering results in the case of user error, for example a request to /api/dcim/devices/?has_primry_ip=false (note the typo primry) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.

Moved Registry Template Context (#1945)

The settings_and_registry default context processor was changed to purely settings - the (large) Nautobot application registry dictionary is no longer provided as part of the render context for all templates by default. Added a new registry template tag that can be invoked by specific templates to provide this variable where needed.