nautobot 2.0.4__py3-none-any.whl → 2.1.0b1__py3-none-any.whl

nautobot/docs/development/core/style-guide.md

@@ -1,200 +0,0 @@
-# Style Guide
-
-Nautobot generally follows the [Django style guide](https://docs.djangoproject.com/en/stable/internals/contributing/writing-code/coding-style/), which is itself based on [PEP 8](https://www.python.org/dev/peps/pep-0008/). The following tools are used to enforce coding style and best practices:
-
-* [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`, `.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.
-
-```bash
-cd .git/hooks/
-ln -s ../../scripts/git-hooks/pre-commit
-```
-
-You can also invoke these utilities manually against the development Docker containers by running:
-
-```no-highlight
-invoke flake8
-invoke black
-invoke eslint
-invoke prettier
-invoke check-migrations
-invoke hadolint
-invoke markdownlint
-invoke pylint
-```
-
-## Introducing New Dependencies
-
-The introduction of a new dependency is best avoided unless it is absolutely necessary. For small features, it's generally preferable to replicate functionality within the Nautobot code base rather than to introduce reliance on an external project. This reduces both the burden of tracking new releases and our exposure to outside bugs and attacks.
-
-If there's a strong case for introducing a new dependency, it must meet the following criteria:
-
-* Its complete source code must be published and freely accessible without registration.
-* Its license must be conducive to inclusion in an open source project.
-* It must be actively maintained, with no longer than one year between releases.
-* It must be available via the [Python Package Index](https://pypi.org/) (PyPI).
-
-New dependencies can be added to the project via the `poetry add` command. This will correctly add the dependency to `pyproject.toml` as well as the `poetry.lock` file. You should then update the `pyproject.toml` with a comment providing a short description of the package and/or how Nautobot is making use of it.
-
-## General Guidance
-
-* When in doubt, remain consistent: It is better to be consistently incorrect than inconsistently correct. If you notice in the course of unrelated work a pattern that should be corrected, continue to follow the pattern for now and open a bug so that the entire code base can be evaluated at a later point.
-
-* Prioritize readability over concision. Python is a very flexible language that typically offers several options for expressing a given piece of logic, but some may be more friendly to the reader than others. (List comprehensions are particularly vulnerable to over-optimization.) Always remain considerate of the future reader who may need to interpret your code without the benefit of the context within which you are writing it.
-
-* No easter eggs. While they can be fun, Nautobot must be considered as a business-critical tool. The potential, however minor, for introducing a bug caused by unnecessary logic is best avoided entirely.
-
-* Constants (variables which generally do not change) should be declared in `constants.py` within each app.
-
-* Every model should have a docstring. Every custom method should include an explanation of its function.
-
-* 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.
-
-+++ 1.4.0
-
-    * Similarly, for filter forms, `nautobot.extras.forms.NautobotFilterForm` combines `nautobot.core.forms.BootstrapMixin`, `nautobot.extras.forms.CustomFieldModelFilterFormMixin`, and `nautobot.extras.forms.RelationshipModelFilterFormMixin`, and should be used where appropriate.
-
-    * Similarly, for bulk-edit forms, `nautobot.extras.forms.NautobotBulkEditForm` combines `nautobot.core.forms.BulkEditForm` and `nautobot.core.forms.BootstrapMixin` with `nautobot.extras.forms.CustomFieldModelBulkEditFormMixin`, `nautobot.extras.forms.RelationshipModelBulkEditFormMixin` and `nautobot.extras.forms.NoteModelBulkEditFormMixin`, and should be used where appropriate.
-
-    * 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 `` 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.
-
-## Branding
-
-* When referring to Nautobot in writing, use the proper form "Nautobot," with the letter N. The lowercase form "nautobot" should be used in code, filenames, etc.
-
-<!-- markdownlint-disable-next-line NAUTOBOTMD001 -->
-* There is an SVG form of the Nautobot logo at [nautobot/docs/nautobot_logo.svg](../../nautobot_logo.svg). It is preferred to use this logo for all purposes as it scales to arbitrary sizes without loss of resolution. If a raster image is required, the SVG logo should be converted to a PNG image of the prescribed size.
-
-## Importing Python Packages
-
-To prevent circular dependency errors and improve code readability, the following standards should be followed when importing from other python modules.
-
-### PEP8 Style Guide
-
-Nautobot follows the [PEP8 style guide's](https://peps.python.org/pep-0008/#imports) standard for importing modules. Libraries should be imported in these groups: standard library, third party libraries, then `nautobot` packages and finally try/except imports. The groups should be separated by a single blank line. Within these groups,import lines should be sorted alphanumerically by the package name. Lists of of names imported from packages should also be sorted alphanumerically.
-
-!!! example
-
-    ```py
-    from abc import ABC
-    import logging
-    from uuid import UUID
-
-    from django.db.models import CharField, DecimalField, TextField
-    import django_filters
-
-    from nautobot.dcim import models as dcim_models
-    from nautobot.extras import models
-    ```
-
-### Wildcard Imports
-
-Wildcard imports (`from foo import *`) should only be used in `__init__.py` files to import names from submodules that have a `__all__` variable defined.
-
-!!! example
-
-    ```py title="nautobot/dcim/models/__init__.py"
-    from nautobot.dcim.models.cables import *
-    from nautobot.dcim.models.device_component_templates import *
-    from nautobot.dcim.models.device_components import *
-    # etc ...
-    ```
-
-### Importing from External Packages
-
-Individual names may be imported from external packages (`from foo import some_function, SomeClass`). This differs from the standard for [importing from the `nautobot` package](#module-name-imports).
-
-### Importing Nautobot Packages
-
-#### Module Name Imports
-
-Whenever possible, imports from the `nautobot` package should use module level imports, not individual names from a module.
-
-!!! example
-
-    ```py
-    # module import
-    from nautobot.core import xyz
-
-    # name import (do not use)
-    from nautobot.core.xyz import SomeClass, some_function
-    ```
-
-#### Absolute Imports
-
-Always use absolute imports instead of relative imports.
-
-!!! example
-
-    ```py
-    # absolute import
-    from nautobot.dcim import constants
-    from nautobot.dcim.models import Device
-
-    # relative import (do not use)
-    import constants
-    from .models import Device
-    ```
-
-#### Import Style Conventions
-
-To import modules from other apps under the `nautobot` namespace, use the convention `from nautobot.<app_name> import <module> as <app_name>_<module>`. If importing from within the same app do not alias the imported namespace.
-
-!!! example
-
-    ```py title="nautobot/extras/models.py"
-    # inter-app import
-    from nautobot.dcim import models as dcim_models
-
-    # intra-app import
-    from nautobot.extras import constants
-    ```
-
-#### Resolving Name Conflicts
-
-When using external libraries you may need to import multiple different modules with the same name. In this case, the namespace from the external package should be aliased. For aliasing external libraries, use `<package>_<module>`.
-
-!!! example
-
-    ```py
-    # from within the current app
-    from nautobot.extras import models
-
-    # from a different Nautobot app
-    from nautobot.dcim import models as dcim_models
-
-    # other libraries
-    from django.db import models as django_models
-    from tree_queries import models as tree_queries_models
-    ```
-
-#### Convenience Imports
-
-Nautobot uses convenience imports in the same way that [django](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#imports) implements them. These should be leveraged whenever possible.
-
-!!! example
-
-    ```py
-    from nautobot.extras import forms
-
-    # use top level import if available:
-    forms.NoteModelFormMixin()
-
-    # instead of the full path:
-    forms.mixins.NoteModelFormMixin()
-    ```

nautobot/docs/development/core/templates.md

@@ -1,101 +0,0 @@
-# Page Templates
-
-Nautobot comes with a variety of page templates that allow for a lot of flexibility
-while keeping the page style consistent with the rest of the application.
-This document presents these templates and their features.
-
-You can use these templates as the basis for your templates by calling `{% extends '<template_name>' %}`
-at the top of your template file.
-
-## Object Detail
-
-+++ 1.2.0
-
-The most customizable template is `generic/object_detail.html`, as object detail views have a wide range of specific requirements to be accommodated. It provides the following blocks:
-
-* `header`: overloading this block allows for changing the entire top row of
-  the page, including the title, breadcrumbs, search field, and tabs.
-    * `breadcrumbs`: overloading this block allows for changing the entire
-      breadcrumbs block.
-        * `extra_breadcrumbs`: this enables extending the breadcrumbs block
-          just before the model without having to redefine the entire block.
-    * `buttons`: overloading this block allows redefining the entire button
-      section on the right of the page.
-        * `extra_buttons`: this block enables extending the buttons block
-          without losing the predefined buttons. Custom buttons will appear
-          between the plugin buttons and clone/edit/delete actions.
-    * `masthead`: is the block that contains the title. Overloading it enables
-      to change anything about the title block.
-    * `title`: is the block contained by `masthead` and wrapped in a heading
-      block. Overloading it makes it possible to change the heading text as
-      well as the page title shown in the browser.
-    * `nav_tabs`: are the navigation tabs. If overloaded, custom tabs can be
-      rendered instead of the default.
-        * `extra_nav_tabs`: this block allows to add new tabs without having to
-          override the default ones.
-* `content`: is the entire content of the page below the `header`.
-    * `content_left_page`: is a half-width column on the left. Multiple panels
-      can be rendered in a single block.
-    * `content_right_page`: is a half-width column on the right.
-    * `content_full_width_page`: is a full-width column.
-
-## Object List
-
-The base template for listing objects is `generic/object_list.html`, with the following blocks:
-
-* `buttons`: may provide a set of buttons at the top right of the page, to the
-  left of the table configuration button.
-* `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
-
-The base template for object addition or change is `generic/object_edit.html`,
-with the following blocks:
-
-* `form`: is the block in which the form gets rendered. This can be overridden
-  to provide a custom UI or UX for form views beyond what `render_form`
-  provides.
-
-## Object Import
-
-The base template for object import is `generic/object_import.html`, with the following blocks:
-
-* `tabs`: may provide tabs at the top of the page. The default import view is
-  not tabbed.
-
-## Object Deletion
-
-The base template for object deletion is `generic/object_delete.html`, with the following blocks:
-
-* `message`: is the confirmation message for deletion, which can be overridden.
-    * `message_extra`: provides a way to add to the default message without
-      overriding it.
-
-## Bulk Edit
-
-The base template for bulk object change is `generic/object_bulk_edit.html`. It
-does not provide any blocks for customizing the user experience.
-
-## Bulk Import
-
-The base template for bulk object import is `generic/object_bulk_import.html`, with the following blocks:
-
-* `tabs`: may provide tabs at the top of the page. The default import view is
-  not tabbed.
-
-## Bulk Deletion
-
-The base template for bulk object deletion is `generic/object_bulk_delete.html`, with the following blocks:
-
-* `message_extra`: provides a way to add to the default message.
-
-**Note**: contrary to the deletion of a single object, this template does *not*
-provide a way to completely override the deletion message.
-
-## Bulk Renaming
-
-The base template for renaming objects in bulk is `generic/object_bulk_rename.html`.
-It does not provide any blocks for customizing the user experience.

nautobot/docs/development/core/testing.md

@@ -1,238 +0,0 @@
-# Testing Nautobot
-
-Best practices for developing and maintaining Nautobot's automated unit/integration test suites.
-
-Unit tests are automated tests written and run to ensure that a section of the Nautobot application (known as the "unit") meets its design and behaves as intended and expected. Most commonly as a developer of or contributor to Nautobot you will be writing unit tests to exercise the code you have written. Unit tests are not meant to test how the application behaves, only the individual blocks of code, therefore use of mock data and phony connections is common in unit test code. As a guiding principle, unit tests should be fast, because they will be executed quite often.
-
-Integration tests are automated tests written and run to ensure that the Nautobot application behaves as expected when being used as it would be in practice. By contrast to unit tests, where individual units of code are being tested, integration tests rely upon the server code actually running, and web UI clients or API clients to make real connections to the service to exercise actual workflows, such as navigating to the login page, filling out the username/passwords fields, and clicking the "Log In" button.
-
-Integration testing is much more involved, and builds on top of the foundation laid by unit testing. As a guiding principle, integration tests should be comprehensive, because they are the last mile to asserting that Nautobot does what it is advertised to do. Without integration testing, we have to do it all manually, and that's no fun for anyone!
-
-## Tagging Tests
-
-By Nautobot convention, **unit** tests must be [tagged](https://docs.djangoproject.com/en/stable/topics/testing/tools/#tagging-tests) with `unit`. The base test case class `nautobot.core.testing.TestCase` has this tag, therefore any test cases inheriting from that class do not need to be explicitly tagged. All existing view and API test cases in the Nautobot test suite inherit from this class.
-
-By Nautobot convention, **integration** tests must be [tagged](https://docs.djangoproject.com/en/stable/topics/testing/tools/#tagging-tests) with `integration`. The base test case class `nautobot.core.testing.integration.SeleniumTestCase` has this tag, therefore any test cases inheriting from that class do not need to be explicitly tagged. All existing integration test cases in the Nautobot test suite inherit from this class.
-
-+/- 2.0.0
-    The base test classes moved from `nautobot.utilities.testing` to `nautobot.core.testing`.
-
-The `invoke unittest` and `invoke integration-test` commands are intentionally distinct, and the correct tagging of test cases is essential to enforcing the division between these two test categories. We never want to risk running the unit tests and integration tests at the same time. The isolation from each other is critical to a clean and manageable continuous development cycle.
-
-## Base Classes and Code Location
-
-| Test Type   | Base Class                                               | Code Location                              |
-| ----------- | -------------------------------------------------------- | ------------------------------------------ |
-| Unit        | `nautobot.core.testing.TestCase` or subclass (see below) | `nautobot/APP/tests/test_*.py`             |
-| Integration | `nautobot.core.testing.integration.SeleniumTestCase`     | `nautobot/APP/tests/integration/test_*.py` |
-
-- New unit tests **must always** inherit from `nautobot.core.testing.TestCase` or one of its subclasses. Do not use `django.test.TestCase`.
-    - API view test cases should generally inherit from one or more of the classes in `nautobot.core.testing.api.APIViewTestCases`.
-    - Filterset test cases should generally inherit from `nautobot.core.testing.filters.FilterTestCases.FilterTestCase`.
-    - Model test cases should generally inherit from `nautobot.core.testing.models.ModelTestCases.BaseModelTestCase`.
-    - View test cases should generally inherit from one or more of the classes in `nautobot.core.testing.views.ViewTestCases`.
-- New integration tests **must always** inherit from `nautobot.core.testing.integration.SeleniumTestCase`. Do not use any other base class for integration tests.
-
-+/- 2.0.0
-    The base test classes moved from `nautobot.utilities.testing` to `nautobot.core.testing`.
-
-## Generic Filter Tests
-
-+++ 2.0.0
-
-Nautobot provides a set of generic tests for testing the behavior of FilterSets. These tests are located in [`nautobot.core.testing.filters.FilterTestCase`](../../code-reference/nautobot/apps/testing.md#nautobot.core.testing.filters.FilterTestCases.FilterTestCase) and can be used to test some common filters in Nautobot.
-
-### Generic Boolean Filter Tests
-
-When using `FilterTestCase`, all filters that are instances of `nautobot.core.filters.RelatedMembershipBooleanFilter` that are not using a custom filter method will be tested to verify that the filter returns the same results as the model's queryset. `RelatedMembershipBooleanFilter` filters will be tested for both `True` and `False` values.
-
-### Generic Multiple Choice Filter Tests
-
-A `generic_filter_tests` attribute with a list of filters can be defined on the test class to run generic tests against multiple choice filters. The `generic_filter_tests` attribute should be in the following format:
-
-```python
-generic_filter_tests = (
-    # use a single item when the filter name matches the model field name
-    ["model_field"],
-    # use [filter_name, field_name] when the filter name does not match the model field name
-    ["related_object_filter", "related_object__name"],
-    # the field name is passed as a kwarg to the `queryset.filter` method, so the dunder syntax can be used to make nested queries
-    ["related_object_filter", "related_object__id"],
-)
-```
-
-### Tags Filter Test
-
-If the model being tested is a `PrimaryModel`, the `tags` filter will be automatically tested by passing at least two values to the filter and verifying that the result matches the equivalent queryset filter.
-
-## Integration Tests
-
-### Troubleshooting Integration Tests
-
-Because integration tests normally involve interacting with Nautobot through a browser via [Selenium](https://www.selenium.dev/selenium/docs/api/py/index.html) and the [Splinter](https://splinter.readthedocs.io/en/latest/) wrapper library, they can be difficult to troubleshoot directly from the Python code when a failure occurs. A common troubleshooting technique is to add a `breakpoint()` at the appropriate place in the Python test code (i.e., immediately prior to the observed failure). When the breakpoint is hit and the test pauses, you can then use a VNC viewer application (such as macOS's "Screen Sharing" app) to connect to the running Selenium instance (`localhost:15900` if using the Docker development environment; the default password if prompted is simply "`secret`"). This will allow you to interact live with the testing web browser in its current state and can often provide invaluable insight into the nature of any test failure.
-
-## Factories
-
-+++ 1.5.0
-
-Nautobot uses the [`factory_boy`](https://factoryboy.readthedocs.io/en/stable/) library as a way to generate randomized but plausible database data for use in unit and integration tests, or for convenience in populating a local development instance.
-
-Factories for each Nautobot app's models are defined in the corresponding `nautobot/APPNAME/factory.py` files. Helper classes and functions for certain common patterns are defined in `nautobot/core/factory.py`. Factories can be used directly from `nautobot-server nbshell` so long as you have `factory_boy` installed. Examples:
-
-```python
->>> from nautobot.tenancy.factory import TenantFactory, TenantGroupFactory
->>> # Create a single TenantGroup instance
->>> TenantGroupFactory.create()
-<TenantGroup: Peterson, Nunez and Miller>
->>> # Create 5 Tenant instances
->>> TenantFactory.create_batch(5)
-[<Tenant: Smith-Vance>, <Tenant: Sanchez, Brown and Davis>, <Tenant: Benson and Sons>, <Tenant: Pennington PLC>, <Tenant: Perez and Sons>]
->>> # Create 5 more Tenant instances all with a specified "group" value
->>> TenantFactory.create_batch(5, group=TenantGroup.objects.first())
-[<Tenant: Mercado, Wilson and Fuller>, <Tenant: Blackburn-Andrade>, <Tenant: Oliver-Ramirez>, <Tenant: Pugh-Clay>, <Tenant: Norman and Sons>]
-```
-
-!!! warning
-    `factory_boy` is only a *development* dependency of Nautobot. You cannot use the model factories in a production deployment of Nautobot unless you directly `pip install factory_boy` into such a deployment.
-
-Nautobot's custom [test runner](https://docs.djangoproject.com/en/3.2/topics/testing/advanced/#defining-a-test-runner) class (`nautobot.core.tests.runner.NautobotTestRunner`) makes use of the various factories to pre-populate the test database with data before running any tests. This reduces the need for individual tests to define their own baseline data sets.
-
-!!! info
-    Because plugins also commonly use Nautobot's test runner, the base Nautobot `settings.py` currently defaults [`TEST_USE_FACTORIES`](../../user-guide/administration/configuration/optional-settings.md#test_use_factories) to `False` so as to not negatively impact plugin tests that may not be designed to account for the presence of pre-populated test data in the database. This configuration is overridden to `True` in `nautobot/core/tests/nautobot_config.py` for Nautobot's own tests.
-
-### Factory Caching
-
-+++ 1.5.11
-
-To reduce the time taken between multiple test runs, a new argument has been added to the `nautobot-server test`, `invoke unittest` and `invoke integration-test` commands: `--cache-test-fixtures`. When running one of these commands with `--cache-test-fixtures` for the first time, after the factory data has been generated it will be saved to a `factory_dump.json` file in the `development` directory. On subsequent runs of unit or integration tests, the factory data will be loaded from the file instead of being generated again. This can significantly reduce the time taken to run tests. It's a good idea to let this file be regenerated after pulling new code from the repository, as the factory data may have changed.
-
-Factory caching is disabled by default. When using the `invoke` commands to run tests, caching can be enabled by default for your development environment by setting the `cache_test_fixtures` key to `True` in the `invoke.yml` file.
-
-## Performance Tests
-
-+++ 1.5.0
-
-### Running Performance Tests
-
-Nautobot uses [`django-slowtests`](https://pypi.org/project/django-slowtests/) to run performance tests. To run performance tests, you need to install the `django-slowtests` package.
-Once you install the package, you can do `invoke performance-test` or `invoke unittest --performance-test` to run unit tests with `NautobotPerformanceTestRunner`. The invoke commands will automatically add `--testrunner nautobot.core.tests.runner.NautobotPerformanceTestRunner` to the `coverage run` command and this flag will replace the default `NautobotTestRunner` while retaining all its functionalities with the addition of performance evaluation after test runs.
-
-`NautobotPerformanceTestRunner` which inherits from `DiscoverSlowestTestsRunner` will only be available when `django-slowtests` is installed. The runner measures the time to run unit tests against baselines stored in a designated .yml file (defaults to `nautobot/core/tests/performance_baselines.yml`) in addition to running the unit tests themselves.
-
-!!! warning
-    This functionality requires the installation of the [`django-slowtests`](https://pypi.org/project/django-slowtests/) Python package, which is present in Nautobot's own development environment, but is *not* an inherent dependency of the Nautobot package when installed otherwise, such as into a plugin's development environment.
-
-!!! info
-    `invoke performance-test` is enabled when `django-slowtests` is installed and when called, it will run and evaluate the performance of specific unit tests that are tagged with `performance` i.e. `@tag("performance")`. `invoke unittest --performance-report` and `invoke integration-test --performance-report` will also be enabled and when called, they will generate a performance report for all the tests ran in the terminal.
-    If performance baselines for tests are not available:
-
-```no-highlight
-175 abnormally slower tests:
-Performance baseline for test_account (nautobot.circuits.tests.test_filters.ProviderTestCase) is not available. Test took 0.0758s to run
-Performance baseline for test_asn (nautobot.circuits.tests.test_filters.ProviderTestCase) is not available. Test took 0.0427s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTerminationTest) is not available. Test took 0.2900s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTest) is not available. Test took 0.2292s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTypeTest) is not available. Test took 0.1596s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.ProviderNetworkTest) is not available. Test took 0.1897s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.ProviderTest) is not available. Test took 0.2092s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTerminationTest) is not available. Test took 0.1168s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTest) is not available. Test took 0.2762s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTypeTest) is not available. Test took 0.0663s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.ProviderNetworkTest) is not available. Test took 0.0875s to run
-...
-```
-
-!!! info
-    If performance baselines for tests are available and the time it take to run tests are siginificantly slower than baselines:
-
-```no-highlight
-12 abnormally slower tests:
-0.9838s test_bulk_import_objects_with_constrained_permission (nautobot.ipam.tests.test_views.VLANTestCase) is significantly slower than the baseline 0.3692s
-1.2548s test_create_multiple_objects_with_constrained_permission (nautobot.dcim.tests.test_views.ConsolePortTestCase) is significantly slower than the baseline 0.5385s
-1.4289s test_create_multiple_objects_with_constrained_permission (nautobot.dcim.tests.test_views.DeviceBayTestCase) is significantly slower than the baseline 0.5616s
-1.1551s test_create_multiple_objects_with_constrained_permission (nautobot.dcim.tests.test_views.InventoryItemTestCase) is significantly slower than the baseline 0.5822s
-1.4712s test_create_multiple_objects_with_constrained_permission (nautobot.dcim.tests.test_views.RearPortTestCase) is significantly slower than the baseline 0.5695s
-1.5958s test_create_multiple_objects_with_constrained_permission (nautobot.virtualization.tests.test_views.VMInterfaceTestCase) is significantly slower than the baseline 1.0020s
-1.0566s test_create_object_with_constrained_permission (nautobot.virtualization.tests.test_views.VirtualMachineTestCase) is significantly slower than the baseline 0.3627s
-...
-```
-
-!!! info
-    To output the performance evaluation to a file for later use, i.e. as performance baselines for future test runs, do `invoke performance-test --performance-snapshot`. This command will collect the `names` of the test and their `execution_time` and store them in a .yml file default to `report.yml`. Subsequently, the data in that file will have to be manually added to the baseline file set at [`TEST_PERFORMANCE_BASELINE_FILE`](../../user-guide/administration/configuration/optional-settings.md#test_performance_baseline_file) to be used as baselines in performance tests.
-
-Example output of `invoke performance-test --performance-snapshot`:
-
-```yaml
-- tests:
-  - name: test_account (nautobot.circuits.tests.test_filters.ProviderTestCase)
-    execution_time: 0.07075
-  - name: test_asn (nautobot.circuits.tests.test_filters.ProviderTestCase)
-    execution_time: 0.041262
-  - name: test_cabled (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-    execution_time: 0.268673
-  - name: test_cid (nautobot.circuits.tests.test_filters.CircuitTestCase)
-    execution_time: 0.116057
-  - name: test_circuit_id (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-    execution_time: 0.042665
-  - name: test_commit_rate (nautobot.circuits.tests.test_filters.CircuitTestCase)
-    execution_time: 0.047894
-  - name: test_connected (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-    execution_time: 0.056196
-  - name: test_id (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-    execution_time: 0.03598
-...
-```
-
-### Gathering Performance Test Baseline Data
-
-`TEST_PERFORMANCE_BASELINE_FILE` specifies the file in which performance baselines are stored, defaults to `nautobot/core/tests/performance_baselines.yml`. Currently, only baselines for those unit tests tagged with `performance` are stored.
-
-You can add baselines for your own test to `nautobot/core/tests/performance_baselines.yml` or have your own baseline yaml file for performance testing by specifying a different file path for  `TEST_PERFORMANCE_BASELINE_FILE` in plugin's development/test `nautobot_config.py`, and store the output of `invoke performance-test --performance-snapshot` in that file.
-`--performance-snapshot` flag will store the results of your performance test to a new `report.yml` and all you need to do is copy/paste the results to the file set by `TEST_PERFORMANCE_BASELINE_FILE`. Now you have baselines for your own tests!
-
-Example output of `invoke performance-test --performance-snapshot`:
-
-```yaml
-- tests:
-  - name: test_account (nautobot.circuits.tests.test_filters.ProviderTestCase)
-    execution_time: 0.07075
-  - name: test_asn (nautobot.circuits.tests.test_filters.ProviderTestCase)
-    execution_time: 0.041262
-  - name: test_cabled (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-    execution_time: 0.268673
-  - name: test_cid (nautobot.circuits.tests.test_filters.CircuitTestCase)
-    execution_time: 0.116057
-  - name: test_circuit_id (nautobot.circuits.tests.test_filters.CircuitTerminationTestCase)
-...
-```
-
-if you decide to run `invoke unittest --performance-test` which will run tests that currently do not have their baselines present in the file, your output could look something like this:
-
-```no-highlight
-175 abnormally slower tests:
-Performance baseline for test_account (nautobot.circuits.tests.test_filters.ProviderTestCase) is not available. Test took 0.0758s to run
-Performance baseline for test_asn (nautobot.circuits.tests.test_filters.ProviderTestCase) is not available. Test took 0.0427s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTerminationTest) is not available. Test took 0.2900s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTest) is not available. Test took 0.2292s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.CircuitTypeTest) is not available. Test took 0.1596s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.ProviderNetworkTest) is not available. Test took 0.1897s to run
-Performance baseline for test_bulk_create_objects (nautobot.circuits.tests.test_api.ProviderTest) is not available. Test took 0.2092s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTerminationTest) is not available. Test took 0.1168s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTest) is not available. Test took 0.2762s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.CircuitTypeTest) is not available. Test took 0.0663s to run
-Performance baseline for test_bulk_delete_objects (nautobot.circuits.tests.test_api.ProviderNetworkTest) is not available. Test took 0.0875s to run
-...
-```
-
-### Caveats
-
-!!! warning
-    `django-slowtests` is only a *development* dependency of Nautobot. You cannot run performance tests in a production deployment of Nautobot unless you directly `pip install django-slowtests` into such a deployment.
-
-!!! info
-    Because plugins also commonly use Nautobot's default test runner `NautobotTestRunner`, in order to use `NautobotPerformanceTestRunner` you need to add `django-slowtests` as a part of your plugin dev dependencies.
-
-## Test Code Style
-
-- Use more specific/feature-rich test assertion methods where available (e.g. `self.assertInHTML(fragment, html)` rather than `self.assertTrue(re.search(fragment, html))` or `assert re.search(fragment, html) is not None`).
-- Keep test case scope (especially in unit tests) small. Split test functions into smaller tests where possible; otherwise, use `self.subTest()` to delineate test blocks as appropriate.

nautobot/docs/development/core/user-preferences.md

@@ -1,11 +0,0 @@
-# User Preferences
-
-The `users.User` model holds individual preferences for each user in the form of JSON data in the `config_data` field. This page serves as a manifest of all recognized user preferences in Nautobot.
-
-## Available Preferences
-
-| Name | Description |
-| ---- | ----------- |
-| `extras.configcontext.format` | Preferred format when rendering config context data (JSON or YAML) |
-| `pagination.per_page` | The number of items to display per page of a paginated table |
-| `tables.TABLE_NAME.columns` | The ordered list of columns to display when viewing the table |

nautobot/docs/development/index.md

@@ -1 +0,0 @@
-# Developer Guide