nautobot 2.0.0a3__py3-none-any.whl → 2.0.0b1__py3-none-any.whl

nautobot/docs/models/dcim/device.md

@@ -14,4 +14,7 @@ Device names must be unique within a site, unless the device has been assigned t
 
 When a device has one or more interfaces with IP addresses assigned, a primary IP for the device can be designated, for both IPv4 and IPv6.
 
++/- 2.0.0
+    In Nautobot 1.x, it was not possible to delete an IPAddress or an Interface that was serving as the primary IP address (`primary_ip4`/`primary_ip6`) for a Device. As of Nautobot 2.0, this is now permitted; doing so will clear out the Device's corresponding primary IP value.
+
 For Devices forming a group (Failover, Load-Sharing, Redundacy or similar) refer to [Device Redundancy Groups](deviceredundancygroup.md) model documentation.

nautobot/docs/models/dcim/deviceredundancygroup.md

@@ -48,7 +48,7 @@ query ($device_name: [String]) {
                     name
                     ip_addresses {
                         host
-                        prefix_length
+                        mask_length
                     }
                     parent_interface {
                         name
@@ -98,7 +98,7 @@ We will demonstrate how to execute the command for Primary Unit only, however yo
                                     "ip_addresses": [
                                         {
                                             "host": "172.27.48.0",
-                                            "prefix_length": 31
+                                            "mask_length": 31
                                         }
                                     ],
                                     "parent_interface": {
@@ -118,7 +118,7 @@ We will demonstrate how to execute the command for Primary Unit only, however yo
                                     "ip_addresses": [
                                         {
                                             "host": "172.27.48.1",
-                                            "prefix_length": 31
+                                            "mask_length": 31
                                         }
                                     ],
                                     "parent_interface": {

nautobot/docs/models/extras/computedfield.md

@@ -17,13 +17,13 @@ As an example, within your automation system, you may want to be able to have an
 
 Computed fields can be created through the Nautobot UI under **Extensibility > Computed Fields**.
 
-Each computed field must have a slug and a label.
+Each computed field must have a key and a label.
 
-- Slug must be a simple, database-friendly string, e.g. `device_with_site`
+- Key must be a simple, database-friendly string, e.g. `device_with_site`
 - Label is used as the human-friendly display name for this field in the UI, for example, `Device With Site`.
 
 !!! tip
-    Because computed field data can be included in the REST API and in GraphQL, we strongly recommend that when defining a computed field, you provide a slug that contains underscores rather than dashes (`my_field_slug`, not `my-field-slug`), as some features may not work optimally if dashes are included in the slug.
+    Because computed field data can be included in the REST API and in GraphQL, we strongly recommend that when defining a computed field, you provide a key that contains underscores rather than dashes (`my_field_key`, not `my-field-key`), as some features may not work optimally if dashes are included in the key.
 
 Similar to custom fields, the weight value is used to order computed fields within a form. A description can also be provided, and will appear beneath the field in a form.
 
@@ -76,4 +76,4 @@ When explicitly requested as such, computed field data will be included in the `
 ```
 
 !!! note
-    The `slug` value of each computed field is used as the key name for items in the `computed_fields` attribute.
+    The `key` value of each computed field is used as the key name for items in the `computed_fields` attribute.

nautobot/docs/models/extras/gitrepository.md

@@ -14,6 +14,9 @@ Some text-based content is more conveniently stored in a separate Git repository
 
 When defining a Git repository for Nautobot to consume, the `name`, `remote URL`, and `branch` parameters are mandatory - the name acts as a unique identifier, and the remote URL and branch are needed for Nautobot to be able to locate and access the specified repository. Additionally, if the repository is private you may specify a `secrets group` that can be used to gain access to the repository.
 
+!!! note
+    Nautobot currently only supports repositories that can be cloned using the standard git command line, `git clone`. This means App-style integrations like GitHub Apps are not currently supported, as their workflow of managing files leverages a REST API.
+
 --- 2.0.0
     In Nautobot 1.x it was possible to configure the secrets (`username` and/or `token`) for a private Git Repository directly in Nautobot's database. Due to security concerns and maintainability challenges, this option has been removed. To access a private Git repository you now must use Secrets Groups.
 

nautobot/docs/models/extras/job.md

@@ -17,6 +17,7 @@ Records of this type store the following data as read-only (not modifiable via t
 * The name of the module containing the Job
 * The name of the Job class
 * Whether the job is installed presently
+* Whether the job is read-only
 * Whether the job is a [Job Hook Receiver](jobhook.md#job-hook-receivers)
 * Whether the job is a [Job Button Receiver](jobbutton.md#job-button-receivers)
 

nautobot/docs/models/extras/jobbutton.md

@@ -97,7 +97,7 @@ class ExampleSimpleJobButtonReceiver(JobButtonReceiver):
         name = "Example Simple Job Button Receiver"
 
     def receive_job_button(self, obj):
-        self.log_info(obj=obj, message="Running Job Button Receiver.")
+        self.logger.info("Running Job Button Receiver.", extra={"object": obj})
         # Add job logic here
 ```
 
@@ -106,7 +106,7 @@ class ExampleSimpleJobButtonReceiver(JobButtonReceiver):
 Since Job Buttons can be associated to multiple object types, it would be trivial to create a Job that can change what it runs based on the object type.
 
 ```py
-from nautobot.dcim.models import Device, Site
+from nautobot.dcim.models import Device, Location
 from nautobot.extras.jobs import JobButtonReceiver
 
 
@@ -114,25 +114,30 @@ class ExampleComplexJobButtonReceiver(JobButtonReceiver):
     class Meta:
         name = "Example Complex Job Button Receiver"
 
-    def _run_site_job(self, obj):
-        self.log_info(obj=obj, message="Running Site Job Button Receiver.")
-        # Run Site Job function
+    def _run_location_job(self, obj):
+        self.logger.info("Running Location Job Button Receiver.", extra={"object": obj})
+        # Run Location Job function
 
     def _run_device_job(self, obj):
-        self.log_info(obj=obj, message="Running Device Job Button Receiver.")
+        self.logger.info("Running Device Job Button Receiver.", extra={"object": obj})
         # Run Device Job function
 
     def receive_job_button(self, obj):
         user = self.request.user
-        if isinstance(obj, Site):
-            if not user.has_perm("dcim.add_site"):
-                self.log_failure(obj=obj, message=f"User '{user}' does not have permission to add a Site.")
+        if isinstance(obj, Location):
+            if not user.has_perm("dcim.add_location"):
+                self.logger.error("User '%s' does not have permission to add a Location.", user, extra={"object": obj})
+                raise Exception("User does not have permission to add a Location.")
             else:
-                self._run_site_job(obj)
-        if isinstance(obj, Device):
+                self._run_location_job(obj)
+        elif isinstance(obj, Device):
             if not user.has_perm("dcim.add_device"):
-                self.log_failure(obj=obj, message=f"User '{user}' does not have permission to add a Device.")
+                self.logger.error("User '%s' does not have permission to add a Device.", user, extra={"object": obj})
+                raise Exception("User does not have permission to add a Device.")
             else:
                 self._run_device_job(obj)
-        self.log_failure(obj=obj, message=f"Unable to run Job Button for type {type(obj).__name__}.")
+        else:
+            self.logger.error("Unable to run Job Button for type %s.", type(obj).__name__, extra={"object": obj})
+            raise Exception("Job button called on unsupported object type.")
+
 ```

nautobot/docs/models/extras/jobhook.md

@@ -16,6 +16,9 @@ A Job Hook is a mechanism for automatically starting a [job](../../additional-fe
 
 Job Hooks are only able to initiate a specific type of job called a **Job Hook Receiver**. These are jobs that subclass the `nautobot.extras.jobs.JobHookReceiver` class. Job hook receivers are similar to normal jobs except they are hard coded to accept only an `object_change` [variable](../../additional-features/jobs.md#variables). Job Hook Receivers are hidden from the jobs listing UI by default but otherwise function similarly to other jobs. The `JobHookReceiver` class only implements one method called `receive_job_hook`.
 
+!!! warning
+    Requiring approval for execution of Job Hooks by setting the `Meta.approval_required` attribute to `True` on your `JobHookReceiver` subclass is not supported. The value of this attribute will be ignored. Support for requiring approval of Job Hooks will be added in a future release.
+
 !!! important
     To prevent negatively impacting system performance through an infinite loop, a change that was made by a `JobHookReceiver` job will not trigger another `JobHookReceiver` job to run.
 
@@ -34,21 +37,21 @@ class ExampleJobHookReceiver(JobHookReceiver):
 
         # log diff output
         snapshots = change.get_snapshots()
-        self.log_info(f"DIFF: {snapshots['differences']}")
+        self.logger.info("DIFF: %s", snapshots['differences'])
 
         # validate changes to serial field
         if "serial" in snapshots["differences"]["added"]:
             old_serial = snapshots["differences"]["removed"]["serial"]
             new_serial = snapshots["differences"]["added"]["serial"]
-            self.log_info(f"{changed_object} serial has been changed from {old_serial} to {new_serial}")
+            self.logger.info("%s serial has been changed from %s to %s", changed_object, old_serial, new_serial)
 
             # Check the new serial is valid and revert if necessary
             if not self.validate_serial(new_serial):
                 changed_object.serial = old_serial
                 changed_object.save()
-                self.log_info(f"{changed_object} serial {new_serial} was not valid. Reverted to {old_serial}")
+                self.logger.info("%s serial %s was not valid. Reverted to %s", changed_object, new_serial, old_serial)
 
-            self.log_success(message=f"Serial validation completed for {changed_object}")
+            self.logger.info("Serial validation completed for %s", changed_object)
 
     def validate_serial(self, serial):
         # add business logic to validate serial

nautobot/docs/models/extras/jobresult.md

@@ -4,9 +4,13 @@ Nautobot provides a generic data model for storing and reporting the results of
 
 Records of this type store the following data:
 
-- A reference to the type and name of the object or feature that the task was associated with
+- A reference to the job model that the task was associated with
 - A reference to the user who initiated the task
+- If initiated by a scheduled job, a reference to that scheduled job instance
 - The arguments that were passed to the task (allowing for later queuing of the task for re-execution if desired)
 - Timestamps indicating when the task was created and when it completed
 - An overall status such as "pending", "running", "errored", or "completed".
-- A block of structured data (often rendered as JSON); Any return values from the `.run()` and any `test` methods go to the key `output`. In addition any Job or plugin using the `JobResult` model can store arbitrary structured data here if needed. (Note that prior to Nautobot 1.2, job log records were stored in this field; they are now stored as distinct [`JobLogEntry`](joblogentry.md) records instead.)
+- A block of structured data representing the return value from the `.run()` method (often rendered as JSON).
+
++/- 1.2.0
+    Note that prior to Nautobot 1.2, job log records were stored in the `data` field; they are now stored as distinct [`JobLogEntry`](joblogentry.md) records instead.

nautobot/docs/models/extras/relationship.md

@@ -43,7 +43,7 @@ Required relationships are enforced in the following scenarios:
 
 Filters can be defined to restrict the type or selection of objects for either side of the connection.
 
-An important note is that the filters have to be defined in **FilterSet** rather than QuerySet format. In practice this means that you can use any of the filters that are valid in the REST API for a given object type, but cannot necessarily use complex nested attribute lookups (such as `interfaces__ip_addresses__prefix_length` on a Device, for example).
+An important note is that the filters have to be defined in **FilterSet** rather than QuerySet format. In practice this means that you can use any of the filters that are valid in the REST API for a given object type, but cannot necessarily use complex nested attribute lookups (such as `interfaces__ip_addresses__mask_length` on a Device, for example).
 
 As an example, let's create a relationship between Circuits and Devices.
 In our situation we only would terminate Circuits on Devices with the Device Role of `edge`.
@@ -149,7 +149,7 @@ In the relationship field, you may specify a dictionary of object attributes ins
 ```json
 {
     "relationship": {
-        "slug": "device-vlans"
+        "key": "device_vlans"
     },
     "source_type": "ipam.vlan",
     "source_id": "89588629-2d70-45ce-9e20-f6b159b41b0c",

nautobot/docs/models/extras/status.md

@@ -12,9 +12,10 @@ Statuses may be managed by navigating to **Organization > Statuses** in the navi
 
 ### Importing Objects with a `status` Field
 
-When using CSV import to reference a `status` field on an object, the `Status.slug` field is used.
+When using CSV import to reference a `status` field on an object, the `Status.name` field is used.
 
-For example, the default **Active** status has a slug of `active`, so the `active` value would be used for import.
++/- 2.0.0
+    Changed the CSV import reference for Statuses from `Status.slug` to `Status.name`.
 
 ## Customizing Statuses
 
@@ -33,10 +34,10 @@ For Virtual Machines, if utilizing OpenStack, statuses in Nautobot could be cust
     data models of their own that implement a `status` field. Proceed at your
     own risk!
 
-Any model that is intended to have a `status` field must inherit from `nautobot.extras.models.statuses.StatusModel`. This abstract model will add an `nautobot.extras.models.statuses.StatusField` to the model. The abstract base will automatically assign a `related_name` for the reverse relationship back to the inheriting model's verbose plural name (e.g. `devices`).
+Any model that is intended to have a `status` field must use a `nautobot.extras.models.statuses.StatusField` for its foreign-key to the model. This field type will automatically assign a `related_name` for the reverse relationship back to the inheriting model's verbose plural name (e.g. `devices`).
 
 +/- 2.0.0
-    The related name for Statuses was changed to be based on the model's `verbose_name_plural` instead of the pattern `%(app_label)s_%(model)s_related`. For example, `Status.devices` and not `Status.dcim_device_related`.
+    The related name for Statuses was changed to be based on the model's `verbose_name_plural` instead of the pattern `%(app_label)s_%(model)s_related`. For example, `Status.devices` and not `Status.dcim_device_related`. Additionally, the recommendation to inherit from `StatusModel` has been replaced with a recommendation to directly include a `StatusField`.
 
 ### `StatusField` model field
 
@@ -60,15 +61,6 @@ Any model form that is intended to have a `status` field must inherit from one o
 +/- 1.4.0
     In prior Nautobot versions these mixins were named `StatusFilterFormMixin` and `StatusBulkEditFormMixin`; the old names are still available as aliases but will be removed in a future major release.
 
-- FIXME: CSV import forms
-
-### `StatusModelSerializerMixin` serializer mixin
-
-Any serializer that is intended to have a `status` field must inherit from `nautobot.extras.api.serializers.StatusModelSerializerMixin`. This adds an `nautobot.extras.api.fields.StatusSerializerField` to the serializer.
-
-+/- 2.0.0
-    The `StatusSerializerField` was changed to use a `NestedStatusSerializer` instead of presenting choices as a list of enums.
-
 ### Table field
 
 If you wish for a table to include a `status` field, your table must inherit from `nautobot.extras.tables.StatusTableMixin`. This includes a `ColorColumn` on the table.
@@ -79,13 +71,12 @@ To fully integrate a model to include a `status` field, assert the following:
 
 ### Model
 
-- The model must inherit from `nautobot.extras.models.statuses.StatusModel`
+- The model must use a `nautobot.extras.models.statuses.StatusField`
 - Decorate the model class with `@extras_features('statuses')` (`from nautobot.extras.utils import extras_features`)
 
 ### Forms
 
 - Generic model forms will automatically include a `StatusField`
-- CSV model import forms must inherit from `nautobot.extras.forms.StatusModelCSVFormMixin`
 - Bulk edit model forms must inherit from `nautobot.extras.forms.StatusModelBulkEditFormMixin`
 - Filter forms must inherit from `nautobot.extras.forms.StatusModelFilterFormMixin`
 
@@ -96,10 +87,6 @@ To fully integrate a model to include a `status` field, assert the following:
 
 - Filtersets for your model must inherit from `nautobot.extras.filters.StatusModelFilterSetMixin`
 
-### Serializers
-
-- Serializers for your model must inherit from `nautobot.extras.api.serializers.StatusModelSerializerMixin`
-
 ### Tables
 
 - The table class for your model must inherit from `nautobot.extras.tables.StatusTableMixin`

nautobot/docs/models/ipam/ipaddress.md

@@ -27,6 +27,9 @@ An IP address can be assigned to any device or virtual machine interface, and an
 !!! note
     When primary IPs are set for both IPv4 and IPv6, Nautobot will prefer IPv6. This can be changed by setting the `PREFER_IPV4` configuration parameter.
 
++/- 2.0.0
+    `prefix_length` becomes `mask_length` and is intended to describe the desired subnet mask of the IP addresses when configured on interface(s).
+
 ## Network Address Translation (NAT)
 
 An IP address can be designated as the network address translation (NAT) inside IP address for one or more other IP addresses. This is useful primarily to denote a translation between public and private IP addresses. This relationship is followed in both directions: For example, if 10.0.0.1 is assigned as the inside IP for 192.0.2.1, 192.0.2.1 will be displayed as the outside IP for 10.0.0.1.

nautobot/docs/models/virtualization/virtualmachine.md

@@ -12,3 +12,6 @@ Like devices, each VM can be assigned a platform and/or functional role, and an
 * Decommissioning
 
 Additional fields are available for annotating the vCPU count, memory (GB), and disk (GB) allocated to each VM. Each VM may optionally be assigned to a tenant. Virtual machines may have virtual interfaces assigned to them, but do not support any physical component.
+
++/- 2.0.0
+    In Nautobot 1.x, it was not possible to delete an IPAddress or an VMInterface that was serving as the primary IP address (`primary_ip4`/`primary_ip6`) for a VirtualMachine. As of Nautobot 2.0, this is now permitted; doing so will clear out the VirtualMachine's corresponding primary IP value.

nautobot/docs/plugins/development.md

@@ -151,7 +151,6 @@ Nautobot looks for the `config` variable within an app's `__init__.py` to load i
 | Name | Default | Description |
 | ---- | ------- | ----------- |
 | `base_url` | Same as specified `name` | Base path to use for app URLs |
-| `caching_config` | `{"*":{"ops":"all"}}` | App-specific [query caching configuration](https://github.com/Suor/django-cacheops#setup) |
 | `config_view_name` | `None` | [URL name](#adding-links-to-the-installed-apps-view) for a "configuration" view defined by this app |
 | `default_settings` | `{}` | A dictionary of configuration parameters and their default values |
 | `home_view_name` | `None` | [URL name](#adding-links-to-the-installed-apps-view) for a "home" or "dashboard" view defined by this app |
@@ -167,6 +166,9 @@ Nautobot looks for the `config` variable within an app's `__init__.py` to load i
 +++ 2.0.0
     Support for the `searchable_models` and `constance_config` attributes were added.
 
+--- 2.0.0
+    Support for `caching_config` was removed with the removal of `django-cacheops`.
+
 !!! note
     All `required_settings` must be configured in `PLUGINS_CONFIG` in `nautobot_config.py` before the app can be used.
 
@@ -388,7 +390,10 @@ def banner(context, *args, **kwargs):
 
 Apps can extend the existing navigation bar layout. By default, Nautobot looks for a `menu_items` list inside of `navigation.py`. (This can be overridden by setting `menu_items` to a custom value on the app's `NautobotAppConfig`.)
 
-Using a key and weight system, a developer can integrate the app's menu additions amongst existing menu tabs, groups, items and buttons, and/or create entirely new menus as desired.
+Using a key and weight system, a developer can integrate the app's menu additions amongst existing menu tabs, groups, and items.
+
+--- 2.0.0
+    As part of the Nautobot 2.0 UI redesign, the option for apps to add entirely new top-level menu "tabs" has been removed. Additionally, buttons can no longer be added to menu items.
 
 More documentation and examples can be found in the [Navigation Menu](../development/navigation-menu.md) guide.
 
@@ -469,6 +474,57 @@ class AnimalSoundsConfig(NautobotAppConfig):
 !!! warning
     Do not store secrets in the constance_config, instead use Nautobot [Secrets](../models/extras/secret.md).
 
+### Overriding Default Model Views in Nautobot Apps
+
++++ 2.0.0
+
+In UI 2.0, Nautobot provides default model views (`ObjectListView`, `ObjectRetrieveView` and etc) for every model including App provided models unless they are explicitly overridden. For example, an app called `your_example_app` wants to override the default `ObjectRetrieveView` for its model called `YourExampleModel` with a customized view called `YourExampleView`. We need to go to the `index.js` file located in the `your_example_app/ui` folder and add a key `view_overrides` to the `app_config` dictionary variable.
+
+```no-highlight
+const app_config = {
+    ...
+    view_overrides: {}
+    ...
+}
+```
+
+In `view_overrides`'s dictionary, you need to specify the app and the model you want to override the default view for in this format `{app_label}: {model_name}`. So in our case, it would be `"your-example-app": "your-example-model"`.
+
+```no-highlight
+...
+    view_overrides: {
+        "your-example-app": "your-example-model": {}
+    }
+...
+```
+
+Finally, you need to specify the default view action you want to override and the new view in this format `{view_action}: {new_view}`. So in our case, it would be `"retrieve": "YourExampleView"`:
+
+```no-highlight
+...
+    view_overrides: {
+        "your-example-app": "your-example-model": {
+            "retrieve": "YourExampleView"
+        }
+    }
+...
+```
+
+Now if you go to `YourExampleModel`'s retrieve view, instead of the default `ObjectRetrieveView`, you will see the customized layout of `YourExampleView`.
+
+If you want to override the default `ObjectListView` as well for `YourExampleModel` with `YourExampleListView`, just append `"list": "YourExampleListView"` to the `"your-example-app": "your-example-model"` dictionary.
+
+```no-highlight
+...
+    view_overrides: {
+        "your-example-app": "your-example-model": {
+            "retrieve": "YourExampleView",
+            "list": "YourExampleListView",
+        }
+    }
+...
+```
+
 ## Extending Existing Functionality
 
 ### Adding Jinja2 Filters
@@ -598,7 +654,7 @@ def refresh_git_animals(repository_record, job_result, delete=False):
         job_result.log(
             "Successfully created/updated animal",
             obj=animal_record,
-            level_choice=LogLevelChoices.LOG_SUCCESS,
+            level_choice=LogLevelChoices.LOG_INFO,
             grouping="animals",
         )
 
@@ -646,9 +702,9 @@ def create_site_to_animal_relationship(sender, apps, **kwargs):
 
     # Ensure that the Relationship exists
     Relationship.objects.update_or_create(
-        slug="site-favorite-animal",
+        key="site_favorite_animal",
         defaults={
-            "name": "Site's Favorite Animal",
+            "label": "Site's Favorite Animal",
             "type": RelationshipTypeChoices.TYPE_ONE_TO_MANY,
             "source_type": ContentType.objects.get_for_model(Animal),
             "source_label": "Sites that love this Animal",
@@ -1020,36 +1076,40 @@ Concrete examples on how to use `NautobotUIViewSet` resides in `nautobot.circuit
 Below we provide an example on how to use `NautobotUIViewSet` on a theoretical app model.
 
 ```python
-from nautobot.apps.views import NautobotUIViewset
+from nautobot.apps.views import NautobotUIViewSet
+from yourapp import filters, forms, models, tables
+from yourapp.api import serializers
 
 class YourAppModelUIViewSet(NautobotUIViewSet):
-    bulk_create_form_class = YourAppModelCSVForm
-    bulk_update_form_class = YourAppModelBulkEditForm
-    filterset_class = YourAppModelFilterSet
-    filterset_form_class = YourAppModelFilterForm
-    form_class = YourAppModelForm
-    queryset = YourAppModel.objects.all()
+    bulk_update_form_class = forms.YourAppModelBulkEditForm
+    filterset_class = filters.YourAppModelFilterSet
+    filterset_form_class = forms.YourAppModelFilterForm
+    form_class = forms.YourAppModelForm
+    queryset = models.YourAppModel.objects.all()
     serializer_class = serializers.YourAppModelSerializer
-    table_class = YourAppModelTable
+    table_class = tables.YourAppModelTable
 ```
 
 #### Setting ViewSet Attributes
 
 **One caveat of using the NautobotUIViewSet is that the `queryset`, `serializer_class` and `table_class` attribute of the `YourAppModelUIViewSet` has to be set before most of the `NautobotUIViewSet` functionalities will become available.**
 
-By default the URL patterns generated by a `NautobotUIViewSet` are based on the model's `slug` (`/model-name/<slug>/` for the detail view, `/model-name/<slug>/edit/` for the edit view, etc.). If your model lacks a `slug` field, or if you otherwise need to use a different field to look up an object, just override the default `lookup_field` in your ViewSet attributes:
+By default the URL patterns generated by a `NautobotUIViewSet` are based on the model's `pk` (`/model-name/<pk>/` for the detail view, `/model-name/<pk>/edit/` for the edit view, etc.). if you need to use a different field to look up an object, just override the default `lookup_field` in your ViewSet attributes:
 
 ```python
-from nautobot.apps.views import NautobotUIViewset
+from nautobot.apps.views import NautobotUIViewSet
 
 class YourAppModelUIViewSet(NautobotUIViewSet):
     ...
-    lookup_field = "pk"
+    lookup_field = "slug"
     ...
 ```
 
++/- 2.0.0
+    The default `lookup_field` for `NautobotUIViewSet` has been changed from `"slug"` to `"pk"`.
+
 !!! note
-    Using a field other than the default `slug` or the alternative field `pk` (as shown in the example above), may result in certain pieces of the UI not displaying (for example, the edit and delete buttons on the object detail view). This is due to the URL expecting a named key of slug or pk, rather than id.
+    Using a field other than the default `pk` or the alternative field `slug` (as shown in the example above), may result in certain pieces of the UI not displaying (for example, the edit and delete buttons on the object detail view). This is due to the URL expecting a named key of slug or pk, rather than id.
 
 #### View Template Context
 
@@ -1090,11 +1150,13 @@ Other context keys may be available for certain views:
 
 You may see other context keys as well, but any not documented above should not be relied upon as they may be removed in a future release. Some examples of those are:
 
-* `changelog_url`: This can now be retrieved from the object itself, via `object.get_changelog_url`, if the object supports change-logging
 * `obj`: Please use `object` instead
 * `obj_type`: Please use `verbose_name` instead
 * `obj_type_plural`: Please use `verbose_name_plural` instead
 
+--- 2.0.0
+    The `changelog_url` context key was removed. Use `object.get_changelog_url` instead.
+
 #### Excluding ViewMixins from NautobotUIViewSet
 
 For app models that do not require certain views, simply inherit directly from the `ViewMixin` classes available in `nautobot.apps.views` instead of `NautobotUIViewSet`.
@@ -1172,13 +1234,13 @@ urlpatterns = [
     # changelog, notes and etc.
     ...
     path(
-        "yourappmodels/<slug:slug>/changelog/",
+        "yourappmodels/<uuid:pk>/changelog/",
         ObjectChangeLogView.as_view(),
         name="yourappmodel_changelog",
         kwargs={"model": yourappmodel},
     ),
     path(
-        "yourappmodels/<slug:slug>/notes/",
+        "yourappmodels/<uuid:pk>/notes/",
         ObjectNotesView.as_view(),
         name="yourappmodel_notes",
         kwargs={"model": yourappmodel},
@@ -1412,7 +1474,7 @@ try:
     from nautobot.extras.views import ObjectNotesView
     urlpatterns.append(
         path(
-            'random/<slug:slug>/notes/),
+            'random/<uuid:pk>/notes/),
             ObjectNotesView.as_view(),
             name="random_notes",
             kwargs={"model": Random},

nautobot/docs/release-notes/version-1.5.md

@@ -148,6 +148,59 @@ A number of mixin classes have been renamed and/or relocated for improved self-c
 | `TenancyFilterSet`             | `TenancyModelFilterSetMixin`                 |
 
 <!-- towncrier release notes start -->
+## v1.5.18 (2023-05-01)
+
+### Added
+
+- [#1526](https://github.com/nautobot/nautobot/issues/1526) - Added UI button and REST API to validate a `Secret` can be retrieved.
+- [#3669](https://github.com/nautobot/nautobot/issues/3669) - Added indexes to `JobResult` across common fields: `created`, `completed`, and `status`.
+
+### Changed
+
+- [#2800](https://github.com/nautobot/nautobot/issues/2800) - Add model documentation to navigation panel.
+- [#3440](https://github.com/nautobot/nautobot/issues/3440) - Added warning admonitions for Job Hooks and Job Approvals documentation that setting `Meta.approval_required` is ignored on `JobHookReceiver` classes.
+- [#3602](https://github.com/nautobot/nautobot/issues/3602) - Updated `.gitignore` to not track new UI non-source files.
+- [#3621](https://github.com/nautobot/nautobot/issues/3621) - Changed development Docker compose commands to not leave temporary containers behind.
+- [#3633](https://github.com/nautobot/nautobot/issues/3633) - Changed Custom Validator applicator to not require DB query.
+
+### Fixed
+
+- [#3083](https://github.com/nautobot/nautobot/issues/3083) - Fixed an issue where unit tests might fail erroneously when dealing with objects whose name/display contains characters like `"<>`.
+- [#3533](https://github.com/nautobot/nautobot/issues/3533) - Fixed an issue where sending a PATCH to `/api/dcim/interfaces/(uuid)/` might inadvertently reset the interface's status to `Active`.
+- [#3533](https://github.com/nautobot/nautobot/issues/3533) - Fixed an issue where sending a PATCH to `/api/users/tokens/(uuid)/` might inadvertently change the token's value.
+- [#3612](https://github.com/nautobot/nautobot/issues/3612) - Fixed a 500 error when filtering by `content_type` in Dynamic Groups list view.
+- [#3660](https://github.com/nautobot/nautobot/issues/3660) - Fixed an issue where grouped job buttons would always be disabled due to a template rendering issue.
+
+### Security
+
+- [#3642](https://github.com/nautobot/nautobot/issues/3642) - Updated `sqlparse` to `0.4.4` due to CVE-2023-30608. This is not a direct dependency so it will not auto-update when upgrading Nautobot. Please be sure to update your local environment.
+
+## v1.5.17 (2023-04-17)
+
+### Added
+
+- [#3484](https://github.com/nautobot/nautobot/issues/3484) - Added job profiling option to job execution when in DEBUG mode.
+- [#3544](https://github.com/nautobot/nautobot/issues/3544) - Added the ability to change the `CACHES["default"]["BACKEND"]` via an environment variable `NAUTOBOT_CACHES_BACKEND`
+
+### Changed
+
+- [#3544](https://github.com/nautobot/nautobot/issues/3544) - The default database backend if `METRICS_ENABLED` is `True` is now "django_prometheus.db.backends.postgresql"
+- [#3544](https://github.com/nautobot/nautobot/issues/3544) - The default CACHES backend if `METRICS_ENABLED` is `True` is now "django_prometheus.cache.backends.redis.RedisCache"
+- [#3548](https://github.com/nautobot/nautobot/issues/3548) - Changed Git Repository docs to include admonition about Github Apps.
+- [#3595](https://github.com/nautobot/nautobot/issues/3595) - Update the warning provided when a bad reverse entry is not found in serializer to point to correct import location.
+
+### Dependencies
+
+- [#3525](https://github.com/nautobot/nautobot/issues/3525) - Added explicit dependency on `packaging` that had been inadvertently omitted.
+
+### Fixed
+
+- [#3116](https://github.com/nautobot/nautobot/issues/3116) - Fixed JSON comparison of `data_scheme` keys in `assertInstanceEqual` tests.
+- [#3573](https://github.com/nautobot/nautobot/issues/3573) - Fixed advanced filtering on interface UI list page not working.
+- [#3577](https://github.com/nautobot/nautobot/issues/3577) - Fixed `NautobotUIViewSet` documentation example for case sensitive typos.
+- [#3577](https://github.com/nautobot/nautobot/issues/3577) - Fixed `NautobotUIViewSet` documentation example not including imports.
+- [#3598](https://github.com/nautobot/nautobot/issues/3598) - Fixed default sanitizer patterns to account for strings beginning with `i` or `is`.
+
 ## v1.5.16 (2023-04-10)
 
 ### Added