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

nautobot/docs/development/navigation-menu.md

@@ -1,95 +1,35 @@
 # Populating the Navigation Menu
 
-Both core applications and plugins can contribute items to the navigation menu by defining `menu_items` inside of their app's `navigation.py`. Using the key and weight system, a developer can integrate amongst existing menu tabs, groups, items and buttons and/or create entirely new menus as desired.
+Both core applications and plugins can contribute items to the navigation menu by defining `menu_items` inside of their app's `navigation.py`. Using the key and weight system, a developer can integrate amongst existing menu contexts (a.k.a. tabs), groups, and items.
 
-## Modifying Existing Menu
+--- 2.0.0
+    The updated UI does not permit including buttons into the navigation menu items. As such, `NavMenuButton` and its subclasses have been removed, and the `buttons` parameter to `NavMenuItem` is no longer supported.
 
-By defining an object with the same identifier, a developer can modify existing objects. The example below shows modifying an existing tab to have a new group.
+## Defining and Modifying Menus
 
-A tab object is being created with the same identifier as an existing object using the `name` attribute. Then a group is being created with a weight of `150`, which means it will appear between the already defined `Circuits` and `Provider` groups.
+Nautobot will intelligently merge the contents of all apps' `menu_items` defined in their `navigation.py` to create the final navigation menu structure. This is done by matching on objects' `name` fields to identify items that need to be consolidated.
+
+The example below shows adding a new group containing a new item under the base `Inventory` menu context. The group is being defined with a weight of `150`, which means it will appear between the already defined `Devices` (weight `100`) and `Organization` (weight `200`) groups in this context.
 
 !!! tip
-    Weights for already existing items can be found in the nautobot source code (in `navigation.py`) or with a web session open to your nautobot instance, you can inspect an element of the navbar using the developer tools. Each type of element will have an attribute `data-{type}-weight`. The type can be `tab`, `group`, `item` or `button`.
+    Weights for already existing items can be found in the nautobot source code (in `navigation.py`).
 
