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

nautobot/docs/development/getting-started.md

@@ -222,6 +222,7 @@ Available tasks:
   destroy                Destroy all containers and volumes.
   docker-push            Tags and pushes docker images to the appropriate repos, intended for release use only.
   dumpdata               Dump data from database to db_output file.
+  eslint                 Check for ESLint rule compliance and other style issues.
   flake8                 Check for PEP8 compliance and other style issues.
   hadolint               Check Dockerfile for hadolint compliance and other style issues.
   integration-test       Run Nautobot integration tests.
@@ -232,6 +233,7 @@ Available tasks:
   nbshell                Launch an interactive Nautobot shell.
   performance-test       Run Nautobot performance tests.
   post-upgrade           Performs Nautobot common post-upgrade operations using a single entrypoint.
+  prettier               Check Node.JS code style with Prettier.
   pylint                 Perform static analysis of Nautobot code.
   restart                Gracefully restart containers.
   serve-docs             Runs local instance of mkdocs serve (ctrl-c to stop).
@@ -240,6 +242,7 @@ Available tasks:
   tests                  Run all linters and unit tests.
   unittest               Run Nautobot unit tests.
   unittest-coverage      Report on code test coverage as measured by 'invoke unittest'.
+  unittest-ui            Run Nautobot UI unit tests.
   vscode                 Launch Visual Studio Code with the appropriate Environment variables to run in a container.
 ```
 
@@ -254,12 +257,12 @@ A development environment can be easily started up from the root of the project
 
 Additional useful commands for the development environment:
 
-* `invoke start [-s servicename]` - Starts Docker containers for Nautobot, PostgreSQL, Redis, Celery, and Celery Beat (or a specific container/service, such as `invoke start -s redis`) to run in the background with debug disabled
+* `invoke start [-s servicename]` - Starts Docker containers for Nautobot, PostgreSQL, Redis, NGINX, Node.js, Celery, and Celery Beat (or a specific container/service, such as `invoke start -s redis`) to run in the background with debug disabled
 * `invoke cli [-s servicename]` - Launch a `bash` shell inside the specified service container (if none is specified, defaults to the Nautobot container)
 * `invoke stop [-s servicename]` - Stops all containers (or a specific container/service) created by `invoke start`
 
 !!! note
-    The mkdocs container must be started manually with `invoke start -s mkdocs`. It will not start automatically with the `invoke start` or `invoke debug` commands.
+    The `mkdocs` and `storybook` containers (see later) are not started automatically by `invoke start` or `invoke debug`. If desired, these may be started manually with `invoke start -s mkdocs` or `invoke start -s storybook` as appropriate.
 
 !!! tip
     The Nautobot server uses a Django webservice and worker uses watchdog to provide automatic reload of your web and worker servers in **most** cases when using `invoke start` or `invoke debug`.
@@ -319,6 +322,22 @@ brew install hadolint
 brew install markdownlint-cli
 ```
 
