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

nautobot/docs/user-guide/platform-functionality/rest-api/ui-related-endpoints.md

@@ -1,9 +0,0 @@
-# UI Related API Endpoints
-
-+++ 2.0.0
-
-Nautobot now retrieves its UI component information from API endpoints.
-
-!!!important
-    These UI-related API endpoints serve a very different purpose from the rest. While we encourage users to utilize other API endpoints whenever possilbe in custom development, these API endpoints are not for external users and for internal use only. Therefore, they are not subject to Semantic Versioning and can change at any time to fit Nautobot UI needs until we decide that we are ready to support UI specific endpoints.
-    Note that these API endpoints are hidden from OpenAPI schema as well.

nautobot/docs/user-guide/platform-functionality/role.md

@@ -1,17 +0,0 @@
-# Roles
-
-The Role model represents a role that can be assigned to a device, rack, virtual machine, IP address, VLAN, or prefix. Each role is identified by a unique name and has a weight, color and content-types associated with it.
-
-## Role Basics
-
-The value of a `role` field on a model (such as `Device.role`) will be represented as a `nautobot.extras.models.Role` object.
-
-When created, a `Role` can be associated to one or more model content-types using a many-to-many relationship. The relationship to each model is referenced across all user interfaces using the `{app_label}.{model}` naming convention (e.g. `dcim.device`).
-
-Roles may be managed by navigating to **Organization > Roles** in the navigation menu.
-
-### Importing Objects with a `role` Field
-
-When using CSV import to reference a `role` field on an object, the `Role.name` field is used.
-
-Visit [role-internals](../../development/core/role-internals.md) to learn more about working with `role` as a developer.

nautobot/docs/user-guide/platform-functionality/secret.md