-This pattern works for modifying all objects in the tree. New items can be added to existing groups and new buttons can be added to existing items.
+This pattern works for modifying all objects in the tree. New groups can be added to existing tabs and new items can be added to existing groups. The set of tabs is defined by the Nautobot `nautobot.core.apps.MENU_TABS` constant and cannot generally be changed.
 
 ``` python
-menu_tabs = (
+menu_items = (
     NavMenuTab(
-        name="Circuits",
+        name="Inventory",
         groups=(
             NavMenuGroup(
-                name="Example Circuit Group",
+                name="Example App",
                 weight=150,
                 items=(
                     NavMenuItem(
-                        link="plugins:example_plugin:examplemodel_list",
                         name="Example Model",
-                        permissions=[
-                            "example_plugin.view_examplemodel"
-                        ],
-                        buttons=(
-                            NavMenuAddButton(
-                                link="plugins:example_plugin:examplemodel_add",
-                                permissions=[
-                                    "example_plugin.add_examplemodel",
-                                ],
-                            ),
-                            NavMenuImportButton(
-                                link="plugins:example_plugin:examplemodel_import",
-                                permissions=[
-                                    "example_plugin.add_examplemodel"
-                                ],
-                            ),
-                        ),
-                    ),
-                ),
-            ),
-        ),
-    ),
-)
-```
-
-## Adding a New Menu
-
-The code below shows how to add a new tab to the navbar. A tab is defined by a `NavMenuTab` object. Similarly a group is defined using `NavMenuGroup`. Both of these objects are used as containers for actual items.
-
-The position in the navigation menu is defined by the weight. The lower the weight the closer to the start of the menus the object will be. All core objects have weights in multiples of 100, meaning there is plenty of space around the objects for plugins to customize.
-
-Below you can see `Example Tab` has a weight value of `150`. This means the tab will appear between `Organization` and `Devices`.
-
-``` python
-from nautobot.core.apps import NavMenuAddButton, NavMenuGroup, NavMenuItem, NavMenuImportButton, NavMenuTab
-
-menu_items = (
-    NavMenuTab(
-        name="Example Tab",
-        weight=150,
-        groups=(
-            NavMenuGroup(
-                name="Example Group 1",
-                weight=100,
-                items=(
-                    NavMenuItem(
+                        weight=100,
                         link="plugins:example_plugin:examplemodel_list",
-                        link_text="Example Model",
-                        permissions=[
-                            "example_plugin.view_examplemodel"
-                        ],
-                        buttons=(
-                            NavMenuAddButton(
-                                link="plugins:example_plugin:examplemodel_add",
-                                permissions=[
-                                    "example_plugin.add_examplemodel",
-                                ],
-                            ),
-                            NavMenuImportButton(
-                                link="plugins:example_plugin:examplemodel_import",
-                                permissions=[
-                                    "example_plugin.add_examplemodel"
-                                ],
-                            ),
-                        ),
+                        permissions=["example_plugin.view_examplemodel"],
                     ),
                 ),
             ),
@@ -107,16 +47,18 @@ menu_items = (
 A `NavMenuTab` has the following attributes:
 
 * `name` - Display name to be shown in navigation menu
-* `weight` - Defines the position the object should be displayed at (optional)
-* `permissions` - A list of permissions required to display this link (optional)
+* `permissions` - A list of permissions required to display this object (optional)
 * `groups` - List or tuple of `NavMenuGroup`
 
+--- 2.0.0
+    As the sequence of menu "tabs"/"contexts" in Nautobot is now constant, the `weight` property has been removed from `NavMenuTab`.
+
 A `NavMenuGroup` has the following attributes:
 
 * `name` - Display name to be shown in navigation menu
 * `weight` - Defines the position the object should be displayed at (optional)
-* `permissions` - A list of permissions required to display this link (optional)
-* `items` - List or tuple of `NavMenuItem`
+* `permissions` - A list of permissions required to display this object (optional)
+* `items` - List or tuple of `NavMenuGroup` and/or `NavMenuItem`
 
 A `NavMenuItem` has the following attributes:
 
@@ -124,19 +66,6 @@ A `NavMenuItem` has the following attributes:
 * `name` - The text presented to the user
 * `weight` - Defines the position the object should be displayed at (optional)
 * `permissions` - A list of permissions required to display this link (optional)
-* `buttons` - An iterable of NavMenuButton (or subclasses of NavMenuButton) instances to display (optional)
-
-!!! note
-    Any buttons associated within a menu item will be hidden if the user does not have permission to access the menu item, regardless of what permissions are set on the buttons.
 
-A `NavMenuButton` has the following attributes:
-
-* `title` - The tooltip text (displayed when the mouse hovers over the button)
-* `link` - The name of the URL path to which this button links
-* `weight` - Defines the position the object should be displayed at (optional)
-* `icon_class` - Button icon CSS classes (Nautobot currently supports [Material Design Icons](https://materialdesignicons.com) or one of the choices provided by `ButtonActionIconChoices`)
-* `button_class` - One of the choices provided by `ButtonActionColorChoices` (optional)
-* `permissions` - A list of permissions required to display this button (optional)
-
-!!! note
-    `NavMenuAddButton` and `NavMenuImportButton` are subclasses of `NavMenuButton` that can be used to provide the commonly used "Add" and "Import" buttons.
+--- 2.0.0
+    The `buttons` attribute was removed from `NavMenuItem`.

nautobot/docs/development/react-ui.md

@@ -0,0 +1,105 @@
+# Building the React UI
+
+## Introduction
+
+Nautobot 2.0 introduces a new user interface built on React. This new UI will eventually be a complete replacement for the previous Django-based UI. It currently prioritizes read-only operations for core views. In subsequent releases, more operations and features will become available in this new UI.
+
+## Design Patterns
+
+A key change with moving to a client-side application for the user interface is that the application is now stateful. This means that the application is aware of the current state of the user interface, and can update the UI without requiring a page refresh. This is a significant change from the previous Django-based UI, which was stateless. In order to achieve this, a perspective on how the UI is rendered is required. Since much of the data is retrieved from the API, the UI is rendered in two phases:
+
+- **Phase 1**: The UI is rendered with placeholder data, and the API is queried for the actual data
+- **Phase 2**: The UI is re-rendered with the actual data
+
+This encourages the UI to be built in a way that is resilient to changes in the data, and allows the UI to be updated without requiring a page refresh. Placeholder data can either be empty, for example on a list view this is easy: an empty list `[]`. But in more complex cases, a view may choose to show a loading indicator until the data is available.
+
+In most cases, we build the UI with the preference we only display the final component once the data is available and display a loading indicator until then.
+
+### State Management
+
+The React UI is built with a concept of state management, which is handled by Redux. There is a single state store that is used to manage the state of the entire application, split into two core sections:
+
+- **Application State**: Managed by Redux
+    - Is the user logged in?
+    - What is the current user?
+    - What is the current page?
+    - What are the models and navigation menu the user can access?
+- **API State**: Managed by RTK Query (a subset library provided by Redux)
+    - Previous responses to detail and list requests
+
+These sections are known as "slices" of state, and have their own methods for updating and retrieving state. For more information on Redux, see the [Redux documentation](https://redux.js.org/).
+
+### Hooks
+
+The React UI uses hooks to manage state and side effects. Hooks are functions that let you "hook into" React state and lifecycle features. To learn more about hooks, see the [React Hooks documentation](https://react.dev/reference/react).
+
+## Getting Started With Development
+
+The libraries and tools used to build the React UI are:
+
+- [React](https://reactjs.org/)
+- [React Router](https://reactrouter.com/)
+- [Chakra UI](https://chakra-ui.com/)
+- [Redux](https://redux.js.org/)
+- [React Redux](https://react-redux.js.org/)
+- [RTK Query](https://redux-toolkit.js.org/rtk-query/overview)
+
+### Documenting Your Code
+
+The UI uses JS Doc to document the code. For more information on JS Doc, see the [JS Doc website](https://jsdoc.app/).
+
+We prefer to use the `@param` and `@returns` tags to document the parameters and return values of functions. For example:
+
+```js
+/**
+ * Given an API payload with session information, updates the state with the session information
+ * @param {Object} state - The current state
+ * @param {Object} action - The called-with payload and action type
+ * @returns The updated state
+ */
+updateAuthStateWithSession(state, action) {
+    //... 
+}
+```
+
+### Linting & Formatting
+
+#### Linting
+
+The UI uses ESLint to lint the code. For more information on ESLint, see the [ESLint website](https://eslint.org/).
+
+To check for linting errors, run the following command:
+
+```shell
+invoke eslint
+```
+
+To automatically fix some linting errors, run the following command:
+
+```shell
+invoke eslint -a
+```
+
+#### Formatting
+
+The UI uses Prettier to format the code. For more information on Prettier, see the [Prettier website](https://prettier.io/).
+
+To check for linting errors, run the following command:
+
+```shell
+invoke prettier
+```
+
+To automatically format the code, run the following command:
+
+```shell
+invoke prettier -a
+```
+
+## Additional Links
+
+Here are some links to resources that may be helpful when working with the React UI:
+
+- [React and Effects](https://react.dev/learn/synchronizing-with-effects)
+- [RTK Query and Asynchronous Hooks](https://redux-toolkit.js.org/rtk-query/usage/queries#query-hook-options)
+- [Using useDispatch](https://react-redux.js.org/api/hooks#usedispatch)

nautobot/docs/development/role-internals.md

@@ -5,7 +5,7 @@
     data models of their own that implement a `role` field. Proceed at your
     own risk!
 
-Any model that is intended to have a `role` field must inherit from either of these two mixins: `nautobot.extras.models.roles.RoleModelMixin` or `nautobot.extras.models.roles.RoleRequiredRoleModelMixin`. The `RoleModelMixin` adds a nullable `role` field, while the `RoleRequiredRoleModelMixin` adds a required `role` field. This abstract model will add an `nautobot.extras.models.roles.RoleField` 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 `role` field must use a `nautobot.extras.models.roles.RoleField` field for its foreign-key to the Role 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`).
 
 ## `RoleField` model field
 
