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

nautobot/docs/development/apps/migration/from-v1.md

@@ -1,56 +0,0 @@
-# Migrating from 1.x to 2.0
-
-This document provides guidance on migrating code from version 1.x to version 2.0.0. It covers the major changes introduced in the new version and outlines the necessary modifications you need to make in your code to ensure compatibility.
-
-## Table of Contents
-
-- New to Nautobot v2.0.0
-    - [New UI](../../core/react-ui.md)
-    - [Enhanced Filter Fields](../../../release-notes/version-2.0.md#enhanced-filter-fields-2804)
-- Changes to Nautobot in v2.0.0
-    - [Database (ORM) Changes](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#database-orm-changes)
-        - [Database Field Behavior Changes](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#database-field-behavior-changes)
-        - [Renamed Database Fields](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#renamed-database-fields)
-        - [Removed Database Fields](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#removed-database-fields)
-    - [Generic Role Model](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#generic-role-model)
-    - [Collapse Site and Region into Location](../migration/model-updates/dcim.md#replace-site-and-region-with-location-model)
-    - [Aggregate model Migrated to Prefix](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#aggregate-migrated-to-prefix)
-    - [Renamed Database Foreign Keys and Related Names](../../../release-notes/version-2.0.md#renamed-database-foreign-keys-and-related-names-2520)
-    - [Renamed Filter Fields](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#renamed-filter-fields)
-    - [Corrected Filter Fields](../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#corrected-filter-fields)
-    - [Jobs](../../jobs/migration/from-v1.md)
-- Steps to Migrate an App from V1
-    - Preliminary Steps:
-        - Add [`pylint-nautobot`](https://github.com/nautobot/pylint-nautobot) as a development dependency
-        - Run `pylint -v --disable=all --enable=nautobot-code-location-changes,nautobot-replaced-models *` in order to parse your development environment for changes that need to be fixed before pylint-django can successfully run.
-        - Specific steps to install and run `pylint-nautobot` in your development environment is available [here](https://docs.nautobot.com/projects/pylint-nautobot/en/latest/getting_started/)
-    - [Dependency Updates](dependency-updates.md)
-        - [Nautobot Version](dependency-updates.md#nautobot-version)
-        - [Python Version](dependency-updates.md#python-version)
-        - [pylint-nautobot](dependency-updates.md#pylint-nautobot)
-    - [Code Updates](code-updates.md)
-        - [Update Code Import Locations](code-updates.md#update-code-import-locations)
-        - [Replace PluginMenuItem with NavMenuItem](code-updates.md#replace-pluginmenuitem-with-navmenuitem)
-        - [Remove Tag/Tags Filter Field from FilterSet Definitions](code-updates.md#remove-tagtags-filter-from-filterset-definitions)
-        - [Replace DjangoFilterBackend with NautobotFilterBackend](code-updates.md#replace-djangofilterbackend-with-nautobotfilterbackend)
-        - [App Model Serializer Inheritance](code-updates.md#app-model-serializer-inheritance)
-        - [Revamp Rest API Serializers](code-updates.md#revamp-rest-api-serializers)
-        - [Revamp CSV Import and Export](code-updates.md#revamp-csv-import-and-export)
-    - Model Updates
-        - [Global](model-updates/global.md)
-            - [Replace the Usage of Slugs](model-updates/global.md#replace-the-usage-of-slugs-with-composite-keys)
-        - [DCIM](model-updates/dcim.md)
-            - [Replace Site and Region with Location Model](model-updates/dcim.md#replace-site-and-region-with-location-model)
-        - [Extras](model-updates/extras.md)
-            - [Replace Role Related Models with Generic Role Model](model-updates/extras.md#replace-role-related-models-with-generic-role-model)
-            - [Update Job and Job related models](model-updates/extras.md#update-job-and-job-related-models)
-                - [Job Model Changes](model-updates/extras.md#job-model-changes)
-                - [Job Logging Changes](model-updates/extras.md#job-logging-changes)
-                - [JobResult Model Changes](model-updates/extras.md#jobresult-model-changes)
-            - [Update CustomField, ComputedField, and Relationship](model-updates/extras.md#update-customfield-computedfield-and-relationship)
-        - [IPAM](model-updates/ipam.md)
-            - [Replace Aggregate with Prefix](model-updates/ipam.md#replace-aggregate-with-prefix)
-            - [Introduction of Namespace](model-updates/ipam.md#introduction-of-namespace)
-            - [Concrete Relationship between Prefix and IP Address](model-updates/ipam.md#concrete-relationship-between-prefix-and-ip-address)
-            - [Concrete Relationship between Prefix and Self](model-updates/ipam.md#concrete-relationship-between-prefix-and-self)
-            - [Convert Relationship Type between Prefix and VRF to Many to Many](model-updates/ipam.md#convert-relationship-type-between-prefix-and-vrf-to-many-to-many)

nautobot/docs/development/apps/migration/model-updates/dcim.md

@@ -1,285 +0,0 @@
-# DCIM
-
-## Replace Site and Region with Location Model
-
-In Nautobot 2.0.0, all the `Region` and `Site` related data models are being migrated to use `Location`. Below is a comprehensive guide for Nautobot App developers to migrate their `Region` and `Site` related data models to `Location`.
-
-We will be using `ExampleModel` as a relatively simple and hands-on example throughout this guide to better your understanding of the migration process.
-
-### Before you Begin
-
-!!! warning
-    You **must** perform these steps before proceeding. Failing to follow them properly could result in data loss. **Always** backup your database before performing any migration steps.  
-Before you follow the guide, please make sure that these operations are completed:  
-
-1. Make sure your working Nautobot is on Version 1.5.x with baseline migrations all run.  
-2. Stop Nautobot Server.  
-3. Create a [backup](../../../../user-guide/administration/upgrading/database-backup.md) of your Nautobot database.
-4. Update installed version of Nautobot to 2.0.0.  
-5. Run `nautobot-server migrate dcim 0034_migrate_region_and_site_data_to_locations`. (This operation will ensure that `("dcim", "0034_migrate_region_and_site_data_to_locations")` is the latest migration applied to your Nautobot instance and that `("dcim", "0034_remove_region_and_site")` is **not** applied. **Failure to complete this step will result in data loss**)  
-
-After you complete those operations, follow the guide below for each of your installed apps to:  
-
-1. Make all necessary migration files for each app.  
-2. Run `nautobot-server migrate [app_name]` to apply those migration files to each app.  
-3. Finally, Start Nautobot Server after **all** the migration files are applied and **all** your affected apps are updated.  
-
-### Add Location Fields to Site and Region Related Data Models
-
-If the `ExampleModel` currently has a `site` ForeignKey field but it does not have a `location` ForeignKey field, you will need to add the `location` field before any other migrations in this guide.
-
-!!! note
-    You can skip this step only if your data models already have both a `site` (or `region`) field and a `location` field.
-
-```python
-# models.py
-
-class ExampleModel(OrganizationalModel):
-    site = models.ForeignKey(
-        to="dcim.Site",
-        on_delete=models.PROTECT,
-        blank=True,
-        null=True,
-    )
-    name = models.CharField(max_length=20, help_text="The name of this Example.")
-...
-```
-
-**DO NOT** delete the `site` ForeignKey field yet. As a first step, just add a `ForeignKey` to `dcim.Location` with all other arguments identical to the existing `dcim.Site` `ForeignKey`:
-
-```python
-# models.py
-
-class ExampleModel(OrganizationalModel):
-    site = models.ForeignKey(
-        to="dcim.Site",
-        on_delete=models.PROTECT,
-        blank=True,
-        null=True,
-    )
-    location = models.ForeignKey(
-        to="dcim.Location",
-        on_delete=models.PROTECT,
-        blank=True,
-        null=True,
-    )
-    name = models.CharField(max_length=20, help_text="The name of this Example.")
-...
-```
-
-Make the migration file by running `nautobot-server makemigrations [app_name] -n [migration_name]`, for example:
-
-```shell
-nautobot-server makemigrations example_app -n add_location_field_to_example_model
-```
-
-### Create an Empty Migration File and Write the Data Migration
-
-After you make sure that all `Site`/`Region` related models have `location` fields on them, it is time to migrate `Site`/`Region` references in your data to `Location`.
-
-Django doesn't automatically know how to do this; we have to create an empty migration file and write the migration script ourselves. This is also known as a [data migration](https://docs.djangoproject.com/en/3.2/topics/migrations/#data-migrations).
-
-Create a migration file first by running `nautobot-server makemigrations [app_name] -n [migration_file_name] --empty`, for example:
-
-```shell
-nautobot-server makemigrations example_app -n migrate_app_data_from_site_to_location --empty
-```
-
-The empty migration file will look like this with the only dependency being our previous migration that added a `location` ForeignKey field to our `ExampleModel`:
-
-```python
-# Generated by Django 3.2.17 on 2023-02-22 15:38
-# 0008_migrate_example_model_data_from_site_to_location
-
-from django.db import migrations
-
-class Migration(migrations.Migration):
-    dependencies = [
-        ("example_app", "0007_add_location_field_to_example_model"),
-    ]
-    operations = []
-```
-
-!!! warning
-    First we need to add a mandatory dependency to a Nautobot 2.0 migration file, namely `("dcim", "0034_migrate_region_and_site_data_to_locations")`. This dependent migration is very important as it creates the `Location` and `LocationType` records corresponding to the existing `Site`/`Region` records, which you will need to reference to migrate your data.
-    **Without it, your data migration might not work!**
-
-```python
-    dependencies = [
-        # The dcim migration creates the Site Type and Region Type Locations that
-        # your data models are migrating to. It has to be run **before** this migration.
-        ("dcim", "0034_migrate_region_and_site_data_to_locations"),
-        ("example_app", "0007_add_location_field_to_example_model"),
-    ]
-```
-
-Before we write the function that will perform the data migration, please note that Nautobot's `dcim` `0029` migration helpfully added and populated a Foreign Key called `migrated_location` on all `Region` and `Site` records. `migrated_location` stores the new location records that have the same names and other attributes as their respective `Sites`. That means all you need to do is query `ExampleModel` instances that have non-null `site` fields and null `location` fields and point the `location` field on your object to the site's `migrated_location` attribute, for example:
-
-```python
-example_model.location = example_model.site.migrated_location
-```
-
-Below is what the function might look like:
-
-```python
-def migrate_example_model_data_to_locations(apps, schema_editor):
-    # Always use the provided `apps` to look up models
-    # rather than importing them directly!
-    ExampleModel = apps.get_model("example_app", "examplemodel")
-    LocationType = apps.get_model("dcim", "locationtype")
-    Location = apps.get_model("dcim", "location")
-
-    # Query ExampleModel instances with non-null site field
-    example_models = ExampleModel.objects.filter(
-        site__isnull=False, location__isnull=True
-    ).select_related("site", "location")
-    for example_model in example_models:
-        # Point the location field to the corresponding
-        # "Site" LocationType Location stored in migrate_location
-        example_model.location = example_model.site.migrated_location
-    ExampleModel.objects.bulk_update(example_models, ["location"], 1000)
-```
-
-Finally, we need to add `migrations.RunPython` to the `operations` attribute in the migration class to execute this function when the migration is applied:
-
-```python
-    operations = [
-        migrations.RunPython(
-            # Execute the function
-            code=migrate_example_model_data_to_locations,
-            reverse_code=migrations.operations.special.RunPython.noop,
-        )
-    ]
-
-```
-
-The final migration file might look like this:
-
-```python
-# Generated by Django 3.2.17 on 2023-02-22 15:38
-# 0008_migrate_example_model_data_from_site_to_location
-
-from django.db import migrations
-
-def migrate_example_model_data_to_locations(apps, schema_editor):
-
-    ExampleModel = apps.get_model("example_app", "examplemodel")
-    LocationType = apps.get_model("dcim", "locationtype")
-    Location = apps.get_model("dcim", "location")
-    # Get "Site" LocationType
-    site_location_type = LocationType.objects.get(name="Site")
-
-    # Query ExampleModel instances with non-null site field
-    example_models = ExampleModel.objects.filter(
-        site__isnull=False, location__isnull=True
-    ).select_related("site", "location")
-    for example_model in example_models:
-        # Point the location field to the corresponding "Site" LocationType Location
-        # with the same name.
-        example_model.location = example_model.site.migrated_location
-    ExampleModel.objects.bulk_update(example_models, ["location"], 1000)
-
-class Migration(migrations.Migration):
-    dependencies = [
-        # The dcim migration creates the Site Type and Region Type Locations that
-        # your data models are migrating to.
-        # Therefore, It has to be run **before** this migration.
-        ("dcim", "0034_migrate_region_and_site_data_to_locations"),
-        ("example_app", "0007_add_location_field_to_example_model"),
-    ]
-    operations = [
-        migrations.RunPython(
-            # Execute the function
-            code=migrate_example_model_data_to_locations,
-            reverse_code=migrations.operations.special.RunPython.noop,
-        )
-    ]
-```
-
-### Remove Site/Region Related Fields from Migrated Data Models
-
-After the data migration is successful, we need to remove the `site`/`region` fields from your data model so that Nautobot will be able to remove the `Site` and `Region` models. Note that we need to remove those attributes in a separate migration file from the previous one, as it's never a good practice to combine data migrations and schema migrations in the same file. You can do this by simply removing the `site`/`region` attributes from your model class:
-
-```python
-# models.py
-class ExampleModel(OrganizationalModel):
-    # note that site field is gone
-    location = models.ForeignKey(
-        to="dcim.Location",
-        on_delete=models.PROTECT,
-        blank=True,
-        null=True,
-    )
-    name = models.CharField(max_length=20, help_text="The name of this Example.")
-...
-```
-
-After removing the `site` attribute, make the migration file by running `nautobot-server makemigrations [app_name] -n [migration_name]`, for example:
-
-```shell
-nautobot-server makemigrations example_app -n remove_site_field_from_example_model
-```
-
-The migration file might look like this:
-
-```python
-# Generated by Django 3.2.17 on 2023-02-22 17:09
-# 0009_remove_site_field_from_example_model.py
-
-from django.db import migrations
-
-class Migration(migrations.Migration):
-
-    dependencies = [
-        ('example_app', '0008_migrate_example_model_data_from_site_to_location'),
-    ]
-
-    operations = [
-        migrations.RemoveField(
-            model_name='examplemodel',
-            name='site',
-        ),
-    ]
-```
-
-!!! important
-    Before you apply this migration, you have to add a `run_before` attribute in this migration file to make sure that you remove `site`/`region` fields before `Site` and `Region` models themselves are removed. **Without it, your migration files might be out of order and your app will not start**.
-
-```python
-    # Ensure this migration is run before the migration that removes Region and Site Models
-    run_before = [
-        ("dcim", "0040_remove_region_and_site"),
-    ]
-```
-
-The final migration file might look like this:
-
-```python
-# Generated by Django 3.2.17 on 2023-02-22 17:09
-# 0009_remove_site_field_from_example_model.py
-
-from django.db import migrations
-
-class Migration(migrations.Migration):
-    
-    # Ensure this migration is run before the migration that removes Region and Site Models
-    run_before = [
-        ("dcim", "0040_remove_region_and_site"),
-    ]
-    dependencies = [
-        ("example_app", "0008_migrate_example_model_data_from_site_to_location"),
-    ]
-
-    operations = [
-        migrations.RemoveField(
-            model_name="examplemodel",
-            name="site",
-        ),
-    ]
-```
-
-Apply the migration files by running `nautobot-server migrate [app_name]`, for example:
-
-```shell
-nautobot-server migrate example_app
-```

nautobot/docs/development/apps/migration/model-updates/extras.md

@@ -1,30 +0,0 @@
-# Extras
-
-## Replace Role Related Models with Generic Role Model
-
-1. Narrowly defined role models including `dcim.DeviceRole`, `dcim.RackRole` and `ipam.Role` are replaced by a generic `extras.Role` model.
-2. If any of your models are using the replaced role models, it is required for you to remove the `role` field from your model and add either `nautobot.extras.models.roles.RoleModelMixin` or `nautobot.extras.models.roles.RoleRequiredRoleModelMixin` to your model class definition. `RoleModelMixin` adds a nullable `role` field whereas `RoleRequiredRoleModelMixin` adds a required `role` field.
-3. Please go [here](../../../core/role-internals.md) to check out how the `extras.Role` model works in v2.0.
-
-## Updates to Job and Job related models
-
-### Job Model Changes
-
-See details about the fundamental changes to `Job` Model [here](../../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#job-database-model-changes)
-
-### Job Logging Changes
-
-1. Job logging is now handled by a logger off the Job itself and has a function for each level to send the message (info, warning, debug, etc).
-2. `JobResult.log` no longer accepts a `logger` arg and app/job authors should transition to using the Job's logger methods instead of directly calling `JobResult.log`.
-3. There is no longer a `log_success` or `log_failure` function. Checkout the changes in detail [here](../../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#logging-changes)
-
-### JobResult Model Changes
-
-`JobResult` no longer needs a `job_id`, `user`, or `obj_type` passed to it. It now needs a `name`, `task_name`, and a `worker`. See [here](../../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#jobresult-database-model-changes) for details.
-
-## Update CustomField, ComputedField, and Relationship
-
-1. In accordance with the removal of `slug` field in Nautobot v2.0, `CustomField`, `ComputeField` and `Relationship`'s `slug` field is replaced by the `key` field which contains a GraphQL-safe string that is used exclusively in the API and GraphQL.
-2. Removed `name` field from `CustomField` model and renamed `name` field to `label` on `Relationship` model.
-3. Their `label` fields are now used for display purposes only in the UI.
-4. Please go to their respective documentations for more information [CustomField](../../../../user-guide/feature-guides/custom-fields.md), [ComputedField](../../../../user-guide/platform-functionality/computedfield.md), and [Relationship](../../../../user-guide/feature-guides/relationships.md).

nautobot/docs/development/apps/migration/model-updates/global.md

@@ -1,5 +0,0 @@
-# Global
-
-## Replace the Usage of Slugs
-
-Slugs were used to identify unique objects in the database for various models in Nautobot v1.x and they are now replaced by Natural Keys. The `slug` field can be safely deleted as long as your models are derived from `BaseModel` that automatically supports the following [natural key](https://docs.djangoproject.com/en/3.2/topics/serialization#natural-keys) APIs. For a more comprehensive guideline on how Natural Keys in Nautobot v2.0 work, please go to the [Natural Key documentation](../../../core/natural-keys.md).

nautobot/docs/development/apps/migration/model-updates/ipam.md

@@ -1,22 +0,0 @@
-# IPAM
-
-## Replace Aggregate with Prefix
-
-`Aggregate` models are removed in v2.0 and all existing `Aggregate` instances are migrated to `Prefix` with type set to "Container". So your models and data that are associated with `Aggregate` via ForeignKey or ManyToMany relationships are now required to be migrated to `Prefix`. Please go [here](../../../../user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.md#aggregate-migrated-to-prefix) for this change and its potential impact on other models.
-
-## Introduction of Namespace
-
-A Namespace groups together a set of related but distinct [VRFs](../../../../user-guide/core-data-model/ipam/vrf.md), [Prefixes](../../../../user-guide/core-data-model/ipam/prefix.md), and [IP addresses](../../../../user-guide/core-data-model/ipam/ipaddress.md). Within a given Namespace, only a single record may exist for each distinct VRF, Prefix, or IP address. Although such a record may be used in multiple locations within your network, such as a VRF being configured on multiple Devices, or a virtual IP address being assigned to multiple Interfaces or Devices, it is fundamentally a single network object in these cases, and Nautobot models this data accordingly. Check out the model documentation [here](../../../../user-guide/core-data-model/ipam/namespace.md)
-
-## Concrete Relationship between Prefix and IP Address
-
-[IP addresses](../../../../user-guide/core-data-model/ipam/ipaddress.md) now have a concrete relationship with its parent [Prefix](../../../../user-guide/core-data-model/ipam/prefix.md). `IPAddress.parent` now refers to the parent prefix and `Prefix.ip_addresses` refers to the child ips.`
-
-## Concrete Relationship between Prefix and Self
-
-Each [Prefix](../../../../user-guide/core-data-model/ipam/prefix.md) now has a concrete parent/child relationship with related Prefixes. `Prefix.parent` refers to its parent prefix and `Prefix.children` refers to all its child Prefixes.
-
-## Convert Relationship Type between Prefix and VRF to Many to Many
-
-[Prefixes](../../../../user-guide/core-data-model/ipam/prefix.md) now no longer have a ForeignKey to [VRF](../../../../user-guide/core-data-model/ipam/vrf.md). Instead, the Many to Many relationship is now defined on the VRF side as `VRF.prefixes`. VRF is also no longer a uniqueness constraint on the Prefix. Namespace is used instead.
-Additionally, VRF is no longer assigned directly to an IPAddress but is now derived from any association to the parent Prefix.

nautobot/docs/development/apps/porting-from-netbox.md

@@ -1,23 +0,0 @@
-# Porting NetBox Plugins to Nautobot
-
-Given an existing NetBox plugin, it will range from straightforward to very complicated to create a port of this plugin that's compatible with Nautobot, though in general it should be easier than developing a comparable plugin entirely from scratch. Of course, it would be impossible to provide a generalized, step-by-step guide that would cover all possibilities, but this document at least documents some known tips and tricks for this purpose.
-
-## Updating Python module import paths
-
-The most likely first issue you will encounter will be a module import problem, and in most cases a simple change to the name of imported modules will suffice:
-
-- `circuits.* -> nautobot.circuits.*`
-- `dcim.* -> nautobot.dcim.*`
-- `extras.* -> nautobot.extras.*`
-- `ipam.* -> nautobot.ipam.*`
-- `netbox.* -> nautobot.core.*`
-- `tenancy.* -> nautobot.tenancy.*`
-- `utilities.* -> nautobot.core.*`
-- `virtualization.* -> nautobot.virtualization.*`
-
-+/- 2.0.0
-    The equivalent of NetBox's `utilities` module moved from `nautobot.utilities` to `nautobot.core`.
-
-## Regenerating database migrations
-
-In general, your migrations files will not port over easily; you will probably want to delete and re-generate them (`nautobot-server makemigrations <plugin-name>`) instead.

nautobot/docs/development/core/application-registry.md

@@ -1,216 +0,0 @@
-# Application Registry
-
-The registry is an in-memory data structure which houses various application-wide parameters, such as the list of enabled plugins. It is not exposed to the user and is not intended to be modified by any code outside of Nautobot core.
-
-The registry behaves essentially like a Python dictionary, with the notable exception that once a store (key) has been declared, it cannot be deleted or overwritten. The value of a store can, however, be modified; e.g. by appending a value to a list. Store values generally do not change once the application has been initialized.
-
-The registry can be inspected by importing `registry` from `nautobot.extras.registry`. Page templates that need access to the registry can use the `registry` template tag to load it into the template context, for example:
-
-```django
-<!-- Load the "registry" template tag library -->
-{% load registry %}
-<!-- Load the registry into the template context as variable "registry"-->
-{% registry %}
-<!-- Use the registry variable in the template -->
-{{ registry.datasource_contents }}
-```
-
-## Stores
-
-### `datasource_contents`
-
-Definition of data types that can be provided by data source models (such as [Git repositories](../../user-guide/platform-functionality/gitrepository.md)). Implemented as a dictionary mapping the data source model name to a list of the types of data that it may contain and callback functions associated with those data types. The default mapping in Nautobot is currently:
-
-```python
-{
-    "extras.gitrepository": [
-        DatasourceContent(
-            name='config contexts',
-            content_identifier='extras.configcontext',
-            icon='mdi-code-json',
-            callback=extras.datasources.git.refresh_git_config_contexts,
-        ),
-        DatasourceContent(
-            name='jobs',
-            content_identifier='extras.job',
-            icon='mdi-script-text',
-            callback=extras.datasources.git.refresh_git_jobs,
-        ),
-        DatasourceContent(
-            name='export templates',
-            content_identifier='extras.exporttemplate',
-            icon='mdi-database-export',
-            callback=extras.datasources.git.refresh_git_export_templates,
-        ),
-    ]
-}
-```
-
-Plugins may extend this dictionary with additional data sources and/or data types by calling `extras.registry.register_datasource_contents()` as desired.
-
-### `homepage_layout`
-
-+++ 1.2.0
-
-A dictionary holding information about the layout of Nautobot's homepage. Each app may register homepage panels and items using objects from the generic app class. Each object has a weight attribute allowing the developer to define the position of the object.
-
-``` python
-{
-    "panels": {
-        "Panel 1" {
-            "weight": 100,
-            "items": {
-                "Item 1": {
-                    "description": "This is item 1",
-                    "link": "example.link_1"
-                    "model": Example,
-                    "permissions": "example.view_link_1",
-                    "weight": 100,
-                },
-                "Item 2": {
-                    "description": "This is item 2",
-                    "link": "example.link_2"
-                    "model": Example,
-                    "permissions": "example.view_link_2",
-                    "weight": 200,
-                }
-            }
-        }
-        "Panel 2": {
-            "weight": 200,
-            "custom_template": "panel_example.html",
-            "custom_data": {
-                "example": example_callback_function,
-            },
-        }
-    }
-}
-```
-
-### `model_features`
-
-A dictionary of particular features (e.g. custom fields) mapped to the Nautobot models which support them, arranged by app. For example:
-
-```python
-{
-    'custom_fields': {
-        'circuits': ['provider', 'circuit'],
-        'dcim': ['location', 'rack', 'devicetype', ...],
-        ...
-    },
-    'webhooks': {
-        ...
-    },
-    ...
-}
-```
-
-For more information visit [model-features](model-features.md).
-
-### `nav_menu`
-
-+++ 1.1.0
-
-Navigation menu items provided by Nautobot applications. Each app may register its navbar configuration inside of the `nav_menu` dictionary using `navigation.py`. Tabs are stored in the top level moving down to groups, items and buttons. Tabs, groups and items can be modified by using the key values inside other application and plugins. The `nav_menu` dict should never be modified directly.
-
-Example:
-
-```python
-{
-    "tabs": {
-        "tab_1": {
-            "weight": 100,
-            "permissions": [],
-            "groups": {
-                "group_1":{
-                    "weight": 100,
-                    "permissions": [],
-                    "items": {
-                        "item_link_1": {
-                            "link_text": "Item 1",
-                            "weight": 100,
-                            "permissions": [],
-                            "buttons": {
-                                "button_1": {
-                                    "button_class": "success",
-                                    "icon_class": "mdi-plus-thick",
-                                    "link": "button_link_1",
-                                    "weight": 100,
-                                    "permissions": [],
-                                },
-                                "button_2": {
-                                    "button_class": "success",
-                                    "icon_class": "mdi-plus-thick",
-                                    "link": "button_link_2",
-                                    "weight": 200,
-                                    "permissions": [],
-                                }
-                            }
-                        },
-                        "item_link_2": {
-                            "link_text": "Item 2",
-                            "weight": 200,
-                            "permissions": [],
-                            "buttons": {
-                                "button_1": {
-                                    "button_class": "success",
-                                    "icon_class": "mdi-plus-thick",
-                                    "link": "button_link_1",
-                                    "weight": 100,
-                                    "permissions": [],
-                                },
-                                "button_2": {
-                                    "button_class": "success",
-                                    "icon_class": "mdi-plus-thick",
-                                    "link": "button_link_2",
-                                    "weight": 200,
-                                    "permissions": [],
-                                }
-                            }
-                        },
-                    }
-                }
-            }
-        }
-    }
-}
-```
-
-### `plugin_custom_validators`
-
-Plugin [custom validator classes](../apps/api/platform-features/custom-validators.md) that provide additional data model validation logic. Implemented as a dictionary mapping data model names to a list of `CustomValidator` subclasses, for example:
-
-```python
-{
-    'circuits.circuit': [CircuitMustHaveDescriptionValidator],
-    'dcim.location': [LocationMustHaveTenantValidator, LocationNameMustIncludeCountryCodeValidator],
-}
-```
-
-### `plugin_graphql_types`
-
-List of GraphQL Type objects that will be added to the GraphQL schema. GraphQL objects that are defined in a plugin will be automatically registered into this registry. An example:
-
-```python
-[
-    <DjangoObjectType>, <DjangoObjectType>, <OptimizedDjangoObjectType>
-]
-```
-
---- 2.0.0
-    The `plugin_jobs` registry has been replaced by [`nautobot.core.celery.register_jobs`](../../user-guide/platform-functionality/jobs/index.md#writing-jobs) which should be called at import time by any plugin that provides jobs.
-
-### `plugin_template_extensions`
-
-Plugin content that gets embedded into core Nautobot templates. The store comprises Nautobot models registered as dictionary keys, each pointing to a list of applicable template extension classes that exist. An example:
-
-```python
-{
-    'dcim.location': [
-        <TemplateExtension>, <TemplateExtension>, <TemplateExtension>,
-    ],
-    'dcim.rack': [
-        <TemplateExtension>, <TemplateExtension>,
-    ],
-}
-```