@@ -1,136 +0,0 @@
-# Secrets
-
-+++ 1.2.0
-
-For security reasons, Nautobot generally does not store sensitive secrets (device access credentials, systems-integration API tokens, etc.) in its own database. There are other approaches and systems better suited to this purpose, ranging from simple solutions such as process-specific environment variables or restricted-access files on disk, all the way through to dedicated systems such as Hashicorp Vault or AWS Secrets Manager.
-
-However, any number of Nautobot features (including, but not limited to, device access via NAPALM, Git repository access, custom Jobs, and various plugins seeking to integrate with third-party systems) do need the ability to retrieve and make use of such secrets. Towards that end, Nautobot provides a `Secret` database model. This model does **not** store the secret value itself, but instead defines **how** Nautobot can retrieve the secret value as and when it is needed. By using this model as an abstraction of the underlying secrets storage implementation, this makes it possible for any Nautobot feature to make use of secret values without needing to know or care where or how the secret is actually stored.
-
-Secrets can be grouped and assigned a specific purpose as members of a Secrets Group, which can then be attached to a Git repository, device, or other data model as needed for a given purpose.
-
-## Secrets Groups
-
-+++ 1.2.0
-
-A Secrets Group provides a way to collect and assign a purpose to one or more Secrets. The Secrets Group can then be attached to any object that needs to reference and make use of these Secrets, such as a Git repository needing a username/token to authenticate to a private GitHub repository, or a device using a group of Secrets to drive its NAPALM integration.
-
-When creating or editing a Secrets Group, you can assign any number of defined Secrets to this group, assigning each secret an *access type* and a *secret type* that are unique within the context of this group. Some examples of how a Secrets Group might be populated for use by a given feature:
-
-| Feature                   | Access Type | Secrets Type(s)                                     |
-|---------------------------|-------------|-----------------------------------------------------|
-| Git private repository    | `HTTP(S)`   | `Token`, possibly also `Username`                   |
-| Device NAPALM integration | `Generic`   | `Username`, `Password`, possibly an enable `Secret` |
-
-A Secrets Group is not limited to containing secrets of a single *access type* either - for example, a plugin that supports both NETCONF and gNMI protocols to interact with a device could be able to make use of a Secrets Group containing distinct secrets for each protocol.
-
-## Secrets Providers
-
-Each Secret is associated with a secrets provider (not to be confused with a circuit provider), which provides the functionality needed to retrieve a specific value from a particular source of secrets. Each secrets provider also defines the set of parameters that a given Secret must specify in order to retrieve a secret value from this provider. Nautobot includes the following built-in secrets providers:
-
-- *Environment Variable* - for retrieving a secret value defined in an environment variable; Secrets using this provider must specify the `variable` name to retrieve.
-- *Text File* - for retrieving a secret value stored in a text file; Secrets using this provider must specify the absolute `path` of the file to retrieve.
-
-+/- 1.4.3
-    When using the Text File secrets provider, any leading and trailing whitespace or newlines will be stripped.
-
-When defining a new Secret, you will need to select the desired secrets provider and then fill in the specific parameters required by that provider in order to have a completely specified, usable Secret record.
-
-!!! tip
-    Nautobot plugins can also implement and register additional secrets providers as desired to support other sources such as Hashicorp Vault or AWS Secrets Manager.
-
-## Templated Secret Parameters
-
-In some cases you may have a collection of closely related secrets values that all follow a similar retrieval pattern. For example you might have a directory of text files each containing the unique password for a specific device, or have defined a set of environment variables providing authentication tokens for each different Git repository. In this case, to reduce the need for repeated data entry, Nautobot provides an option to use Jinja2 templates to dynamically alter the provider parameters of a given Secret based on the requesting object. The relevant object is passed to Jinja2 as `obj`. Thus, for example:
-
-- A "Device Password" secret could use the *Text File* provider and specify the file `path` as `"/opt/nautobot/device_passwords/{{ obj.location.name }}/{{ obj.name }}.txt"`, so that a device `csr1` at location `NYC` would be able to retrieve its password value from `/opt/nautobot/device_passwords/NYC/csr1.txt`.
-- A "Git Token" secret could use the *Environment Variable* provider and specify the `variable` name as `"GIT_TOKEN_{{ obj.slug | upper }}"`, so that a Git repository `golden_config` would be able to retrieve its token value from `$GIT_TOKEN_GOLDEN_CONFIG`.
-
-!!! note
-    To access custom fields of an object within a template, use the `cf` attribute. For example, `{{ obj.cf.color }}` will return the value (if any) for the custom field with a key of `color` on `obj`.
-
-## Secrets and Security
-
-Secrets are of course closely linked to security, and as such they pose a number of unique concerns that are worth discussing.
-
-### Leakage of Secret Values
-
-By design, the UI, REST API, and GraphQL do **not** provide access to retrieve or report the actual value of any given Secret, as these values are only meant for use *within* Nautobot itself.
-
-!!! tip
-    If you need to use a secret value for some other purpose (such as to manually log into a device, or query an authenticated REST API endpoint yourself), you should be retrieving the value directly from the appropriate secrets provider rather than trying to relay it through Nautobot.
-
-However, code is power, and with power comes responsibility.
-
-!!! warning
-    Any user or process that has the ability to execute code within Nautobot has the **potential** to access the value of any Secret, and a user or process that has the ability to execute *arbitrary* code absolutely **can** access Secrets.
-
-What does this mean in practice?
-
-- Any [plugin](../../apps/index.md) can potentially access your Secrets, including displaying their values onscreen or even forwarding them to an external system, so only install plugins that you trust.
-- Any [Job](./jobs/index.md) can potentially access your Secrets, and can trivially log a Secret value to its JobResult, where it may be visible to users, so only install Jobs that you trust, carefully limit which users are able to execute jobs and view job results, and be aware of the potential for privilege escalation resulting from careless or malicious logging.
-- Any [Git repository](./gitrepository.md) can add new Jobs to your system, so be careful about which users you grant the ability to create/edit `GitRepository` records.
-- Any user with access to [`nautobot-server nbshell`](../administration/tools/nautobot-shell.md) can execute arbitrary code, including accessing Secrets, and will be able to bypass any Nautobot permissions restrictions as well.
-- Any user with access to modify Secrets can take advantage of a leak of one Secret's information through any of the above vectors to additionally leak other secret values (except as restricted with [object permissions](#using-object-permissions-with-secrets), see below). For example, if a Job erroneously logs a username obtained from a Secret as a part of its output, a user could modify the corresponding Secret definition to make the Job log any other secret value they have access to.
-
-### Using Object Permissions with Secrets
-
-!!! tip
-    In practice you will likely want to carefully restrict which users are allowed to define and edit Secrets, and may want to use object permissions to further restrict which specific Secrets they are allowed to utilize.
-
-The two default Secrets providers potentially allow a user to define and use a Secret corresponding to any environment variable in the Nautobot execution context and/or any file readable by the `nautobot` user. For many users and use cases, you will not want to grant this much power to define and access arbitrary secrets; fortunately Nautobot's built-in permissions model is granular enough to allow for more specifically tailored access grants.
-
-For example, to restrict a specific user to only be able to work with Secrets that use the `environment-variable` Secrets provider, and specifically only to access those environment variables whose names begin with `NAPALM_`, you could define a Permission with a specific constraint like:
-
-```json
-{
-    "provider": "environment-variable",
-    "parameters__variable__startswith": "NAPALM_"
-}
-```
-
-Or for a Permission to work with Secrets that use `text-file`, but only files located in `/opt/nautobot/secrets/`, you could use the following constraint:
-
-```json
-{
-    "provider": "text-file",
-    "parameters__path__startswith": "/opt/nautobot/secrets/"
-}
-```
-
-## Accessing Secrets in Code
-
-Accessing a Secret's value from code is as simple as calling its `get_value()` method. Providing an `obj` parameter for context is recommended so as to allow for proper handling of templated secret parameters:
-
-```python
->>> secret = Secret.objects.get(name="NAPALM Username")
->>> secret.get_value()
-'user'
->>> secret = Secret.objects.get(name="NAPALM Password")
->>> secret.get_value(obj=device1)
-'secret-device1-password'
-```
-
-In the case where a secret's value cannot be retrieved successfully, Nautobot will raise a `SecretError` or one of its subclasses:
-
-```python
->>> from nautobot.extras.secrets.exceptions import SecretError
->>> try:
-...     Secret.objects.get(name="NAPALM Secret").get_value()
-... except SecretError as exc:
-...     print(exc)
-...
-SecretValueNotFoundError: Secret "NAPALM Secret" (provider "EnvironmentVariableSecretsProvider"): Undefined environment variable "NAPALM_SECRET"!
-```
-
-In many cases, rather than accessing a specific Secret directly, you will be working with a Secrets Group instead. To retrieve the value of a specific secret within a group, use the group's `get_secret_value()` method, again with the option of providing an `obj` for template context:
-
-```python
->>> secrets_group = SecretsGroup.objects.get(name="NETCONF Credentials")
->>> from nautobot.extras.choices import SecretsGroupAccessTypeChoices, SecretsGroupSecretTypeChoices
->>> secrets_group.get_secret_value(
-...     access_type=SecretsGroupAccessTypeChoices.TYPE_NETCONF,
-...     secret_type=SecretsGroupSecretTypeChoices.TYPE_USERNAME,
-...     obj=device1,
-... )
-"user-device1"
-```