@@ -23,8 +23,6 @@ Any filter form that is intended to have a `role` field must inherit from `nauto
 
 Any bulk edit form that is intended to have a `role` field must inherit from `nautobot.extras.forms.RoleModelBulkEditFormMixin`. This mixin adds a non-required `role` field to the form, and constrains the eligible role choices to the object type being edited.
 
-Any CSV import form that is intended to have a required or non-required `role` field must inherit from either `nautobot.extras.forms.RoleRequiredRoleModelCSVFormMixin` or `nautobot.extras.forms.RoleModelCSVFormMixin`, respectively, which adds the specified role field to the form and constrains the eligible role choices to the object type being imported.
-
 ## `RoleSerializerField` serializer field
 
 Any serializer that is intended to have a `role` field must either inherit from one of these:

nautobot/docs/development/style-guide.md

@@ -4,11 +4,13 @@ Nautobot generally follows the [Django style guide](https://docs.djangoproject.c
 
 * [Flake8](https://flake8.pycqa.org/) is used to validate code style.
 * [Black](https://black.readthedocs.io/) is used to enforce code formatting conventions.
+* [ESLint](https://eslint.org) is used to validate code style for the UI.
+* [Prettier](https://prettier.io) is used to enforce code formatting conventions for the UI.
 * [Pylint](https://pylint.pycqa.org/en/latest/) is used for Python static code analysis.
 * [Hadolint](https://github.com/hadolint/hadolint) is used to lint and validate Docker best practices in the Dockerfile.
 * [MarkdownLint-cli](https://github.com/igorshubovych/markdownlint-cli) is used to lint and validate Markdown (documentation) files.
 
-Nautobot-specific configuration of these tools is maintained in the files `.flake8`, `.markdownlint.yml`, or `pyproject.toml` as appropriate to the individual tool.
+Nautobot-specific configuration of these tools is maintained in the files `.flake8`, `.markdownlint.yml`, `.prettierrc`, `package.json`, or `pyproject.toml` as appropriate to the individual tool.
 
 It is strongly recommended to include all of the above tools as part of your commit process before opening any pull request. A Git commit hook is provided in the source at `scripts/git-hooks/pre-commit`. Linking to this script from `.git/hooks/` will invoke these tools prior to every commit attempt and abort if the validation fails.
 
@@ -22,6 +24,8 @@ You can also invoke these utilities manually against the development Docker cont
 ```no-highlight
 invoke flake8
 invoke black
