Network Source of Truth & Network Automation Platform
APACHE-2.0 License
Bot releases are hidden (Show)
Published by bryanculver over 2 years ago
invoke cli
parameters match invoke start/stop
.Published by bryanculver over 2 years ago
Published by bryanculver over 2 years ago
This document describes all new features and changes in Nautobot 1.3.
If you are a user migrating from NetBox to Nautobot, please refer to the "Migrating from NetBox" documentation.
A new data model for representing dynamic groups of objects has been implemented. Dynamic groups can be used to organize objects together by matching criteria such as their site location or region, for example, and are dynamically updated whenever new matching objects are created, or existing objects are updated.
For the initial release only dynamic groups of Device
and VirtualMachine
objects are supported.
Plugins can now extend existing FilterSets and Filter Forms. This allows plugins to provide alternative lookup methods or custom queries in the UI or API that may not already exist today.
You can refer to the plugin development guide on how to create new filters and fields.
GraphQL list queries can now be paginated by specifying the filter parameters limit
and offset
. Refer to the GraphQL user guide for examples.
Installed Jobs are now represented by a data model in the Nautobot database. This allows for new functionality including:
slug
as well as by their class_path
./api/extras/jobs/<uuid>/
. The existing /api/extras/jobs/<class_path>/
REST API endpoints continue to work but should be considered as deprecated.
/api/extras/jobs/
list endpoint has been implemented as well, but by default this endpoint continues to demonstrate the pre-1.3 behavior unless the REST API client explicitly requests API version=1.3
. See the section on REST API versioning, below, for more details.enabled = False
, preventing them from being run until an administrator or user with appropriate permissions updates them to be enabled for running.!!! note
As a convenience measure, when initially upgrading to Nautobot 1.3.x, any existing Jobs that have been run or scheduled previously (i.e., have at least one associated JobResult and/or ScheduledJob record) will instead default to enabled = True
so that they may continue to be run without requiring changes.
For more details please refer to the Jobs feature documentation as well as the Job data model documentation.
Custom fields can now have a type of "json". Fields of this type can be used to store arbitrary JSON data.
Many fields have had indexing added to them as well as index togethers on ObjectChange
fields. This should provide a noticeable performance improvement when filtering and doing lookups.
!!! note
This is going to perform several migrations to add all of the indexes. On MySQL databases and tables with 1M+ records this can take a few minutes. Every environment is different but it should be expected for this upgrade to take some time.
IP addresses can now be associated with multiple outside NAT IP addresses. To do this, set more than one IP Address to have the same NAT inside IP address.
A new version of the REST API /api/ipam/ip-addresses/*
endpoints have been implemented as well, but by default this endpoint continues to demonstrate the pre-1.3 behavior unless the REST API client explicitly requests API version=1.3
. See the section on REST API versioning, below, for more details.
!!! note
There are some guardrails on this feature to support backwards compatibility. If you consume the REST API without specifying the version header or query argument and start associating multiple IPs to have the same NAT inside IP address, an error will be reported, because the existing REST API schema returns nat_outside
as a single object, where as 1.3 and beyond will return this as a list.
A data model has been added to support representing the termination of a circuit to an external provider's network.
Python 3.10 is officially supported by Nautobot now, and we are building and publishing Docker images with Python 3.10 now.
New lookup expressions for using regular expressions to filter objects by string (char) fields in the API have been added to all core filters.
The expressions re
(regex), nre
(negated regex), ire
(case-insensitive regex), and nire
(negated case-insensitive regex) lookup expressions are now dynamically-generated for filter fields inherited by subclasses of nautobot.utilities.filters.BaseFilterSet
.
Nautobot now has an /api/users/tokens/
REST API endpoint where a user can provision a new REST API token. This allows a user to gain REST API access without needing to first create a token via the web UI.
$ curl -X POST \
-H "Accept: application/json; indent=4" \
-u "hankhill:I<3C3H8" \
https://nautobot/api/users/tokens/
This endpoint specifically supports Basic Authentication in addition to the other REST API authentication methods.
Nautobot's REST API now supports multiple versions, which may be requested by modifying the HTTP Accept header on any requests sent by a REST API client. Details are in the REST API documentation, but in brief:
/api/extras/jobs/
listing endpoint/api/extras/tags/
create/put/patch endpoints/api/ipam/ip-addresses/
endpointsAccept: application/json
rather than Accept: application/json; version=1.3
) the API behavior will be compatible with Nautobot 1.2, at a minimum for the remainder of the Nautobot 1.x release cycle.major.minor
version where the updated API endpoint was introduced (so to interact with the updated REST API endpoints mentioned above, Accept: application/json; version=1.3
).!!! tip
As a best practice, when developing a Nautobot REST API integration, your client should always request the current API version it is being developed against, rather than relying on the default API behavior (which may change with a new Nautobot major release, as noted, and which also may not include the latest and greatest API endpoints already available but not yet made default in the current release).
Webhooks now provide a snapshot of data before and after a change, as well as the differences between the old and new data. See the default request body section in the webhook docs.
As Python 3.6 has reached end-of-life, the default Docker images published for this release (i.e. 1.3.0
, stable
, latest
) have been updated to use Python 3.7 instead.
extras.approve_job
Permission (#1490)Similar to the existing extras.run_job
permission, a new extras.approve_job
permission is now enforced by the UI and the REST API when approving scheduled jobs. Only users with this permission can approve or deny approval requests; additionally such users also now require the extras.view_scheduledjob
, extras.change_scheduledjob
, and extras.delete_scheduledjob
permissions as well.
The online REST API Swagger documentation (/api/docs/
) has been updated from OpenAPI 2.0 format to OpenAPI 3.0 format and now supports Nautobot's REST API versioning as described above. Try /api/docs/?api_version=1.3
as an example.
When created, a Tag
can be associated to one or more model content-types using a many-to-many relationship. The tag will then apply only to models belonging to those associated content-types.
For users migrating from an earlier Nautobot release, any existing tags will default to being enabled for all content-types for compatibility purposes. Individual tags may subsequently edited to remove any content-types that they do not need to apply to.
Note that a Tag created programmatically via the ORM without assigning any content_types
will not be applicable to any model until content-types are assigned to it.
We've updated the Jinja2 dependency from version 2.11 to version 3.0.3. This may affect the syntax of any nautobot.extras.models.ComputedField
objects in your database... Specifically, the template
attribute, which is parsed as a Jinja2 template. Please refer to Jinja2 3.0.x's release notes to check if any changes might be required in your computed fields' templates.
As Python 3.6 has reached end-of-life, and many of Nautobot's dependencies have already dropped support for Python 3.6 as a consequence, Nautobot 1.3 and later do not support installation under Python 3.6.
BaseFilterSet
filter fields in the API.ObjectChange
.drf-yasg
(OpenAPI 2.0) to drf-spectacular
(OpenAPI 3.0) for REST API interactive Swagger documentation.dev
and final
images.extras.approve_job
permissions as appropriate.0
when performing a bulk edit of device types.schedule
would allow approval_required
to be bypassed.null
.render_boolean
template filter, which renders computed boolean values as HTML in a consistent manner.hidden = True
in the Job's inner Meta
class.soft_time_limit
and time_limit
in seconds as attributes of a Job's Meta
.nautobot.extras.forms.NautobotModelForm
and nautobot.extras.filters.NautobotFilterSet
base classes. All form classes which inherited from all three of (BootstrapMixin
, CustomFieldModelForm
, and RelationshipModelForm
) now inherit from NautobotModelForm
as their base class. All filterset classes which inherited from all three of (BaseFilterSet
, CreatedUpdatedFilterSet
, and CustomFieldModelFilterSet
) now inherit from NautobotFilterSet
as their base class.type()
are now refactored to use isinstance()
where applicable.Job.Meta.description
can now contain markdown-formatted multi-line text.1.3.0
, stable
, latest
) have been updated to use Python 3.7 instead.nautobot.extras.models.jobs
; refined Job testing best practices.Published by bryanculver over 2 years ago
primary_ip
is available for a device, but other connection options are available.IPAddress.primary_ip4_for
Published by bryanculver over 2 years ago
AbortTransaction
to end the job and force rollback.Published by bryanculver over 2 years ago
A new data model for representing dynamic groups of objects has been implemented. Dynamic groups can be used to organize objects together by matching criteria such as their site location or region, for example, and are dynamically updated whenever new matching objects are created, or existing objects are updated.
For the initial release only dynamic groups of Device
and VirtualMachine
objects are supported.
!!! note
For this first 1.3 beta release, this feature is not yet documented. Dynamic Groups be found by navigating to Organization > Dynamic Groups in the web interface.
GraphQL list queries can now be paginated by specifying the filter parameters limit
and offset
. Refer to the user guide for examples.
Installed Jobs are now represented by a data model in the Nautobot database. This allows for new functionality including:
slug
as well as by their class_path
.api/extras/job-models
. The existing api/extras/jobs
REST API continues to work but should be considered as deprecated.!!! warning
The new Jobs REST API endpoint URL is likely to change before the final release of Nautobot 1.3.
enabled = False
, preventing them from being run until an administrator or user with appropriate permissions updates them to be enabled for running.!!! note
As a convenience measure, when initially upgrading to Nautobot 1.3.x, any existing Jobs that have been run or scheduled previously (i.e., have at least one associated JobResult and/or ScheduledJob record) will instead default to enabled = True
so that they may continue to be run without requiring changes.
For more details please refer to the Jobs feature documentation as well as the Job data model documentation.
A data model has been added to support representing the termination of a circuit to an external provider's network.
Python 3.10 is officially supported by Nautobot now, and we are building and publishing Docker images with Python 3.10 now.
We've updated the Jinja2 dependency from version 2.11 to version 3.0.3. This may affect the syntax of any nautobot.extras.models.ComputedField
objects in your database... Specifically, the template
attribute, which is parsed as a Jinja2 template. Please refer to Jinja2 3.0.x's release notes to check if any changes might be required in your computed fields' templates.
As Python 3.6 has reached end-of-life, the default Docker images published for this release (i.e. 1.3.0
, stable
, latest
) have been updated to use Python 3.7 instead.
As Python 3.6 has reached end-of-life, and many of Nautobot's dependencies have already dropped support for Python 3.6 as a consequence, Nautobot 1.3 and later do not support installation under Python 3.6.
null
.render_boolean
template filter, which renders computed boolean values as HTML in a consistent manner.hidden = True
in the Job's inner Meta
classsoft_time_limit
and time_limit
in seconds as attributes of a Job's Meta
.nautobot.extras.forms.NautobotModelForm
and nautobot.extras.filters.NautobotFilterSet
base classes. All form classes which inherited from all three of (BootstrapMixin
, CustomFieldModelForm
, and RelationshipModelForm
) now inherit from NautobotModelForm
as their base class. All filterset classes which inherited from all three of (BaseFilterSet
, CreatedUpdatedFilterSet
, and CustomFieldModelFilterSet
) now inherit from NautobotFilterSet
as their base class.type()
are now refactored to use isinstance()
where applicable.Job.Meta.description
can now contain markdown-formatted multi-line text.1.3.0
, stable
, latest
) have been updated to use Python 3.7 instead.nautobot.extras.models.jobs
; refined Job testing best practices.Published by bryanculver over 2 years ago
extras.0017_joblog_data_migration
migration when the job logs contain messages mistakenly logged as object references.It is highly recommended that users of Python 3.6 prioritize upgrading to a newer version of Python. Nautobot will be removing support for Python 3.6 in a future update.
For users remaining on Python 3.6, please know that upgrading to Nautobot v1.2.9 will not resolve these CVEs for your installation. The only remedy at this time is to upgrade your systems to utilize Python 3.7 or later.
Published by bryanculver over 2 years ago
5.2.x
to address 5.1.x
blocking redis 4.x
versions.nit
on Github Issue Form styling.null
on Virtual Chassis API.Published by bryanculver over 2 years ago
!! NOTE: This release is functionally equivalent to v1.2.6, but due to an issue in our GitHub Action, a Python package was published to PyPI but Docker images were not published. Instead of pulling the package and retagging, we are pushing a new version.
Published by bryanculver over 2 years ago
get_absolute_url
method to the CircuitTermination
model, fixing a UI error that could occur when relationships involve CircuitTerminations.CELERY_BROKER_URL
to a multiline string instead of a Tuple (tuple is invalid, and raises an exception when job completes).PAGINATE_COUNT
setting but instead defaulted to full unpaginated results.nautobot-secrets-providers
plugin.celery.backend_cleanup
task.MarkupSafe
to version 2.0.1 as later versions are incompatible with Nautobot's current Jinja2
dependency.Published by jathanism over 2 years ago
description
field for device component templates is now correctly propagated to device components created from these templates.release
CI workflowPublished by jathanism almost 3 years ago
workflow_call
to the GitHub Actions CI workflow so that it may be called by other GHA workflows.Published by jathanism almost 3 years ago
nautobot-server dumpdata
and nautobot-server loaddata
commands.status
is a required field.nautobot.utilities.filters.BaseFilterSet.FILTER_DEFAULTS
does not allow models.TextField
to use multi-value filtering. Models using TextField
s will now be able to MultiValCharFilter
in filter classes on those fields./api/
URLs now correctly return a JSON 404 response rather than an HTML 404 response.device_types
.Published by jathanism almost 3 years ago
JobLogEntry
objects.JobResult
page may fail to list JobLogEntries
in chronological orderPublished by jathanism almost 3 years ago
ObjectChange
model.JobResultTable
where rename was not made to the Meta
.ImportError: libxml2.so.2
.graphiql
to 1.5.16 as well as updating the associated Javascript libraries used in the GraphiQL UI to address a reported security flaw in older versions of GraphiQL. To the best of our understanding, the Nautobot implementation of GraphiQL was not vulnerable to said flaw.Published by jathanism almost 3 years ago
This document describes all new features and changes in Nautobot 1.2.
If you are a user migrating from NetBox to Nautobot, please refer to the "Migrating from NetBox" documentation.
The Nautobot Admin UI now includes a "Configuration" page that can be used to dynamically customize a number of optional settings as an alternative to editing nautobot_config.py
and restarting the Nautobot processes.
If upgrading from a previous Nautobot version where these settings were defined in your nautobot_config.py
, you must remove those definitions in order to use this feature, as explicit configuration in nautobot_config.py
takes precedence over values configured in the Admin UI.
All "object detail" views (pages displaying details of a single Nautobot record) now inherit from a common base template, providing improved UI consistency, reducing the amount of boilerplate code needed to create a new detail view, and fixing a number of bugs in various views. Plugin developers are encouraged to make use of this new template (generic/object_detail.html
) to take advantage of these improvements.
Views based on this template now include a new "Advanced" tab - currently this tab includes the UUID and slug (if any) of the object being viewed, but may be extended in the future to include additional information not relevant to the basic object detail view.
Creation and management of Custom Field definitions can now be performed by any user with appropriate permissions. (Previously, only admin users were able to manage Custom Fields.)
Webhooks can now be triggered when creating/updating/deleting CustomField
and CustomFieldChoice
definition records.
After running nautobot-server migrate
or nautobot-server post_upgrade
, Nautobot now emits a custom signal, nautobot_database_ready
. This signal is designed for plugins to connect to in order to perform automatic database population (such as defining custom fields, relationships, webhooks, etc.) at install/upgrade time. For more details, refer to the plugin development documentation.
The GraphQL API now supports query filter parameters at any level of a query. For example:
query {
sites(name: "ams") {
devices(role: "edge") {
name
interfaces(type: "virtual") {
name
}
}
}
}
Complex GraphQL queries have been greatly optimized thanks to integration of
graphene-django-optimizer
into Nautobot!
In our internal testing and benchmarking the number of SQL queries generated per GraphQL query have been drastically reduced, resulting in much quicker response times and less strain on the database.
For in depth details on our benchmarks, please see the comment thread on the issue.
The Plugins
menu now includes an "Installed Plugins" menu item which provides a list view of information about all installed and enabled plugins, similar to a formerly administrator-only view.
Additionally, when viewing this list, each plugin can now be clicked on for a detail view, which provides an in-depth look at the capabilities of the plugin, including whether it makes use of each or all of the various Nautobot features available to be used by plugins.
Additionally, plugins now have the option of registering specific "home" and/or "configuration" views, which will be linked and accessible directly from the installed-plugins list and detail views.
Please refer to the plugin development documentation for more details about this functionality.
Nautobot now again supports custom lookup filters on the IPAddress
, Prefix
, and Aggregate
models, such as address__net_contained
, network__net_contains_or_equals
, etc. Refer to the REST API filtering documentation for more specifics and examples.
Jobs can now be optionally defined as approval_required = True
, in which case the Job will not be executed immediately upon submission, but will instead be placed into an approval queue; any user other than the submitter can approve or deny a queued Job, at which point it will then be executed as normal.
Jobs can now be scheduled for execution at a future date and time (such as during a planned maintenance window), and can also be scheduled for repeated execution on an hourly, daily, or weekly recurring cadence.
!!! note
Execution of scheduled jobs is dependent on Celery Beat; enablement of this system service is a new requirement in Nautobot 1.2.
Please see the documentation on enabling the Celery Beat scheduler service to get started!
Template rendering with Django and/or Jinja2 now supports by default all filters provided by the netutils
library. These filters can be used in page templates, computed fields, custom links, export templates, etc. For details, please refer to the template filters documentation.
Organizations may provide custom branding assets to change the logo, icons, and footer URLs to help Nautobot fit within their environments and user communities. Please see the configuration documenation for details on how to specify the location and usage of custom branding assets.
Each plugin is now able to optionally inject a custom banner into any of the Nautobot core views.
Please refer to the plugin development documentation for more details about this functionality.
The Relationships feature has been extended in two ways:
For more details, refer to the Relationships documentation.
Nautobot can now read secret values (such as device or Git repository access credentials) on demand from a variety of external sources, including environment variables and text files, and extensible via plugins to support additional secrets providers such as Hashicorp Vault and AWS Secrets Manager. Both the NAPALM device integration and the Git repository integration can now make use of these secrets, and plugins and jobs can do so as well.
For more details, please refer to the Secrets documentation.
Nautobot core applications and plugins can now both define panels, groups, and items to populate the Nautobot home page. The home page now dynamically reflows to accommodate available content. Plugin developers can add to existing panels or groups or define entirely new panels as needed. For more details, see Populating the Home Page.
The Admin sub-site within Nautobot (/admin/
and its child pages) has been revamped in appearance and functionality. It has been re-skinned to resemble the rest of the Nautobot UI, and has been slimmed down to only include those models and features that are still exclusive to admin users, such as user/group/permission management.
Job log messages are now stored in a separate database table as a separate JobLogEntry
data model, instead of being stored as JSON on the JobResult
model/table. This provides faster and more robust rendering of JobResult
-related views and lays groundwork for future enhancements of the Jobs feature.
!!! note
If you use Jobs inside tests, your TestCase class(es) should have @mock.patch("nautobot.extras.models.models.JOB_LOGS", None)
. This will allow the tests and the JobLogEntry
objects to use the default
database.
!!! note
Because JobLogEntry
records reference their associated JobResult
, the pattern job.job_result = JobResult()
(creating only an in-memory JobResult
object, rather than a database entry) will no longer work. Instead you will need to create a proper JobResult database object job.job_result = JobResult.objects.create(...)
.
All models that have slug
fields now use AutoSlugField
from the django-extensions
package. This means that when creating a record via the REST API, CSV import, or direct ORM Python calls, the slug
field is now fully optional; if unspecified, it will be automatically assigned a unique value, just as how a slug
is auto-populated in the UI when creating a new record.
Just as with the UI, the slug
can still always be explicitly set if desired.
URM-P2
, URM-P4
, and URM-P8
port types.**kwargs
to Celery tasks when using JobResult.enqueue_job()
to execute a Job
.netutils
template filters for both Django and Jinja2 template rendering.SECRET_KEY
before Nautobot is configured.family
field to IPAddressType
for GraphQL API enable filtering of IPAddress
objects by family
.ValueError
when rendering JobResult
detail view with non-standard JobResult.data
contents.JobResult
detail view page templates.JobResult
table/list view.AttributeError
when bulk-adding interfaces to virtual machines.NavMenuItem
without specifying the buttons
argument.nautobot_database_ready
signalapproval_required = True
on Jobsgraphene-django-optimizer
CustomField
and CustomFieldChoice
models.GIT_SSL_NO_VERIFY
environment variable for using self-signed Git repositoriesDISABLE_PREFIX_LIST_HIERARCHY
setting to render IPAM Prefix list view as a flat listJobResult
lists now show the associated Job's name (if available) instead of the Job's class_path
.slug
fields are now optional when creating records via the REST API, ORM, or CSV import. Slugs will be automatically assigned if unspecified.AttributeError
on certain object detail viewsPublished by glennmatthews almost 3 years ago
Published by jathanism almost 3 years ago
This document describes all new features and changes in Nautobot 1.2.
If you are a user migrating from NetBox to Nautobot, please refer to the "Migrating from NetBox"documentation.
The Nautobot Admin UI now includes a "Configuration" page that can be used to dynamically customize a number of optional settings as an alternative to editing nautobot_config.py
and restarting the Nautobot processes.
If upgrading from a previous Nautobot version where these settings were defined in your nautobot_config.py
, you must remove those definitions in order to use this feature, as explicit configuration in nautobot_config.py
takes precedence over values configured in the Admin UI.
All "object detail" views (pages displaying details of a single Nautobot record) now inherit from a common base template, providing improved UI consistency, reducing the amount of boilerplate code needed to create a new detail view, and fixing a number of bugs in various views. Plugin developers are encouraged to make use of this new template (generic/object_detail.html
) to take advantage of these improvements.
Views based on this template now include a new "Advanced" tab - currently this tab includes the UUID and slug (if any) of the object being viewed, but may be extended in the future to include additional information not relevant to the basic object detail view.
Creation and management of Custom Field definitions can now be performed by any user with appropriate permissions. (Previously, only admin users were able to manage Custom Fields.)
Webhooks can now be triggered when creating/updating/deleting CustomField
and CustomFieldChoice
definition records.
After running nautobot-server migrate
or nautobot-server post_upgrade
, Nautobot now emits a custom signal, nautobot_database_ready
. This signal is designed for plugins to connect to in order to perform automatic database population (such as defining custom fields, relationships, webhooks, etc.) at install/upgrade time. For more details, refer to the plugin development documentation.
The GraphQL API now supports query filter parameters at any level of a query. For example:
query {
sites(name: "ams") {
devices(role: "edge") {
name
interfaces(type: "virtual") {
name
}
}
}
}
Complex GraphQL queries have been greatly optimized thanks to integration of graphene-django-optimizer
into Nautobot!
In our internal testing and benchmarking the number of SQL queries generated per GraphQL query have been drastically reduced, resulting in much quicker response times and less strain on the database.
For in depth details on our benchmarks, please see the comment thread on the issue.
The Plugins
menu now includes an "Installed Plugins" menu item which provides a list view of information about all installed and enabled plugins, similar to a formerly administrator-only view.
Additionally, when viewing this list, each plugin can now be clicked on for a detail view, which provides an in-depth look at the capabilities of the plugin, including whether it makes use of each or all of the various Nautobot features available to be used by plugins.
Additionally, plugins now have the option of registering specific "home" and/or "configuration" views, which will be linked and accessible directly from the installed-plugins list and detail views.
Please refer to the plugin development documentation for more details about this functionality.
Jobs can now be optionally defined as approval_required = True
, in which case the Job will not be executed immediately upon submission, but will instead be placed into an approval queue; any user other than the submitter can approve or deny a queued Job, at which point it will then be executed as normal.
Jobs can now be scheduled for execution at a future date and time (such as during a planned maintenance window), and can also be scheduled for repeated execution on an hourly, daily, or weekly recurring cadence.
Please Note: Execution of scheduled jobs is dependent on Celery Beat; enablement of this system service is a new requirement in Nautobot 1.2.
Please see the documentation on enabling the Celery Beat scheduler service to get started!
Organizations may provide custom branding assets to change the logo, icons, and footer URLs to help Nautobot fit within their environments and user communities. Please see the configuration documenation for details on how to specify the location and usage of custom branding assets.
Each plugin is now able to optionally inject a custom banner into any of the Nautobot core views.
Please refer to the plugin development documentation for more details about this functionality.
The Relationships feature has been extended in two ways:
For more details, refer to the Relationships documentation.
Nautobot can now read secret values (such as device or Git repository access credentials) on demand from a variety of external sources, including environment variables and text files, and extensible via plugins to support additional secrets providers such as Hashicorp Vault and AWS Secrets Manager. Both the NAPALM device integration and the Git repository integration can now make use of these secrets, and plugins and jobs can do so as well.
For more details, please refer to the Secrets documentation.
Nautobot core applications and plugins can now both define panels, groups, and items to populate the Nautobot home page. The home page now dynamically reflows to accommodate available content. Plugin developers can add to existing panels or groups or define entirely new panels as needed. For more details, see Populating the Home Page.
The Admin sub-site within Nautobot (/admin/
and its child pages) has been revamped in appearance and functionality. It has been re-skinned to resemble the rest of the Nautobot UI, and has been slimmed down to only include those models and features that are still exclusive to admin users, such as user/group/permission management.
All models that have slug
fields now use AutoSlugField
from the django-extensions
package. This means that when creating a record via the REST API, CSV import, or direct ORM Python calls, the slug
field is now fully optional; if unspecified, it will be automatically assigned a unique value, just as how a slug
is auto-populated in the UI when creating a new record.
Just as with the UI, the slug
can still always be explicitly set if desired.
nautobot_database_ready
signalapproval_required = True
on Jobsgraphene-django-optimizer
CustomField
and CustomFieldChoice
models.GIT_SSL_NO_VERIFY
environment variable for using self-signed Git repositoriesJobResult
lists now show the associated Job's name (if available) instead of the Job's class_path
.slug
fields are now optional when creating records via the REST API, ORM, or CSV import. Slugs will be automatically assigned if unspecified.AttributeError
on certain object detail viewsPublished by jathanism almost 3 years ago
id
and name
fields to NestedJobResultSerializer
for the REST API.main
, develop
, and next
.ghcr.io
.Status.DoesNotExist
during nautobot-server loaddata
._custom_field_data
when certain plugins are installed.AttributeError
reported when viewing a Rack with certain associated power configurations.EXTRA_MIDDLEWARE
instead of MIDDLEWARE.append()
.fix_custom_fields
management command.TemplateDoesNotExist
exception when running a Job containing a FileVar
variable.git
command when refreshing a previously checked out repository.mkdocs
dependency to avoid a potential path-traversal vulnerability; note that mkdocs is only used in development and is not a production deployment dependency of Nautobot.Published by glennmatthews about 3 years ago
SOCIAL_AUTH_BACKEND_PREFIX
configuration setting to support custom authentication backends.MAINTENANCE_MODE
in combination with LDAP.nautobot-server runjob
command.::1/128
were not being treated correctly.X-Frame-Options: DENY
rather than X-Frame-Options: SAMEORIGIN
, with the exception of the rack-elevation API view (/api/dcim/rack-elevation/
) which specifically requires X-Frame-Options: SAMEORIGIN
for functional reasons.