nautobot/docs/user-guide/platform-functionality/status.md

@@ -1,92 +0,0 @@
-# Statuses
-
-Nautobot provides the ability for custom statuses to be defined within an organization to be used on various objects to facilitate business workflows around object statuses.
-
-## Status Basics
-
-The value of a `status` field on a model (such as `Device.status`) will be represented as a `nautobot.extras.models.Status` object.
-
-When created, a `Status` can be associated to one or more model content-types using a many-to-many relationship. The relationship to each model is referenced across all user interfaces using the `{app_label}.{model}` naming convention (e.g. `dcim.device`).
-
-Statuses may be managed by navigating to **Organization > Statuses** in the navigation menu.
-
-### Importing Objects with a `status` Field
-
-When using CSV import to reference a `status` field on an object, the `Status.name` field is used.
-
-+/- 2.0.0
-    Changed the CSV import reference for Statuses from `Status.slug` to `Status.name`.
-
-## Customizing Statuses
-
-With Status as a model, statuses can be customized. This can be as simple as removing the option to configure an existing status with a particular model or to remove that status entirely.
-
-The real benefit of custom status is adding your own organization status and process names directly to Nautobot. An example of custom statuses would be including End of Life information for your devices. A simple End of Life status could be EOx for a device hitting any end of life milestone; more specific statuses like EOSS (End of Software Support), EOS (End of Sale), and Pre-EOS (for 1 year prior to EOS) to be more specific. Once the end of life information is tracked as a status, developing a report for Devices that have reached EOSS is trivial.
-
-Another example for locations is tracking the nature of a specific location's installation status. A location that is under construction could receive a status like 'Pre Production'.
-
-For Virtual Machines, if utilizing OpenStack, statuses in Nautobot could be customized to reflect the specific [Nova virtual machine states](https://docs.openstack.org/nova/latest/reference/vm-states.html).
-
-## Status Internals
-
-!!! warning
-    The section below is largely intended for developers who may need to create
-    data models of their own that implement a `status` field. Proceed at your
-    own risk!
-
-Any model that is intended to have a `status` field must use a `nautobot.extras.models.statuses.StatusField` for its foreign-key to the model. This field type will automatically assign a `related_name` for the reverse relationship back to the inheriting model's verbose plural name (e.g. `devices`).
-
-+/- 2.0.0
-    The related name for Statuses was changed to be based on the model's `verbose_name_plural` instead of the pattern `%(app_label)s_%(model)s_related`. For example, `Status.devices` and not `Status.dcim_device_related`. Additionally, the recommendation to inherit from `StatusModel` has been replaced with a recommendation to directly include a `StatusField`.
-
-### `StatusField` model field
-
-The `StatusField` field type subclass of a `django.db.models.ForeignKey` with extra extensions to have it behave like field with choices. Because this pattern is replacing hard-coded `ChoiceSets` (such as `dcim.choices.DeviceStatusChoices`) with database objects, it is not possible to use the `choices=` argument on a foreign key.
-
-Because of this, `StatusField` implements a `.contribute_to_class()` method which will automatically bind `.get_status_display()` and `.get_status_color()` methods to any model that implements this field, so that these do not need to be manually defined on each model.
-
-This model field also emits its own form field to eliminate the requirement for a form field to be explicitly added to model forms.
-
-### `StatusFilter` filter field
-
-Any filter that is intended to have a `status` field must inherit from `nautobot.extras.filters.StatusModelFilterSetMixin`. This will add a `nautobot.extras.filters.StatusFilter` to the filter, which allows filtering by the `name` of the status.
-
-### Form fields
-
-Any model form that is intended to have a `status` field must inherit from one of three mixins, depending on the use-case:
-
-- `nautobot.extras.forms.StatusModelFilterFormMixin` should be used to add a non-required, multiple-choice `status` filter field to UI filter forms. This multiple-choice field allows for multiple status values to be selected for filtering objects in list views in the web UI.
-- `nautobot.extras.forms.StatusModelBulkEditFormMixin` should be used to add a non-required `status` form field to a an object's model form. This field constrains status choices eligible to the object type being edited.
-
-+/- 1.4.0
-    In prior Nautobot versions these mixins were named `StatusFilterFormMixin` and `StatusBulkEditFormMixin`; the old names are still available as aliases but will be removed in a future major release.
-
-### Table field
-
-If you wish for a table to include a `status` field, your table must inherit from `nautobot.extras.tables.StatusTableMixin`. This includes a `ColorColumn` on the table.
-
-## Status object integrations
-
-To fully integrate a model to include a `status` field, assert the following:
-
-### Model
-
-- The model must use a `nautobot.extras.models.statuses.StatusField`
-- Decorate the model class with `@extras_features('statuses')` (`from nautobot.extras.utils import extras_features`)
-
-### Forms
-
-- Generic model forms will automatically include a `StatusField`
-- Bulk edit model forms must inherit from `nautobot.extras.forms.StatusModelBulkEditFormMixin`
-- Filter forms must inherit from `nautobot.extras.forms.StatusModelFilterFormMixin`
-
-+/- 1.4.0
-    In prior Nautobot releases the latter two mixins were named `StatusBulkEditFormMixin` and `StatusFilterFormMixin` respectively; the old names are still available as aliases but will be removed in a future major release.
-
-### Filters
-
-- Filtersets for your model must inherit from `nautobot.extras.filters.StatusModelFilterSetMixin`
-
-### Tables
-
-- The table class for your model must inherit from `nautobot.extras.tables.StatusTableMixin`

nautobot/docs/user-guide/platform-functionality/tag.md

@@ -1,62 +0,0 @@
-# Tags
-
-Tags are user-defined labels which can be applied to a variety of objects within Nautobot. They can be used to establish dimensions of organization beyond the relationships built into Nautobot. For example, you might create a tag to identify a particular ownership or condition across several types of objects.
-
-+++ 1.3.0
-    When created, a `Tag` can be associated to one or more model content-types using a many-to-many relationship. The tag will then apply only to models belonging to those associated content-types.
-
-Each tag has a name, label, color, and permitted content-types. Each tag can also be assigned a description indicating its purpose.
-
-Objects can be filtered by the tags they have applied. For example, the following API request will retrieve all devices tagged as "monitored":
-
-```no-highlight
-GET /api/dcim/devices/?tag=monitored
-```
-
-The `tag` filter can be specified multiple times to match only objects which have _all_ of the specified tags assigned:
-
-```no-highlight
-GET /api/dcim/devices/?tag=monitored&tag=deprecated
-```
-
-Tags can also be created in the ORM or REST API of Nautobot. The following HEX color values in the table below correspond to the dropdown selection when building tags using the UI. Any HEX color value can be used with the ORM or REST API, but a non-standard color will cause some inconsistency when editing the tag via the UI.
-
-| Color | HEX value |
-| :------------ | :------------ |
-| Dark Red | aa1409 |
-| Red | f44336 |
-| Pink | e91e63 |
-| Rose | ffe4e1 |
-| Fuchsia | ff66ff |
-| Purple | 9c27b0 |
-| Dark Purple | 673ab7 |
-| Indigo | 3f51b5 |
-| Blue | 2196f3 |
-| Light blue | 03a9f4 |
-| Cyan | 00bcd4 |
-| Teal | 009688 |
-| Aqua | 00ffff |
-| Dark green | 2f6a31 |
-| Green | 4caf50 |
-| Light green | 8bc34a |
-| Lime | cddc39 |
-| Yellow | ffeb3b |
-| Amber | ffc107 |
-| Orange | ff9800 |
-| Dark orange | ff5722 |
-| Brown | 795548 |
-| Light grey | c0c0c0 |
-| Grey | 9e9e9e |
-| Dark grey | 607d8b |
-| Black | 111111 |
-| White | ffffff |
-
-Example of ORM creation:
-
-```python
-Tag.objects.get_or_create(
-    name="Cisco-3650CX",
-    description="Device tag for Cisco 3650CX series",
-    color="2196f3"
-)
-```

nautobot/docs/user-guide/platform-functionality/template-filters.md

@@ -1,306 +0,0 @@
-# Additional Template Filters
-
-## Introduction
-
-Nautobot uses 2 template engines internally, Django Template and Jinja2. Django Template is used to render the UI pages and Jinja2 is used for features such as computed fields, custom links, export templates, etc.
-
-!!! note
-    Jinja2 and Django Template are very similar, the main difference between them is the syntax of the template. Historically, Django Template has been the go-to solution to generate webpage in Django and Jinja2 is the industry standard outside of Django.
-
-Both Django Template and Jinja2 can be extended with a library of functions, called `filters`, that apply formatting or transformations to a provided input. Nautobot provides many built-in `filters`, including network specific `filters` from the [netutils library](https://netutils.readthedocs.io/en/latest/).
-
-## Netutils Filters
-
-+++ 1.2.0
-
-[Netutils](https://netutils.readthedocs.io/en/latest/) is an external library, maintained by Network to Code, that is focusing on providing a collection of functions for common network automation tasks. Please [check the netutils documentation](https://netutils.readthedocs.io/en/latest/) to see the list of available functions.
-
-These functions are available automatically in Jinja2 rendered by Nautobot. For example you could define a [computed field](./computedfield.md) on Circuit objects, using the Netutils `bits_to_name` function, to display the "Commit Rate" as a human-readable value by using the template code `{{ (obj.commit_rate * 1000) | bits_to_name }}`. (This particular example is contrived, as the Nautobot UI already humanizes the raw `commit_rate` value for display, but it demonstrates the kinds of things that these filters can be used for.)
-
-In general the syntax for using a netutils filter in a Jinja2 template is something like `{{ arg1 | function_name }}` for functions that take a single argument, and `{{ arg1 | function_name(arg_name2=arg2, arg_name3=arg3) }}` for functions that take multiple arguments.
-
-+++ 1.5.11
-    Netutils functions are also available in Django templates after using the `{% load netutils %}` directive in a template. The syntax to use these functions is then generally `{% function_name arg_name1=arg1 arg_name2=arg2 %}`.
-
-## Nautobot Built-In Filters
-
-The Nautobot project also provides the following built-in `filters` that can be used in both Jinja2 and Django Template.
-
-### as_range
-
-Given a list of *n* items, return a corresponding range of *n* integers.
-
-```django
-# Django template
-{% for i in record.parents|as_range %}
-    <i class="mdi mdi-circle-small"></i>
-{% endfor %}
-```
-
-### bettertitle
-
-Alternative to the built-in `title` filter; capitalizes words without replacing letters that are already uppercase.
-
-For example, `title("IP address") == "Ip Address"`, while `bettertitle("IP address") == "IP Address"`.
-
-```django
-{{ obj_type.name|bettertitle }}
-```
-
-### divide
-
-Return x/y (rounded).
-
-```django
-# Django Template
-{{ powerfeed.available_power|divide:3 }}VA
-
-# Jinja
-{{ powerfeed.available_power|divide(3) }}
-```
-
-### fgcolor
-
-Return the ideal foreground color (black `"#000000"` or white `"#ffffff"`) given an arbitrary background color in RRGGBB format.
-
-```django
-color: {{ object.status.color|fgcolor }}
-```
-
-### get_docs_url
-
-Return the static URL of the documentation for the specified model.
-
-```django
-{{ obj | get_docs_url }}
-```
-
-### get_item
-
-Access a specific item/key in a dictionary.
-
-```django
-# Django Template
-{{ labels|get_item:key }}
-
-# Jinja
-{{ labels|get_item(key) }}
-```
-
-### queryset_to_pks
-
-Return all object's in a queryset UUIDs/pks as a string separated by a comma.
-
-```django
-# Django Template
-{{ ip.tags.all | queryset_to_pks }}
-```
-
-### has_one_or_more_perms
-
-Return True if the user has *at least one* of the permissions in the list.
-
-```django
-# Django Template
-{{ request.user|has_one_or_more_perms:panel_details.permissions }}
-
-# Jinja
-{{ request.user|has_one_or_more_perms(panel_details.permissions) }}
-```
-
-### has_perms
-
-Return True if the user has *all* permissions in the list.
-
-```django
-# Django Template
-{{ request.user|has_perms:group_item_details.permissions }}
-
-# Jinja
-{{ request.user|has_perms(group_item_details.permissions) }}
-```
-
-### humanize_speed
-
-Humanize speeds given in Kbps.
-    1544 => "1.544 Mbps"
-    100000 => "100 Mbps"
-    10000000 => "10 Gbps"
-
-```django
-{{ speed_value | humanize_speed }}
-```
-
-### hyperlinked_object
-
-+++ 1.4.0
-
-Render and link to a Django model instance, if any, or render a placeholder if not.
-
-Uses `object.display` if available, otherwise uses the string representation of the object.
-If the object defines `get_absolute_url()` this will be used to hyperlink the displayed object;
-additionally if there is an `object.description` this will be used as the title of the hyperlink.
-
-```django
-{{ device|hyperlinked_object }}
-```
-
-+++ 1.5.0
-    This filter now accepts an optional `field` parameter, which allows you to use a field other than `object.display` for the object representation if desired. For example, to display the object's `name` field instead:
-
-    ```django
-    # Django Template
-    {{ location|hyperlinked_object:"name" }}
-
-    # Jinja
-    {{ location|hyperlinked_object("name") }}
-    ```
-
-### meta
-
-Return the specified Meta attribute of a model.
-
-```django
-{{ obj | meta('app_label') }}
-```
-
-### meters_to_feet
-
-Convert a length from meters to feet.
-
-```django
-{{ meter_value | meters_to_feet }}
-```
-
-### percentage
-
-Return x/y as a percentage.
-
-```django
-# Django Template
-{{ powerfeed.available_power|percentage:total_power }}VA
-
-# Jinja
-{{ powerfeed.available_power|percentage(total_power) }}
-```
-
-### placeholder
-
-Render a muted placeholder (`<span class="text-muted">&mdash;</span>`) if value is falsey, else render the provided value.
-
-```django
-{{ html | placeholder }}
-```
-
-### render_boolean
-
-Render HTML from a computed boolean value.
-
-If value is (for example) a non-empty string or True or a non-zero number, this renders `<span class="text-success"><i class="mdi mdi-check-bold" title="Yes"></i></span>`
-
-If value is (for example) "" or 0 or False, this renders `<span class="text-danger"><i class="mdi mdi-close-thick" title="No"></i></span>`
-
-If value is None this renders `<span class="text-muted">&mdash;</span>`
-
-```django
-{{ value | render_boolean }}
-```
-
-### render_json
-
-Render a dictionary as formatted JSON.
-
-```django
-{{ data | render_json }}
-```
-
-### render_markdown
-
-Render text as Markdown.
-
-```django
-{{ text | render_markdown }}
-```
-
-### render_yaml
-
-Render a dictionary as formatted YAML.
-
-```django
-{{ data | render_yaml }}
-```
-
-### settings_or_config
-
-Get a value from Django settings (if specified) or Constance configuration (otherwise).
-
-```django
-{{ "RELEASE_CHECK_URL" | settings_or_config }}
-```
-
-+++ 2.0.0
-    This filter now accepts an optional `app_name` parameter, which allows you to use this filter for Third-Party Nautobot Apps.
-
-    ```django
-    # Django Template
-    {{ "SAMPLE_VARIABLE" | settings_or_config:"example_plugin" }}
-    {{ "lowercase_example" | settings_or_config:"example_plugin" }}
-    ```
-
-### slugify
-
-Slugify a string.
-
-```django
-# Django Template
-{{ string | slugify }}
-
-# Jinja
-{{ string | slugify }}
-```
-
-### split
-
-Split a string by the given value (default: comma)
-
-```django
-# Django Template
-{{ string | split }}
-{{ string | split:';' }}
-
-# Jinja
-{{ string | split }}
-{{ string | split(';') }}
-```
-
-### tzoffset
-
-Returns the hour offset of a given time zone using the current time.
-
-```django
-{{ object.time_zone|tzoffset }}
-```
-
-### validated_viewname
-
-Return the view name for the given model and action if valid, or None if invalid.
-
-```django
-# Django Template
-{{ obj | validated_viewname:'list' }}
-
-# Jinja
-{{ obj | validated_viewname('list') }}
-```
-
-### viewname
-
-Return the view name for the given model and action. Does not perform any validation.
-
-```django
-# Django Template
-{{ obj | viewname:'list' }}
-
-# Jinja
-{{ obj | viewname('list') }}
-```