+invoke eslint
+invoke prettier
 invoke check-migrations
 invoke hadolint
 invoke markdownlint
@@ -53,8 +57,6 @@ New dependencies can be added to the project via the `poetry add` command. This
 
 * Every model should have a docstring. Every custom method should include an explanation of its function.
 
-* Nested API serializers generate minimal representations of an object. These are stored separately from the primary serializers to avoid circular dependencies. Always import nested serializers from other apps directly. For example, from within the DCIM app you would write `from nautobot.ipam.api.nested_serializers import NestedIPAddressSerializer`.
-
 * The combination of `nautobot.core.filters.BaseFilterSet`, `nautobot.extras.filters.CreatedUpdatedModelFilterSetMixin`, `nautobot.extras.filters.CustomFieldModelFilterSetMixin`, and `nautobot.extras.filters.RelationshipModelFilterSetMixin` is such a common use case throughout the code base that they have a helper class which combines all of these at `nautobot.extras.NautobotFilterSet`. Use this helper class if you need the functionality from these classes.
 
 * The combination of `nautobot.core.forms.BootstrapMixin`, `nautobot.extras.forms.CustomFieldModelFormMixin`, `nautobot.extras.forms.RelationshipModelFormMixin` and `nautobot.extras.forms.NoteModelFormMixin` is such a common use case throughout the code base that they have a helper class which combines all of these at `nautobot.extras.forms.NautobotModelForm`. Use this helper class if you need the functionality from these classes.
