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

nautobot/docs/development/apps/api/models/index.md

@@ -1,81 +0,0 @@
-# Adding Database Models
-
-If your app introduces a new type of object in Nautobot, you'll probably want to create a [Django model](https://docs.djangoproject.com/en/stable/topics/db/core-data-model/) for it. A model is essentially a Python representation of a database table, with attributes that represent individual columns. Model instances can be created, manipulated, and deleted using [queries](https://docs.djangoproject.com/en/stable/topics/db/queries/). Models must be defined within a file named `models.py`.
-
-It is highly recommended to have app models inherit from at least `nautobot.apps.models.BaseModel` which provides base functionality and convenience methods common to all models.
-
-For more advanced usage, you may want to instead inherit from one of Nautobot's "generic" models derived from `BaseModel` -- `nautobot.apps.models.OrganizationalModel` or `nautobot.apps.models.PrimaryModel`. The inherent capabilities provided by inheriting from these various parent models differ as follows:
-
-| Feature | `django.db.models.Model` | `BaseModel` | `OrganizationalModel` | `PrimaryModel` |
-| ------- | --------------------- | ----------- | --------------------- | -------------- |
-| UUID primary key | ❌ | ✅ | ✅ | ✅ |
-| [Natural keys](../../../core/natural-keys.md) | ❌ | ✅ | ✅ | ✅ |
-| [Object permissions](../../../../user-guide/administration/guides/permissions.md) | ❌ | ✅ | ✅ | ✅ |
-| [`validated_save()`](../../../core/best-practices.md#model-validation) | ❌ | ✅ | ✅ | ✅ |
-| [Change logging](../../../../user-guide/platform-functionality/change-logging.md) | ❌ | ❌ | ✅ | ✅ |
-| [Custom fields](../../../../user-guide/platform-functionality/customfield.md) | ❌ | ❌ | ✅ | ✅ |
-| [Relationships](../../../../user-guide/platform-functionality/relationship.md) | ❌ | ❌ | ✅ | ✅ |
-| [Note](../../../../user-guide/platform-functionality/note.md) | ❌ | ❌ | ✅ | ✅ |
-| [Tags](../../../../user-guide/platform-functionality/tag.md) | ❌ | ❌ | ❌ | ✅ |
-
-Below is an example `models.py` file containing a basic model with two character fields:
-
-```python
-# models.py
-from django.db import models
-
-from nautobot.apps.models import BaseModel
-
-
-class Animal(BaseModel):
-    """Base model for animals."""
-
-    name = models.CharField(max_length=50)
-    sound = models.CharField(max_length=50)
-
-    def __str__(self):
-        return self.name
-
-    class Meta:
-        unique_together = [["name", "sound"]]
-```
-
-Once you have defined the model(s) for your app, you'll need to create the database schema migrations. A migration file is essentially a set of instructions for manipulating the database to support your new model, or to alter existing models.
-
-Creating migrations can be done automatically using the `nautobot-server makemigrations <app_name>` management command, where `<app_name>` is the name of the Python package for your app (e.g. `nautobot_animal_sounds`):
-
-```no-highlight
-nautobot-server makemigrations nautobot_animal_sounds
-```
-
-!!! note
-    An app must be installed before it can be used with Django management commands. If you skipped this step above, run `poetry install` from the app's root directory.
-
-```no-highlight
-nautobot-server makemigrations nautobot_animal_sounds
-```
-
-Example output:
-
-```no-highlight
-Migrations for 'nautobot_animal_sounds':
-  /home/bjones/animal_sounds/nautobot_animal_sounds/migrations/0001_initial.py
-    - Create model Animal
-```
-
-Next, apply the migration to the database with the `nautobot-server migrate <app_name>` command:
-
-```no-highlight
-nautobot-server migrate nautobot_animal_sounds
-```
-
-Example output:
-
-```no-highlight
-Operations to perform:
-  Apply all migrations: nautobot_animal_sounds
-Running migrations:
-  Applying nautobot_animal_sounds.0001_initial... OK
-```
-
-For more background on schema migrations, see the [Django documentation](https://docs.djangoproject.com/en/stable/topics/migrations/).

nautobot/docs/development/apps/api/nautobot-app-config.md

@@ -1,84 +0,0 @@
-# NautobotAppConfig
-
-The `NautobotAppConfig` class is a Nautobot-specific wrapper around Django's built-in [`AppConfig`](https://docs.djangoproject.com/en/stable/ref/applications/) class. It is used to declare Nautobot app functionality within a Python package. Each app should provide its own subclass, defining its name, metadata, and default and required configuration parameters. An example is below:
-
-```python
-from nautobot.apps import NautobotAppConfig
-
-class AnimalSoundsConfig(NautobotAppConfig):
-    name = 'nautobot_animal_sounds'
-    verbose_name = 'Animal Sounds'
-    description = 'An example app for development purposes'
-    version = '0.1'
-    author = 'Bob Jones'
-    author_email = 'bob@example.com'
-    base_url = 'animal-sounds'
-    required_settings = []
-    default_settings = {
-        'loud': False
-    }
-
-config = AnimalSoundsConfig
-```
-
-Nautobot looks for the `config` variable within an app's `__init__.py` to load its configuration. Typically, this will be set to the `NautobotAppConfig` subclass, but you may wish to dynamically generate a `NautobotAppConfig` class based on environment variables or other factors.
-
-## Required NautobotAppConfig Attributes
-
-| Name | Description |
-| ---- | ----------- |
-| `author` | Name of app's author |
-| `author_email` | Author's public email address |
-| `description` | Brief description of the app's purpose |
-| `name` | Raw app name; same as the app's source directory |
-| `verbose_name` | Human-friendly name for the app |
-| `version` | Current release ([semantic versioning](https://semver.org/) is encouraged) |
-
-## Optional NautobotAppConfig Attributes
-
-| Name | Default | Description |
-| ---- | ------- | ----------- |
-| `base_url` | Same as specified `name` | Base path to use for app URLs |
-| `config_view_name` | `None` | [URL name](configuration-view.md) for a "configuration" view defined by this app |
-| `default_settings` | `{}` | A dictionary of configuration parameters and their default values |
-| `home_view_name` | `None` | [URL name](configuration-view.md) for a "home" or "dashboard" view defined by this app |
-| `docs_view_name` | `None` | [URL name](configuration-view.md) for a "documentation" view defined by this app |
-| `installed_apps` | `[]` | A list of additional Django application dependencies to automatically enable when the app is activated (you must still make sure these underlying dependent libraries are installed) |
-| `max_version` | `None` | Maximum version of Nautobot with which the app is compatible |
-| `middleware` | `[]` | A list of middleware classes to append after Nautobot's built-in middleware |
-| `min_version` | `None` | Minimum version of Nautobot with which the app is compatible |
-| `required_settings` | `[]` | A list of any configuration parameters that **must** be defined by the user |
-| `searchable_models` | `[]` | A list of model names to include in the global Nautobot search |
-| `constance_config` | `{}` | [Django Constance](database-backend-config.md) configuration parameters for settings. |
-
-+++ 2.0.0
-    Support for the `searchable_models` and `constance_config` attributes were added.
-
---- 2.0.0
-    Support for `caching_config` was removed with the removal of `django-cacheops`.
-
-!!! note
-    All `required_settings` must be configured in `PLUGINS_CONFIG` in `nautobot_config.py` before the app can be used.
-
-!!! warning
-    If a configuration parameter is listed in either of `required_settings` or `constance_config`, and also in `default_settings`, the default setting will be ignored.
-
-## NautobotAppConfig Code Location Attributes
-
-The following `NautobotAppConfig` attributes can be configured to customize where Nautobot will look to locate various pieces of app code. In most cases you will not need to change these, but they are provided as options in case your app has a non-standard organizational structure.
-
-!!! info
-    As used below, a "dotted path" is the combination of a Python module path within the app and the name of a variable within that module. For example, `"template_content.template_extensions"` refers to a variable named `template_extensions` inside a `template_content` module located at the root of the app.
-
-| Name | Default | Description |
-| ---- | ------- | ----------- |
-| `banner_function` | `"banner.banner"` | Dotted path to a function that can render a custom [banner](ui-extensions/banners.md) |
-| `custom_validators` | `"custom_validators.custom_validators"` | Dotted path to a list of [custom validator classes](platform-features/custom-validators.md) |
-| `datasource_contents` | `"datasources.datasource_contents"` | Dotted path to a list of [datasource (Git, etc.) content types](platform-features/git-repository-content.md) to register |
-| `graphql_types` | `graphql.types.graphql_types` | Dotted path to a list of [GraphQL type classes](models/graphql.md#creating-your-own-graphql-type-object) |
-| `homepage_layout` | `"homepage.layout"` | Dotted path to a list of [home page items](ui-extensions/home-page.md) provided by the app |
-| `jinja_filters` | `"jinja_filters"` | Path to a module that contains [Jinja2 filters](platform-features/jinja2-filters.md) to be registered |
-| `jobs` | `"jobs.jobs"` | Dotted path to a list of [Job classes](platform-features/jobs.md) |
-| `menu_items` | `"navigation.menu_items"` | Dotted path to a list of [navigation menu items](ui-extensions/navigation.md) provided by the app |
-| `secrets_providers` | `"secrets.secrets_providers"` | Dotted path to a list of [secrets providers](platform-features/secrets-providers.md) in the app |
-| `template_extensions` | `"template_content.template_extensions"` | Dotted path to a list of [template extension classes](ui-extensions/object-detail-views.md) |

nautobot/docs/development/apps/api/platform-features/custom-validators.md

@@ -1,30 +0,0 @@
-# Implementing Custom Validators
-
-Apps can register custom validator classes which implement model validation logic to be executed during a model's `clean()` method. Like template extensions, custom validators are registered to a single model and offer a method which app authors override to implement their validation logic. This is accomplished by subclassing `CustomValidator` and implementing the `clean()` method.
-
-App authors must raise `django.core.exceptions.ValidationError` within the `clean()` method to trigger validation error messages which are propagated to the user and prevent saving of the model instance. A convenience method `validation_error()` may be used to simplify this process. Raising a `ValidationError` is no different than vanilla Django, and the convenience method will simply pass the provided message through to the exception.
-
-When a CustomValidator is instantiated, the model instance is assigned to context dictionary using the `object` key, much like TemplateExtension. E.g. `self.context['object']`.
-
-Declared subclasses should be gathered into a list or tuple for integration with Nautobot. By default, Nautobot looks for an iterable named `custom_validators` within a `custom_validators.py` file. (This can be overridden by setting `custom_validators` to a custom value on the app's `NautobotAppConfig`.) An example is below.
-
-```python
-# custom_validators.py
-from nautobot.apps.models import CustomValidator
-
-
-class LocationValidator(CustomValidator):
-    """Custom validator for Locations to enforce that they must have a Tenant."""
-
-    model = 'dcim.location'
-
-    def clean(self):
-        if self.context['object'].tenant is None:
-            # Enforce that all locations must have a tenant
-            self.validation_error({
-                "tenant": "All locations must have a tenant"
-            })
-
-
-custom_validators = [LocationValidator]
-```

nautobot/docs/development/apps/api/platform-features/filter-extensions.md

@@ -1,49 +0,0 @@
-# Extending Filters
-
-+++ 1.3.0
-
-Apps can extend any model-based `FilterSet` and `FilterForm` classes that are provided by the Nautobot core.
-
-The requirements to extend a filter set or a filter form (or both) are:
-
-* The file must be named `filter_extensions.py`
-* The variable `filter_extensions` must be declared in that file, and contain a list of `FilterExtension` subclasses
-* The `model` attribute of each `FilterExtension` subclass must be set to a valid model name in the dotted pair format (`{app_label}.{model}`, e.g. `tenant.tenant` or `dcim.device`)
-
-Nautobot dynamically creates many additional filters based upon the defined filter type. Specifically, there are additional lookup expressions (referred to in code as `lookup_expr`) that are created for each filter, when there is neither a `lookup_expr` nor `method` parameter already set. These dynamically-added lookup expressions are added using a shorthand notation (e.g. `icontains` is `ic`). Nautobot will also add the negation of each, for example, so `icontains` will be added along with _not_ `icontains` using the `ic` and `nic` expressions respectively.
-
-The dynamically-added lookup expressions can be found in the source code at [nautobot/core/constants.py](https://github.com/nautobot/nautobot/blob/main/nautobot/core/constants.py) and the mapping logic can be found in [nautobot/core/filters.py](https://github.com/nautobot/nautobot/blob/main/nautobot/core/filters.py). Please see the documentation on [filtering](../../../../user-guide/platform-functionality/rest-api/filtering.md##lookup-expressions) for more information.
-
-!!! tip
-    For developers of apps that define their own model filters, note that the above are added dynamically, as long as the class inherits from `nautobot.apps.filters.BaseFilterSet`.
-
-However, that does not cover every possible use case, to list a few examples:
-
-* Usage of a custom `method` argument on a filter that points to a `FilterSet` method, which would allow arbitrary filtering using custom logic. This is how the `q` field search logic is currently performed.
-* Creation of a filter on a field that does not currently have filtering support
-* Convenience methods for highly nested fields
-
-There are several conditions that must be met in order to extend a filter:
-
-* The original FilterSet must follow the pattern: `f"{model.__name__}FilterSet"` e.g. `TenantFilterSet`
-* The `FilterExtension.filterset_fields` attribute must be a valid dict, with each key being the filter name (which must start with the plugin's `name` + `_`, e.g. `"example_plugin_description"`, not merely `"description"`) and each value being a valid [django-filter](https://django-filter.readthedocs.io/en/main/) filter
-
-Nautobot will dynamically generate the additional relevant lookup expressions of an app's defined custom FilterSet field, so no need to additionally register `example_plugin_description__ic`, etc.
-
-Similar to `FilterSet` fields, Nautobot provides a default filter form for each model, however that does not cover every possible use case. To list a few examples of why one may want to extend a filter form:
-
-* The base filter form does not include a custom filter defined by the app as described above
-* The base filter form does not provide a specific lookup expression to a filterable field, such as allowing regex on name
-
-There are several conditions that must be met in order to extend a filter:
-
-* The original `FilterForm` must follow the pattern: `f"{model.__name__}FilterForm"`, e.g. `TenantFilterForm`
-* The `filterform_fields` attribute must be a valid dictionary of Django form fields
-
-!!! note
-    An app is not required to define both `filterset_fields` and `filterform_fields`.
-
-You can view an example of `filter_extensions.py` by viewing [the one provided](https://github.com/nautobot/nautobot/blob/main/examples/example_plugin/example_plugin/filter_extensions.py) with the Example Plugin.
-
-!!! tip
-    The `method` parameter, if used, must be a callable (method/function). Note that because filters with a `method` do their filtering in Python code rather than at the database level, performance of `method` filters is generally much poorer than pure-database filters. The `method` parameter is not supported when using [Dynamic Groups](../../../../user-guide/platform-functionality/dynamicgroup.md).

nautobot/docs/development/apps/api/platform-features/git-repository-content.md

@@ -1,62 +0,0 @@
-# Loading Data from a Git Repository
-
-It's possible for an app to register additional types of data that can be provided by a [Git repository](../../../../user-guide/platform-functionality/gitrepository.md) and be automatically notified when such a repository is refreshed with new data. By default, Nautobot looks for an iterable named `datasource_contents` within a `datasources.py` file. (This can be overridden by setting `datasource_contents` to a custom value on the app's `NautobotAppConfig`.) An example is below.
-
-```python
-# datasources.py
-import yaml
-import os
-
-from nautobot.extras.choices import LogLevelChoices
-from nautobot.apps.datasources import DatasourceContent
-
-from .models import Animal
-
-
-def refresh_git_animals(repository_record, job_result, delete=False):
-    """Callback for GitRepository updates - refresh Animals managed by it."""
-    if 'nautobot_animal_sounds.Animal' not in repository_record.provided_contents or delete:
-        # This repository is defined not to provide Animal records.
-        # In a more complete worked example, we might want to iterate over any
-        # Animals that might have been previously created by this GitRepository
-        # and ensure their deletion, but for now this is a no-op.
-        return
-
-    # We have decided that a Git repository can provide YAML files in a
-    # /animals/ directory at the repository root.
-    animal_path = os.path.join(repository_record.filesystem_path, 'animals')
-    for filename in os.listdir(animal_path):
-        with open(os.path.join(animal_path, filename)) as fd:
-            animal_data = yaml.safe_load(fd)
-
-        # Create or update an Animal record based on the provided data
-        animal_record, created = Animal.objects.update_or_create(
-            name=animal_data['name'],
-            defaults={'sound': animal_data['sound']}
-        )
-
-        # Record the outcome in the JobResult record
-        job_result.log(
-            "Successfully created/updated animal",
-            obj=animal_record,
-            level_choice=LogLevelChoices.LOG_INFO,
-            grouping="animals",
-        )
-
-
-# Register that Animal records can be loaded from a Git repository,
-# and register the callback function used to do so
-datasource_contents = [
-    (
-        'extras.gitrepository',                                  # datasource class we are registering for
-        DatasourceContent(
-            name='animals',                                      # human-readable name to display in the UI
-            content_identifier='nautobot_animal_sounds.animal',  # internal slug to identify the data type
-            icon='mdi-paw',                                      # Material Design Icons icon to use in UI
-            callback=refresh_git_animals,                        # callback function on GitRepository refresh
-        )
-    )
-]
-```
-
-With this code, once your app is installed, the Git repository creation/editing UI will now include "Animals" as an option for the type(s) of data that a given repository may provide. If this option is selected for a given Git repository, your `refresh_git_animals` function will be automatically called when the repository is synced.

nautobot/docs/development/apps/api/platform-features/index.md

@@ -1 +0,0 @@
-# Extending Existing Functionality

nautobot/docs/development/apps/api/platform-features/jinja2-filters.md

@@ -1,28 +0,0 @@
-# Adding Jinja2 Filters
-
-+++ 1.1.0
-
-Apps can define custom Jinja2 filters to be used when rendering templates defined in computed fields. Check out the [official Jinja2 documentation](https://jinja.palletsprojects.com/en/3.0.x/api/#custom-filters) on how to create filter functions.
-
-In the file that defines your filters (by default `jinja_filters.py`, but configurable in the `NautobotAppConfig` if desired), you must import the `library` module from the `django_jinja` library. Filters must then be decorated with `@library.filter`. See an example below that defines a filter called `leet_speak`.
-
-```python
-from django_jinja import library
-
-
-@library.filter
-def leet_speak(input_str):
-    charset = {"a": "4", "e": "3", "l": "1", "o": "0", "s": "5", "t": "7"}
-    output_str = ""
-    for char in input_str:
-        output_str += charset.get(char.lower(), char)
-    return output_str
-```
-
-This filter will then be available for use in computed field templates like so:
-
-```jinja2
-{{ "HELLO WORLD" | leet_speak }}
-```
-
-The output of this template results in the string `"H3110 W0R1D"`.

nautobot/docs/development/apps/api/platform-features/jobs.md

@@ -1,29 +0,0 @@
-# Including Jobs
-
-Apps can provide [Jobs](../../../../user-guide/platform-functionality/jobs/index.md) to take advantage of all the built-in functionality provided by that feature (user input forms, background execution, results logging and reporting, etc.).
-
-By default, for each app, Nautobot looks for an iterable named `jobs` within a `jobs.py` file. (This can be overridden by setting `jobs` to a custom value on the app's `NautobotAppConfig`.) A brief example is below; for more details on Job design and implementation, refer to the Jobs feature documentation.
-
-```python
-# jobs.py
-from nautobot.apps.jobs import Job, register_jobs
-
-
-class CreateDevices(Job):
-    ...
-
-
-class DeviceConnectionsReport(Job):
-    ...
-
-
-class DeviceIPsReport(Job):
-    ...
-
-
-jobs = [CreateDevices, DeviceConnectionsReport, DeviceIPsReport]
-register_jobs(*jobs)
-```
-
-+/- 2.0.0
-    Because Jobs are now proper Celery tasks, you now must call `register_jobs()` from within your `jobs.py` file when it is imported; any jobs not included in this call will not be available for Celery to schedule and execute.

nautobot/docs/development/apps/api/platform-features/populating-extensibility-features.md

@@ -1,58 +0,0 @@
-# Populating Extensibility Features
-
-+++ 1.2.0
-
-In many cases, an app may wish to make use of Nautobot's various extensibility features, such as [custom fields](../../../../user-guide/platform-functionality/customfield.md) or [relationships](../../../../user-guide/platform-functionality/relationship.md). It can be useful for an app to automatically create a custom field definition or relationship definition as a consequence of being installed and activated, so that everyday usage of the app can rely upon these definitions to be present.
-
-To make this possible, Nautobot provides a custom [signal](https://docs.djangoproject.com/en/stable/topics/signals/), `nautobot_database_ready`, that apps can register to listen for. This signal is triggered when `nautobot-server migrate` or `nautobot-server post_upgrade` is run after installing an app, and provides an opportunity for the app to make any desired additions to the database at this time.
-
-For example, maybe we want our app to make use of a Relationship allowing each Location to be linked to our Animal model. We would define our callback function that makes sure this Relationship exists, by convention in a `signals.py` file:
-
-```python
-# signals.py
-
-from nautobot.extras.choices import RelationshipTypeChoices
-
-def create_location_to_animal_relationship(sender, apps, **kwargs):
-    """Create a Location-to-Animal Relationship if it doesn't already exist."""
-    # Use apps.get_model to look up Nautobot core models
-    ContentType = apps.get_model("contenttypes", "ContentType")
-    Relationship = apps.get_model("extras", "Relationship")
-    Location = apps.get_model("dcim", "Location")
-    # Use sender.get_model to look up models from this app
-    Animal = sender.get_model("Animal")
-
-    # Ensure that the Relationship exists
-    Relationship.objects.update_or_create(
-        key="location_favorite_animal",
-        defaults={
-            "label": "Location's Favorite Animal",
-            "type": RelationshipTypeChoices.TYPE_ONE_TO_MANY,
-            "source_type": ContentType.objects.get_for_model(Animal),
-            "source_label": "Locations that love this Animal",
-            "destination_type": ContentType.objects.get_for_model(Location),
-            "destination_label": "Favorite Animal",
-        },
-    )
-```
-
-Then, in the `NautobotAppConfig` `ready()` function, we connect this callback function to the `nautobot_database_ready` signal:
-
-```python
-# __init__.py
-
-from nautobot.apps import nautobot_database_ready, NautobotAppConfig
-
-from .signals import create_location_to_animal_relationship
-
-class AnimalSoundsConfig(NautobotAppConfig):
-    # ...
-
-    def ready(self):
-        super().ready()
-        nautobot_database_ready.connect(create_location_to_animal_relationship, sender=self)
-
-config = AnimalSoundsConfig
-```
-
-After writing this code, run `nautobot-server migrate` or `nautobot-server post_upgrade`, then restart the Nautobot server, and you should see that this custom Relationship has now been automatically created.

nautobot/docs/development/apps/api/platform-features/secrets-providers.md

@@ -1,64 +0,0 @@
-# Implementing Secrets Providers
-
-+++ 1.2.0
-
-An app can define and register additional providers (sources) for [Secrets](../../../../user-guide/platform-functionality/secret.md), allowing Nautobot to retrieve secret values from additional systems or data sources. By default, Nautobot looks for an iterable named `secrets_providers` within a `secrets.py` file. (This can be overridden by setting `secrets_providers` to a custom value on the app's `NautobotAppConfig`.)
-
-To define a new `SecretsProvider` subclass, we must specify the following:
-
-* A unique `slug` string identifying this provider
-* A human-readable `name` string (optional; the `slug` will be used if this is not specified)
-* A Django form for entering the parameters required by this provider, as an inner class named `ParametersForm`
-* An implementation of the `get_value_for_secret()` API to actually retrieve the value of a given secret
-
-For a simple (insecure!) example, we could define a "constant-value" provider that simply stores a constant value in Nautobot itself and returns this value on demand.
-
-!!! warning
-    This is an intentionally simplistic example and should not be used in practice! Sensitive secret data should never be stored directly in Nautobot's database itself.
-
-```python
-# secrets.py
-from django import forms
-from nautobot.apps.secrets import SecretsProvider
-from nautobot.utilities.forms import BootstrapMixin
-
-
-class ConstantValueSecretsProvider(SecretsProvider):
-    """
-    Example SecretsProvider - this one just returns a user-specified constant value.
-
-    Obviously this is insecure and not something you'd want to actually use!
-    """
-
-    slug = "constant-value"
-    name = "Constant Value"
-
-    class ParametersForm(BootstrapMixin, forms.Form):
-        """
-        User-friendly form for specifying the required parameters of this provider.
-        """
-        constant = forms.CharField(
-            required=True,
-            help_text="Constant secret value. <strong>DO NOT USE FOR REAL DATA</strong>"
-        )
-
-    @classmethod
-    def get_value_for_secret(cls, secret, obj=None, **kwargs):
-        """
-        Return the value defined in the Secret.parameters "constant" key.
-
-        A more realistic SecretsProvider would make calls to external APIs, etc.,
-        to retrieve a secret from another system as desired.
-
-        Args:
-            secret (nautobot.extras.models.Secret): The secret whose value should be retrieved.
-            obj (object): The object (Django model or similar) providing context for the secret's
-                parameters.
-        """
-        return secret.rendered_parameters(obj=obj).get("constant")
-
-
-secrets_providers = [ConstantValueSecretsProvider]
-```
-
-After installing and enabling your app, you should now be able to navigate to `Secrets > Secrets` and create a new Secret, at which point `"constant-value"` should now be available as a new secrets provider to use.

nautobot/docs/development/apps/api/platform-features/uniquely-identify-objects.md

@@ -1,63 +0,0 @@
-# Uniquely Identifying a Nautobot Object
-
-In Nautobot v1.X, the slug field of many models could be used to uniquely identify a specific instance in the database. This was a convenient way to reference an object, but the slug field had some drawbacks and slugs were ultimately removed in Nautobot v2.0. As a result, new patterns will have to be adopted when trying to retrieve specific objects from the database.
-
-## Primary Keys vs. Natural Keys
-
-When designing an application for Nautobot, one of the key decisions is whether to use a primary key or a natural key to uniquely identify individual model instances. Here are some trade-offs to consider:
-
-### Primary Keys
-
-The primary key is a concrete database field and is the primary method for referencing an object or relating multiple objects in the Nautobot database. Here are some advantages of using primary keys:
-
-- **Uniqueness:** Primary keys are guaranteed to be unique.
-- **Performance:** Primary keys are always indexed in Nautobot, which makes lookups very fast.
-
-However, there are also some disadvantages to using primary keys:
-
-- **Usability**: Primary keys in Nautobot use UUIDs and can be difficult to work with directly.
-- **Portability:** Primary keys are specific to a single database and cannot be used to identify an object in multiple contexts, such as in external applications or in different databases.
-
-### Natural Keys
-
-A natural key is an identifier that is based on the natural attributes of a record, such as a platform's name or, in the case of some Nautobot models, a combination of fields. For example, the Prefix model's natural key is formed using a combination of the `prefix` field and the associated Namespace's `name`. Here are some advantages of using natural keys:
-
-- **Usability:** Natural keys are more user-friendly and easier to remember.
-- **Portability:** Natural keys can be used to identify an object in multiple contexts, such as in external applications or in different databases.
-
-However, there are also some disadvantages to using natural keys:
-
-- **Complexity:** Using natural keys can make it more difficult to change the underlying data structure without breaking existing integrations.
-- **Performance:** Natural keys are not guaranteed to be indexed which can make lookups slower. Also, natural keys that include fields from related objects will require database joins to retrieve the object from the database.
-
-In general, the decision of whether to use a primary key or a natural key depends on the specific requirements of the application. If uniqueness is critical, or if performance is a concern, a primary key may be the best choice. If human-readability is important, or if portability is a concern, a natural key may be the best choice.
-
-### Using Primary Keys
-
-In Nautobot v2.0, all object view URLs use the primary key of the object. In the web UI and REST API, the object can be accessed by building a URL using the primary key. For example, to retrieve the device with primary key `00000000-0000-0000-0000-000000000000`, the REST API URL would be `/api/dcim/devices/00000000-0000-0000-0000-000000000000/`.
-
-In the Python ORM, the object can be retrieved using the `get()` method of the model manager. For example, to retrieve the device with primary key `00000000-0000-0000-0000-000000000000`, the Python ORM call would be `Device.objects.get(pk='00000000-0000-0000-0000-000000000000')`. Once an instance of the object is retrieved, the primary key can be accessed using the `pk` attribute.
-
-### Using Natural Keys
-
-Natural keys in Nautobot v2.0 are determined by the combination of database fields that uniquely identify an object. In some cases, such as the Platform model, this is a single field (`name`). In other cases, such as the Prefix model, this is a combination of fields (`namespace__name`, `prefix`). To retrieve the list of lookups that are used to form the natural key for a model, use the `natural_key_field_lookups` property of the model. For example, to retrieve the list of fields that are used to form the natural key for the Prefix model, the Python ORM call would be `Prefix.natural_key_field_lookups`.
-
-In Nautobot v2.0, the REST API and web UI list views can be filtered to find objects based on their attributes. In some cases, these filters will be sufficient for filtering a list down to an individual object. For example, to retrieve the device with name "router1" in tenant "xyz", the REST API URL would be `/api/dcim/devices/?name=router1&tenant=xyz`. However, the filters in Nautobot do not currently cover all combinations of natural key field lookups for all models and the previous example could return multiple objects because it does not filter on the location field which is also required to uniquely define a device.
-
-In the Python ORM, objects can be retrieved using the `get_by_natural_key()` method of the model manager. For example, to retrieve the prefix for "10.0.0.0/8" in namespace "Global", the Python ORM call would be `Prefix.objects.get_by_natural_key("Global", "10.0.0.0/8")`. Once an instance of a model is retrieved, the natural key can be accessed using the `natural_key` method:
-
-```py
->>> prefix = Prefix.objects.get_by_natural_key("Global", "10.0.0.0/8")
->>> prefix.natural_key()
-['Global', '10.0.0.0/8']
-```
-
-!!! info
-    See the [documentation on natural keys](../../../../development/core/natural-keys.md) for more information on Nautobot's natural key implementation.
-
-## Customizing Natural Keys
-
-Nautobot provides settings for overriding the default behavior of the natural key for some models. These allow the natural key to be formed by a single field instead of a combination of fields. For more information, see the documentation for the settings listed below.
-
-- [DEVICE_NAME_AS_NATURAL_KEY](../../../../user-guide/administration/configuration/optional-settings.md#device_name_as_natural_key)
-- [LOCATION_NAME_AS_NATURAL_KEY](../../../../user-guide/administration/configuration/optional-settings.md#location_name_as_natural_key)

nautobot/docs/development/apps/api/prometheus.md

@@ -1,25 +0,0 @@
-# Prometheus Metrics
-
-+++ 1.5.13
-
-It is possible for Nautobot apps to provide their own [Prometheus metrics](../../../user-guide/administration/guides/prometheus-metrics.md). There are two general ways to achieve this:
-
-1. Use the `prometheus_client` library directly in your app code. Depending on whether that code runs in the web server or the worker context, the metric will show up in the respective `/metrics` endpoint(s) (i.e. metrics generated in the worker context show up in the worker's endpoint and those generated in the web application's context show up in the web application's endpoint).
-2. If the metric cannot be generated alongside existing code, apps can implement individual metric generator functions and register them into a list called `metrics` in a file named `metrics.py` at the root of the app. Nautobot will automatically read these and expose them via its `/metrics` endpoint. The following code snippet shows an example metric defined this way:
-
-```python
-# metrics.py
-from prometheus_client.metrics_core import GaugeMetricFamily
-
-from nautobot_animal_sounds.models import Animal
-
-
-def metric_animals():
-    gauges = GaugeMetricFamily("nautobot_noisy_animals_count", "Nautobot Noisy Animals Count", labels=[])
-    screaming_animal_count = Animal.objects.filter(loudness="noisy").count()
-    gauges.add_metric(labels=[], value=screaming_animal_count)
-    yield gauges
-
-
-metrics = [metric_example]
-```