+#### Install npm
+
+[npm](https://www.npmjs.com/) is the tool used to install and compile the Nautobot front-end UI. On macOS with [Homebrew](https://brew.sh) you can install npm by running:
+
+```no-highlight
+brew install npm
+```
+
+You should then move to the `nautobot_ui/` subdirectory and run `npm install` to install all of the JS dependencies for local development of the Nautobot UI:
+
+```no-highlight
+npm install
+```
+
+Be sure to switch back to the base directory of the repository after you do this.
+
 #### Creating a Python Virtual Environment
 
 A Python [virtual environment](https://docs.python.org/3/tutorial/venv.html) (or *virtualenv*) is like a container for a set of Python packages. A virtualenv allow you to build environments suited to specific projects without interfering with system packages or other projects. When installed per the documentation, Nautobot uses a virtual environment in production.
@@ -450,7 +469,7 @@ A newly created configuration includes sane defaults. If you need to customize t
 
 * [`ALLOWED_HOSTS`](../configuration/required-settings.md#allowed_hosts): This can be set to `["*"]` for development purposes and must be set if `DEBUG=False`
 * [`DATABASES`](../configuration/required-settings.md#databases): Database connection parameters, if different from the defaults
-* **Redis settings**: Redis configuration requires multiple settings including [`CACHEOPS_REDIS`](../configuration/required-settings.md#cacheops_redis). The defaults should be fine for development.
+* **Redis settings**: Redis configuration requires multiple settings. The defaults should be fine for development.
 * [`DEBUG`](../configuration/optional-settings.md#debug): Set to `True` to enable verbose exception logging and, if installed, the [Django debug toolbar](https://django-debug-toolbar.readthedocs.io/en/latest/)
 * [`EXTRA_INSTALLED_APPS`](../configuration/optional-settings.md#extra-applications): Optionally provide a list of extra Django apps/plugins you may desire to use for development
 
@@ -502,7 +521,36 @@ Quit the server with CONTROL-C.
 
 Please see the [official Django documentation on `runserver`](https://docs.djangoproject.com/en/stable/ref/django-admin/#runserver) for more information.
 
-You can then log into the development server at `localhost:8080` with the [superuser](#creating-a-superuser) you created.
+!!! note
+    When first started in Docker Compose, the Nautobot development server container will automatically install dependencies for building the React UI for Nautobot, then build this UI. This may take several minutes before the server becomes ready to accept web connections.
+
+You can connect to the development server at `localhost:8080`, but normally you'll want to connect to the Node.js server instead (see below).
+
+### Starting the Node.js Server
+
+In development, you should run a Node.js server instance as well. This will handle automatically rebuilding the UI when you make changes in the `nautobot/ui` directory.
+
+| Docker Compose Workflow | Virtual Environment Workflow    |
+| ----------------------- | ------------------------------- |
+| `invoke start`          | `cd nautobot/ui; npm run start` |
+
+!!! note
+    In the Docker Compose workflow, the Node.js server will delay starting until the Nautobot development server has finished the initial UI build, which may take several minutes. This is normal.
+
+You can connect to the Node.js server at `localhost:3000`.
+
+### Starting the Storybook Server
+
+When working on the UI, you may find it useful to run a [Storybook](https://storybook.js.org/) instance that provides interactive documentation of the `nautobot-ui` library used by Nautobot's user interface.
+
+| Docker Compose Workflow     | Virtual Environment Workflow    |
+| --------------------------- | ------------------------------- |
+| `invoke start -s storybook` | `TODO`                          |
+
+!!! note
+    This container is not started by default when using `invoke start`. You must individually start it using `invoke start -s storybook`.
+
+You can connect to Storybook at `localhost:6006`.
 
 ### Starting the Worker Server
 
@@ -543,7 +591,7 @@ Example output:
 # Django version 3.2.16
 # Nautobot version 2.0.0a0
 # Example Nautobot App version 1.0.0
-Python 3.7.13 (default, May 11 2022, 08:57:12)
+Python 3.8.16 (default, Mar 23 2023, 04:48:11)
 [GCC 10.2.1 20210110] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
@@ -676,12 +724,14 @@ If you make changes to the REST API, you should verify that the REST API OpenAPI
 
 ### Verifying Code Style and Static Analysis
 
-To enforce best practices around consistent [coding style](style-guide.md), Nautobot uses [Flake8](https://flake8.pycqa.org/) and [Black](https://black.readthedocs.io/). Additionally, [static analysis](https://en.wikipedia.org/wiki/Static_program_analysis) of Nautobot code is performed by [Pylint](https://pylint.pycqa.org/en/latest/). You should run all of these commands and ensure that they pass fully with regard to your code changes before opening a pull request upstream.
+To enforce best practices around consistent [coding style](style-guide.md), Nautobot uses [Flake8](https://flake8.pycqa.org/),  [Black](https://black.readthedocs.io/), [ESLint](https://eslint.org), and [Prettier](https://prettier.io). Additionally, [static analysis](https://en.wikipedia.org/wiki/Static_program_analysis) of Nautobot code is performed by [Pylint](https://pylint.pycqa.org/en/latest/). You should run all of these commands and ensure that they pass fully with regard to your code changes before opening a pull request upstream.
 
 | Docker Compose Workflow | Virtual Environment Workflow                                                                            |
 | ----------------------- | ------------------------------------------------------------------------------------------------------- |
 | `invoke flake8`         | `flake8`                                                                                                |
 | `invoke black`          | `black`                                                                                                 |
+| `invoke eslint`         | `npx eslint .`                                                                                          |
+| `invoke prettier`       | `npx prettier -c .`                                                                                     |
 | `invoke pylint`         | `nautobot-server pylint nautobot tasks.py && nautobot-server pylint --recursive development/ examples/` |
 
 ### Handling Migrations

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/release-checklist.md

@@ -209,7 +209,7 @@ poetry publish --username __token__ --password <api_token>
 Build the images locally:
 
 ```no-highlight
-for ver in 3.7 3.8 3.9 3.10; do
+for ver in 3.8 3.9 3.10; do
   export INVOKE_NAUTOBOT_PYTHON_VER=$ver
   invoke buildx --target final --tag networktocode/nautobot-py${INVOKE_NAUTOBOT_PYTHON_VER}:local
   invoke buildx --target final-dev --tag networktocode/nautobot-dev-py${INVOKE_NAUTOBOT_PYTHON_VER}:local
@@ -231,7 +231,7 @@ nautobot:
     You should *not* include `docker-compose.dev.yml` in this test scenario!
 
 ```no-highlight
-for ver in 3.7 3.8 3.9 3.10; do
+for ver in 3.8 3.9 3.10; do
   export INVOKE_NAUTOBOT_PYTHON_VER=$ver
   invoke stop
   invoke integration-tests
@@ -243,7 +243,7 @@ Push the images to GitHub Container Registry and Docker Hub
 ```no-highlight
 docker login
 docker login ghcr.io
-for ver in 3.7 3.8 3.9 3.10; do
+for ver in 3.8 3.9 3.10; do
   export INVOKE_NAUTOBOT_PYTHON_VER=$ver
   invoke docker-push main
 done

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/development/templates.md

@@ -45,9 +45,10 @@ The base template for listing objects is `generic/object_list.html`, with the fo
 
 * `buttons`: may provide a set of buttons at the top right of the page, to the
   left of the table configuration button.
-* `sidebar`: may implement a sidebar below the search form on the right.
 * `bulk_buttons`: may be a set of buttons at the bottom of the table, to the
   left of potential bulk edit or delete buttons.
+* `header_extra`: may provide extra information to display just above the table,
+  to the left.
 
 ## Object Edit
 

nautobot/docs/docker/index.md

@@ -1,6 +1,9 @@
 # Nautobot Docker Images
 
-Nautobot is packaged as a Docker image for use in a production environment. The published image is based on the `python:3.7-slim` image to maintain the most compatibility with Nautobot deployments. The Docker image and deployment strategies are being actively developed, check back here or join the **#nautobot** channel on [Network to Code's Slack community](https://slack.networktocode.com/) for the most up to date information.
+Nautobot is packaged as a Docker image for use in a production environment. The published image is based on the `python:3.8-slim` image to maintain the most compatibility with Nautobot deployments. The Docker image and deployment strategies are being actively developed, check back here or join the **#nautobot** channel on [Network to Code's Slack community](https://slack.networktocode.com/) for the most up to date information.
+
++/- 2.0.0
+    The base image was changed from `python:3.7-slim` to `python:3.8-slim` due to the end-of-life of Python 3.7.
 
 ## Platforms
 
@@ -28,31 +31,30 @@ The following tags are available on both Docker Hub and the GitHub Container Reg
 
 | Tag                                                           | Nautobot Version      | Python Version | Example        |
 | ------------------------------------------------------------- | --------------------- | -------------- | -------------- |
-| `${NAUTOBOT_VER}`                                             | As specified          | 3.7            | `1.2.7`        |
-| `${NAUTOBOT_VER}-py${PYTHON_VER}`                             | As specified          | As specified   | `1.2.7-py3.8`  |
-| `${NAUTOBOT_MAJOR_VER}.${NAUTOBOT_MINOR_VER}`                 | As specified          | 3.7            | `1.2`          |
-| `${NAUTOBOT_MAJOR_VER}.${NAUTOBOT_MINOR_VER}-py${PYTHON_VER}` | As specified          | As specified   | `1.2-py3.8`    |
-| `stable`                                                      | Latest stable release | 3.7            | `stable`       |
+| `${NAUTOBOT_VER}`                                             | As specified          | 3.8            | `2.0.0`        |
+| `${NAUTOBOT_VER}-py${PYTHON_VER}`                             | As specified          | As specified   | `2.0.0-py3.8`  |
+| `${NAUTOBOT_MAJOR_VER}.${NAUTOBOT_MINOR_VER}`                 | As specified          | 3.8            | `2.0`          |
+| `${NAUTOBOT_MAJOR_VER}.${NAUTOBOT_MINOR_VER}-py${PYTHON_VER}` | As specified          | As specified   | `2.0-py3.8`    |
+| `stable`                                                      | Latest stable release | 3.8            | `stable`       |
 | `stable-py${PYTHON_VER}`                                      | Latest stable release | As specified   | `stable-py3.8` |
 
 The following additional tags are only available from the GitHub Container Registry:
 
 | Tag                                                  | Nautobot Branch              | Python Version |
 | ---------------------------------------------------- | ---------------------------- | -------------- |
-| `latest`                                             | `develop`, the latest commit | 3.7            |
+| `latest`                                             | `develop`, the latest commit | 3.8            |
 | `latest-py${PYTHON_VER}`                             | `develop`, the latest commit | As specified   |
-| `develop`                                            | `develop`, the latest commit | 3.7            |
+| `develop`                                            | `develop`, the latest commit | 3.8            |
 | `develop-py${PYTHON_VER}`                            | `develop`, the latest commit | As specified   |
-| `develop-${GIT_SHA:0:7}-$(date +%s)`                 | `develop`, a specific commit | 3.7            |
+| `develop-${GIT_SHA:0:7}-$(date +%s)`                 | `develop`, a specific commit | 3.8            |
 | `develop-${GIT_SHA:0:7}-$(date +%s)-py${PYTHON_VER}` | `develop`, a specific commit | As specified   |
-| `next`                                               | `next`, the latest commit    | 3.7            |
+| `next`                                               | `next`, the latest commit    | 3.8            |
 | `next-py${PYTHON_VER}`                               | `next`, the latest commit    | As specified   |
-| `next-${GIT_SHA:0:7}-$(date +%s)`                    | `next`, a specific commit    | 3.7            |
+| `next-${GIT_SHA:0:7}-$(date +%s)`                    | `next`, a specific commit    | 3.8            |
 | `next-${GIT_SHA:0:7}-$(date +%s)-py${PYTHON_VER}`    | `next`, a specific commit    | As specified   |
 
 Currently images are pushed for the following python versions:
 
-* 3.7
 * 3.8
 * 3.9
 * 3.10
@@ -224,7 +226,7 @@ Example output:
 
 ```no-highlight
 REPOSITORY                                       TAG                              IMAGE ID       CREATED          SIZE
-local/nautobot-dev                               local-py3.7                      0d93eec7dfea   5 minutes ago    1.31GB
+local/nautobot-dev                               local-py3.8                      0d93eec7dfea   5 minutes ago    1.31GB
 ```
 
 If you need to build or test the `final` image, you must set your `invoke.yml` to use `docker-compose.final.yml` in place of `docker-compose.dev.yml`:
@@ -259,7 +261,7 @@ Example output:
 
 ```no-highlight
 REPOSITORY                                       TAG                              IMAGE ID       CREATED          SIZE
-local/nautobot-final                             local-py3.7                      e03e752fcc6b   27 minutes ago   629MB
+local/nautobot-final                             local-py3.8                      e03e752fcc6b   27 minutes ago   629MB
 ```
 
 Similarly, you can use `docker-compose.final-dev.yml` if you wish to build and test the `final-dev` image.

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.
 
@@ -88,7 +89,7 @@ The following diagram displays how data travels through Nautobot's application s
 
 ## Supported Python Versions
 
-Nautobot supports Python 3.7, 3.8, 3.9, and 3.10.
+Nautobot supports Python 3.8, 3.9, and 3.10.
 
 +++ 1.3.0
     Python 3.10 support was added.
@@ -96,6 +97,9 @@ Nautobot supports Python 3.7, 3.8, 3.9, and 3.10.
 --- 1.3.0
     Python 3.6 support was removed.
 
+--- 2.0.0
+    Python 3.7 support was removed.
+
 ## Getting Started
 
 See the [installation guide](installation/index.md) for help getting Nautobot up and running quickly.

nautobot/docs/installation/index.md

@@ -14,7 +14,7 @@ The following minimum versions are required for Nautobot to operate:
 
 | Dependency | Role         | Minimum Version |
 |------------|--------------|-----------------|
-| Python     | Application  | 3.7             |
+| Python     | Application  | 3.8             |
 | PostgreSQL | Database     | 9.6             |
 | MySQL      | Database     | 8.0             |
 | Redis      | Cache, Queue | 4.0             |
@@ -32,6 +32,9 @@ The following minimum versions are required for Nautobot to operate:
 --- 1.3.0
     Python 3.6 support was removed.
 
+--- 2.0.0
+    Python 3.7 support was removed.
+
 Nautobot will not work without these dependencies.
 
 #### Python