@@ -67,7 +69,7 @@ New dependencies can be added to the project via the `poetry add` command. This
 
     * API serializers for most models should inherit from `nautobot.extras.api.serializers.NautobotModelSerializer` and any appropriate mixins. Only use more abstract base classes such as ValidatedModelSerializer where absolutely required.
 
-    * `NautobotModelSerializer` will automatically add serializer fields for `id`, `created`/`last_updated` (if applicable), `custom_fields`, `computed_fields`, and `relationships`, so there's generally no need to explicitly declare these fields in `.Meta.fields` of each serializer class. Similarly, `TaggedModelSerializerMixin` and `StatusModelSerializerMixin` will automatically add the `tags` and `status` fields when included in a serializer class.
+    * `NautobotModelSerializer` will automatically add serializer fields for `id`, `created`/`last_updated` (if applicable), `custom_fields`, `computed_fields`, and `relationships`, so there's generally no need to explicitly declare these fields in `.Meta.fields` of each serializer class. Similarly, `TaggedModelSerializerMixin` and `` will automatically add the `tags` and `status` fields when included in a serializer class.
 
     * API Views for most models should inherit from `nautobot.extras.api.views.NautobotModelViewSet`. Only use more abstract base classes such as `ModelViewSet` where absolutely required.
 

nautobot/docs/index.md

@@ -72,7 +72,7 @@ Nautobot is built on the [Django](https://djangoproject.com/) Python Web framewo
 | WSGI service       | uWSGI or Gunicorn               |
 | Application        | Django/Python                   |
 | Database           | PostgreSQL 9.6+ or MySQL 8.0+   |
-| Cache              | Redis/django-cacheops           |
+| Cache              | Django/Redis                    |
 | Task queuing       | Redis/Celery                    |
 | Live device access | NAPALM                          |
 
@@ -80,7 +80,8 @@ Nautobot is built on the [Django](https://djangoproject.com/) Python Web framewo
     MySQL support was added.
 
 --- 2.0.0
-    django-rq support was removed.
+    - `django-rq` support was removed.
+    - `django-cacheops` usage was removed and replaced with Django's native caching features.
 
 The following diagram displays how data travels through Nautobot's application stack.
 

nautobot/docs/installation/migrating-from-netbox.md

@@ -69,28 +69,16 @@ The following backwards-incompatible changes have been made to the data model in
 
 ### Status Fields
 
-!!! tip
-    Status names are now lower-cased when setting the `status` field on CSV imports. The `slug` value is used for create/update of objects and for filtering in the API.
-
-A new [`Status`](../models/extras/status.md) model has been added to represent the `status` field for many models. Each status has a human-readable `name` field (e.g. `Active`), and a `slug` field (e.g. `active`).
+A new [`Status`](../models/extras/status.md) model has been added to represent the `status` field for many models. Each status has a human-readable `name` field (e.g. `Active`), a `color`, a `description`, and a set of `content_types` that it can be applied to (for example, `Device` and `Location`).
 
 ### Display name
 
 Several models such as device type and VLAN exposed a `display_name` property, which has now been renamed to `display`. In fact, there are several other instances, especially in the REST API, where the `display_name` field was used and as such, all instances have been renamed to `display`.
 
-#### CSV Imports
-
-When using CSV import to define a `status` field on imported objects, such as when importing Devices or Prefixes, the `Status.slug` field is used.
-
-For example, the built-in **Active** status has a slug of `active`, so the `active` value would be used for import.
-
 #### Default Choices
 
 Because `status` fields are now stored in the database, they cannot have a default value, just like other similar objects like Device Roles or Device Types. In cases where `status` was not required to be set because it would use the default value, you must now provide a `status` yourself.  
 
-!!! note
-    For consistency in the API, the `slug` value of a `status` is used when creating or updating an object.
-
 #### Choices in Code
 
 All `*StatusChoices` enums used for populated `status` field choices (such as `nautobot.dcim.choices.DeviceStatusChoices`) are deprecated. Any code you have that is leveraging these will now result in an error when performing lookups on objects with `status` fields.
@@ -145,10 +133,10 @@ All IPAM objects with network field types (`ipam.IPAddress`, and `ipam.Prefix`)
 
 Below is a summary of the underlying technical changes to network fields. These will be explained in more detail in the following sections.
 
-- For `IPAddress`, the `address` field was exploded out to `host`, `broadcast`, and `prefix_length` fields; `address` was converted into a computed field.
+- For `IPAddress`, the `address` field was exploded out to `host` and `mask_length` fields; `address` was converted into a computed field.
 - For `Prefix` objects, the `prefix` field was exploded out to `network`, `broadcast`, and `prefix_length` fields; `prefix` was converted into a computed field.
 - The `host`, `network`, and `broadcast` fields are now of a `varbinary` database type, which is represented as a packed binary integer (for example, the host `1.1.1.1` is packed as `b"\x01\x01\x01\x01"`)
-- Network membership queries are accomplished by triangulating the "position" of an address using the IP, broadcast, and prefix length of the source and target addresses.
+- Network membership queries are accomplished by triangulating the "position" of an address using the `host` of the `IPAddress` and the `network` and `broadcast` of the `Prefix`.
 
 !!! note
     You should never have to worry about the binary nature of how the network fields are stored in the database! The Django database ORM takes care of it all!
@@ -159,7 +147,7 @@ The following fields have changed when working with `ipam.IPAddress` objects:
 
 ##### `address` is now a computed field
 
-This field is computed from `{host}/{prefix_length}` and is represented as a `netaddr.IPNetwork` object.
+This field is computed from `{host}/{mask_length}` and is represented as a `netaddr.IPNetwork` object.
 
 ```python
 >>> ip = IPAddress(address="1.1.1.1/30")
@@ -185,7 +173,7 @@ IPNetwork('1.1.1.1/30')
 ```
 
 !!! note
-    If you use a `prefix_length` other than `/32` (IPv4) or `/128` (IPv6) it **must** be included in your lookups
+    If you use a `mask_length` other than `/32` (IPv4) or `/128` (IPv6) it **must** be included in your lookups
 
 This field *cannot be used in **nested** filter expressions*:
 
@@ -209,47 +197,28 @@ This field *can* be used in nested filter expressions, for example:
 >>> Device.objects.filter(primary_ip4__host="1.1.1.1")
 ```
 
-##### IPAddress `prefix_length` contains the prefix length
+##### IPAddress `mask_length` contains the prefix length
 
 This is an integer, such as `30` for `/30`.
 
 ```python
->>> ip.prefix_length
+>>> ip.mask_length
 30
 ```
 
-For IP addresses with a prefix length other than a host prefix, you will need to filter using `host` and `prefix_length` fields for greater accuracy.
+For IP addresses with a mask length other than a host prefix, you will need to filter using `host` and `mask_length` fields for greater accuracy.
 
-For example, if you have multiple `IPAddress` objects with the same `host` value but different `prefix_length`:
+For example, if you have multiple `IPAddress` objects with the same `host` value but different `mask_length`:
 
 ```python
 >>> IPAddress.objects.create(address="1.1.1.1/32")
 <IPAddress: 1.1.1.1/32>
 >>> IPAddress.objects.filter(host="1.1.1.1")
 <IPAddressQuerySet [<IPAddress: 1.1.1.1/30>, <IPAddress: 1.1.1.1/32>]>
->>> IPAddress.objects.filter(host="1.1.1.1", prefix_length=30)
+>>> IPAddress.objects.filter(host="1.1.1.1", mask_length=30)
 <IPAddressQuerySet [<IPAddress: 1.1.1.1/30>]>
 ```
 
-##### IPAddress `broadcast` contains the broadcast address
-
-If the prefix length is that of a host prefix (e.g. `/32`), `broadcast` will be the same as the `host` :
-
-```python
->>> IPAddress.objects.get(address="1.1.1.1/32").broadcast
-'1.1.1.1'
-```
-
-If the prefix length is any larger (e.g. `/24`), `broadcast` will be that of the containing network for that prefix length (e.g. `1.1.1.255`):
-
-```python
->>> IPAddress.objects.create(address="1.1.1.1/24").broadcast
-'1.1.1.255'
-```
-
-!!! note
-    This field is largely for internal use only for facilitating network membership queries and it is not recommend that you use it for filtering.
-
 #### Changes to `Aggregate` and `Prefix`
 
 The following fields have changed when working with `ipam.Aggregate` and `ipam.Prefix` objects.
@@ -349,7 +318,7 @@ Prefix.objects.filter(prefix__net_mask_length=value)
 Nautobot:
 
 ```python
-IPAddress.objects.filter(prefix_length=value)
+IPAddress.objects.filter(mask_length=value)
 # or
 Prefix.objects.filter(prefix_length=value)
 ```

nautobot/docs/installation/nautobot.md

@@ -204,7 +204,7 @@ Edit `$NAUTOBOT_ROOT/nautobot_config.py`, and head over to the documentation on
 
 * [`ALLOWED_HOSTS`](../configuration/required-settings.md#allowed_hosts): You must set this value. This can be set to `["*"]` for a quick start, but this value is not suitable for production deployment.
 * [`DATABASES`](../configuration/required-settings.md#databases): Database connection parameters. If you installed your database server on the same system as Nautobot, you'll need to update the `USER` and `PASSWORD` fields here. If you are using MySQL, you'll also need to update the `ENGINE` field, changing the default database driver suffix from `django.db.backends.postgresql` to `django.db.backends.mysql`.
-* **Redis settings**: Redis configuration requires multiple settings including [`CACHEOPS_REDIS`](../configuration/required-settings.md#cacheops_redis), if different from the defaults. If you installed Redis on the same system as Nautobot, you do not need to change these settings.
+* **Redis settings**: Redis configuration requires multiple settings, if different from the defaults. If you installed Redis on the same system as Nautobot, you do not need to change these settings.
 
 !!! important
     You absolutely must update your required settings in your `nautobot_config.py` or Nautobot will not work.

nautobot/docs/installation/tables/v2-api-behavior-changes.yaml

@@ -0,0 +1,70 @@
+---
+- Model: "(all)"
+  Field: "created"
+  Changes: "Now is a date/time rather than only a date"
+- Model: "Cable"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "Circuit"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "Device"
+  Field: "config_context"
+  Changes: "Now is only included when specifically requested with `?include=config_context` query parameter"
+- Model: "Device"
+  Field: "location"
+  Changes: "Now required, no longer optional"
+- Model: "Device"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "DeviceRedundancyGroup"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "Interface"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "IPAddress"
+  Field: "role"
+  Changes: "Now is a foreign-key to `Role` rather than a string"
+- Model: "IPAddress"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "JobLogEntry"
+  Field: "display"
+  Changes: "Now contains the message text rather than the message timestamp"
+- Model: "Location"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "PowerFeed"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "PowerPanel"
+  Field: "location"
+  Changes: "Now required, no longer optional"
+- Model: "Prefix"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "Rack"
+  Field: "location"
+  Changes: "Now required, no longer optional"
+- Model: "Rack"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "RackGroup"
+  Field: "location"
+  Changes: "Now required, no longer optional"
+- Model: "RackGroup"
+  Field: "rack_count"
+  Changes: "Now only counts Racks directly belonging to this RackGroup, not those belonging to its descendants"
+- Model: "TenantGroup"
+  Field: "tenant_count"
+  Changes: "Now only counts Tenants directly belonging to this TenantGroup, not those belonging to its descendants"
+- Model: "VirtualMachine"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "VLAN"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"
+- Model: "VMInterface"
+  Field: "status"
+  Changes: "Now is a foreign-key rather than a pseudo-enum"