nautobot 2.4.3__py3-none-any.whl → 2.4.4__py3-none-any.whl

nautobot/project-static/docs/user-guide/administration/configuration/settings.html

@@ -11431,9 +11431,6 @@
 <p>This document describes Nautobot-specific configuration settings that may be customized in your <code>nautobot_config.py</code>, or, in many cases, by configuration of appropriate environment variables. It also describes a number of common Django configuration settings that may also be customized similarly.</p>
 <p>The <a href="https://docs.djangoproject.com/en/stable/ref/settings/">official Django documentation</a> documents <em>all</em> Django settings, and this document does not attempt to replace that documentation.</p>
 <h2 id="administratively-configurable-settings">Administratively Configurable Settings<a class="headerlink" href="#administratively-configurable-settings" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
-</details>
 <p>A number of settings can alternatively be configured via the Nautobot Admin UI. To do so, these settings must <strong>not</strong> be defined in your <code>nautobot_config.py</code>, as any settings defined there will take precedence over any values defined in the Admin UI. Settings that are currently configurable via the Admin UI include:</p>
 <!-- pyml disable-num-lines 5 blanks-around-lists -->
 
@@ -13482,13 +13479,6 @@ in order for the repository to sync.</p>
 </div>
 <hr />
 <h3 id="nautobot_log_deprecation_warnings"><code>NAUTOBOT_LOG_DEPRECATION_WARNINGS</code><a class="headerlink" href="#nautobot_log_deprecation_warnings" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.5.2</summary>
-</details>
-<details class="version-changed">
-<summary>Changed in version 1.5.3</summary>
-<p>This was previously available as a config file setting but changed to environment-variable only. Also <code>DEBUG = True</code> will no longer work to log deprecation warnings.</p>
-</details>
 <p>Default: <code>False</code></p>
 <p>This can be set to <code>True</code> to allow deprecation warnings raised by Nautobot to (additionally) be logged as <code>WARNING</code> level log messages. (Deprecation warnings are normally silent in Python, but can be enabled globally by <a href="https://docs.python.org/3/library/warnings.html">various means</a> such as setting the <code>PYTHONWARNINGS</code> environment variable. However, doing so can be rather noisy, as it will also include warnings from within Django about various code in various package dependencies of Nautobot's, etc. This configuration setting allows a more targeted enablement of only warnings from within Nautobot itself, which can be useful when vetting various Nautobot Apps for future-proofness against upcoming changes to Nautobot.)</p>
 <hr />

nautobot/project-static/docs/user-guide/administration/guides/docker.html

@@ -9607,10 +9607,6 @@
 <p>Nautobot is packaged as a Docker image for use in a production environment; developer images are also provided for those working on App development and testing. The Docker image and deployment strategies are being actively developed, check back here or join the <code>#nautobot</code> channel on <a href="https://slack.networktocode.com/">Network to Code's Slack community</a> for the most up to date information.</p>
 <h2 id="python-versions">Python Versions<a class="headerlink" href="#python-versions" title="Permanent link">&para;</a></h2>
 <p>Docker images are published for multiple supported Python versions. The default image, recommended for most users, is based on the <code>python:3.12-slim</code> image.</p>
-<details class="version-changed">
-<summary>Changed in version 1.6.1</summary>
-<p>The Python version for the image tags that do not explicitly state a Python version changed to 3.11 for Nautobot 1.6.1. From now on, these tagged images will always contain the <strong>latest</strong> supported Python version (e.g., when Python 3.12 support is added, these tags will change to contain Python 3.12). This is a change from Nautobot 1.6.0 and earlier, where tags that did not state a Python version would contain the <strong>earliest</strong> supported Python version.</p>
-</details>
 <p>Currently images are pushed for the following Python versions:</p>
 <ul>
 <li>3.9</li>
@@ -9619,14 +9615,6 @@
 <li>3.12</li>
 </ul>
 <details class="version-added">
-<summary>Added in version 1.6.0 — Added Python 3.11</summary>
-<p>Python 3.11 was added to the set of published images.</p>
-</details>
-<details class="version-removed">
-<summary>Removed in version 1.6.0 — Removed Python 3.7</summary>
-<p>Python 3.7 was removed from the set of published images as Python 3.7 is now end-of-life.</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.3.0 — Added Python 3.12</summary>
 <p>Python 3.12 was added to the set of published images and is now the default version.</p>
 </details>
@@ -9802,9 +9790,6 @@
 <h3 id="uwsgi">uWSGI<a class="headerlink" href="#uwsgi" title="Permanent link">&para;</a></h3>
 <p>The docker container uses <a href="https://uwsgi-docs.readthedocs.io/">uWSGI</a> to serve Nautobot. A default configuration is <a href="https://github.com/nautobot/nautobot/blob/main/docker/uwsgi.ini">provided</a>, and can be overridden by injecting a new <code>uwsgi.ini</code> file at <code>/opt/nautobot/uwsgi.ini</code>. There are a couple of environment variables provided to override some uWSGI defaults:</p>
 <h4 id="nautobot_uwsgi_buffer_size"><code>NAUTOBOT_UWSGI_BUFFER_SIZE</code><a class="headerlink" href="#nautobot_uwsgi_buffer_size" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.3.9</summary>
-</details>
 <p>Default: <code>4096</code></p>
 <p>Max: <code>65535</code></p>
 <p>The max size of non-body request payload, roughly the size of request headers for uWSGI. Request headers that might contain lengthy query parameters, for example GraphQL or Relationship filtered lookups, might go well over the default limit. Increasing this limit will have an impact on running memory usage. Please see <a href="https://uwsgi-docs.readthedocs.io/en/latest/Options.html?highlight=buffer-size#buffer-size">the uWSGI documentation</a> for more information.</p>

nautobot/project-static/docs/user-guide/administration/installation/index.html

@@ -9374,18 +9374,6 @@
 <h4 id="python">Python<a class="headerlink" href="#python" title="Permanent link">&para;</a></h4>
 <p>Nautobot is written in the <a href="https://www.python.org/">Python programming language</a>. The official Python package installer is called <a href="https://pip.pypa.io/en/stable/">Pip</a>, and you will see the <code>pip</code> command referenced often to install or update Python packages.</p>
 <details class="version-added">
-<summary>Added in version 1.3.0 — Python 3.10 support added</summary>
-<p>Python 3.10 support was added.</p>
-</details>
-<details class="version-removed">
-<summary>Removed in version 1.3.0 — Python 3.6 support removed</summary>
-<p>Python 3.6 support was removed.</p>
-</details>
-<details class="version-changed">
-<summary>Changed in version 1.6.0 — Python 3.11 support added, Python 3.7 support removed</summary>
-<p>Python 3.11 support was added and Python 3.7 support was removed.</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.3.0 — Python 3.12 support added</summary>
 <p>Python 3.12 support was added.</p>
 </details>
@@ -9395,10 +9383,6 @@
 </details>
 <h4 id="database">Database<a class="headerlink" href="#database" title="Permanent link">&para;</a></h4>
 <p>Nautobot uses a relational database to store its data. Both MySQL and PostgreSQL are officially supported.</p>
-<details class="version-added">
-<summary>Added in version 1.1.0 — MySQL support added</summary>
-<p>MySQL support was added.</p>
-</details>
 <details class="version-removed">
 <summary>Removed in version 2.1.0 — PostgreSQL minimum version became 12.0</summary>
 <p>Support for versions of PostgreSQL older than 12.0 was removed.</p>

nautobot/project-static/docs/user-guide/administration/installation/nautobot.html

@@ -9683,10 +9683,7 @@
 <a id="__codelineno-20-2" name="__codelineno-20-2" href="#__codelineno-20-2"></a>Configuration file created at /opt/nautobot/nautobot_config.py
 </code></pre></div>
 </details>
-<details class="version-added">
-<summary>Added in version 1.6.0 — Installation metrics selection</summary>
-<p>The <code>nautobot-server init</code> command will now prompt you to set the initial value for the <a href="../configuration/settings.html#installation_metrics_enabled"><code>INSTALLATION_METRICS_ENABLED</code></a> setting. See the <a href="../tools/nautobot-server.html#send_installation_metrics"><code>send_installation_metrics</code></a> command for more information about the feature that this setting toggles.</p>
-</details>
+<p>The <code>nautobot-server init</code> command will prompt you to set the initial value for the <a href="../configuration/settings.html#installation_metrics_enabled"><code>INSTALLATION_METRICS_ENABLED</code></a> setting. See the <a href="../tools/nautobot-server.html#send_installation_metrics"><code>send_installation_metrics</code></a> command for more information about the feature that this setting toggles.</p>
 <h3 id="required-settings">Required Settings<a class="headerlink" href="#required-settings" title="Permanent link">&para;</a></h3>
 <p>Your <code>nautobot_config.py</code> provides sane defaults for most configuration settings, but in the longer term, you will inevitably need to update the settings for your environment. For a more complete guide to supported configuration settings in Nautobot, you can refer to <a href="../configuration/settings.html">Settings</a> later.</p>
 <div class="admonition tip">

nautobot/project-static/docs/user-guide/administration/installation/services.html

@@ -9539,10 +9539,6 @@
 <p>Nautobot requires at least one worker to consume background tasks required for advanced background features. A <code>nautobot-server celery</code> command is included that directly invokes Celery. This command behaves exactly as the Celery command-line utility does, but launches it through Nautobot's environment to share Redis and database connection settings transparently.</p>
 <div class="highlight"><span class="filename">Show help for the Nautobot worker service</span><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>nautobot-server celery --help
 </code></pre></div>
-<details class="version-changed">
-<summary>Changed in version 1.1.0 — Celery added to Nautobot</summary>
-<p>Prior to version 1.1.0, Nautobot utilized RQ as the primary background task worker. As of Nautobot 1.1.0, RQ is now <em>deprecated</em>. RQ and the <code>@job</code> decorator for custom tasks were still supported for the remainder of the 1.x.y releases, but users should <a href="#migrating-to-celery-from-rq">migrate the primary worker to Celery</a>.</p>
-</details>
 <details class="version-removed">
 <summary>Removed in version 2.0.0 — RQ removed from Nautobot</summary>
 <p>Support for RQ has been completely removed from Nautobot.</p>
@@ -9677,10 +9673,6 @@ documentation</a> for the available configuration parameters.</p>
 <h3 id="nautobot-background-services">Nautobot Background Services<a class="headerlink" href="#nautobot-background-services" title="Permanent link">&para;</a></h3>
 <p>Next, we will setup the <code>systemd</code> units for the Celery worker and Celery Beat scheduler.</p>
 <h4 id="celery-worker">Celery Worker<a class="headerlink" href="#celery-worker" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.1.0 — Celery added to Nautobot</summary>
-<p>Prior to version 1.1.0, Nautobot utilized RQ as the primary background task worker. As of Nautobot 1.1.0, RQ is now <em>deprecated</em> and has been replaced with Celery. RQ and the <code>@job</code> decorator for custom tasks were still supported for the remainder of the 1.x.y releases, but users should <a href="#migrating-to-celery-from-rq">migrate the primary worker to Celery</a>.</p>
-</details>
 <p>The Celery worker service consumes tasks from background task queues and is required for taking advantage of advanced
 Nautobot features including <a href="../../platform-functionality/jobs/index.html">Jobs</a>, <a href="../../platform-functionality/customfield.html">Custom
 Fields</a>, and <a href="../../platform-functionality/gitrepository.html">Git Repositories</a>, among others.</p>
@@ -9722,9 +9714,6 @@ Fields</a>, and <a href="../../platform-functionality/gitrepository.html">Git Re
 <a id="__codelineno-10-23" name="__codelineno-10-23" href="#__codelineno-10-23"></a><span class="na">WantedBy</span><span class="o">=</span><span class="s">multi-user.target</span>
 </code></pre></div>
 <h4 id="celery-beat-scheduler">Celery Beat Scheduler<a class="headerlink" href="#celery-beat-scheduler" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.2.0 — Celery Beat added to Nautobot</summary>
-</details>
 <p>The Celery Beat scheduler enables the periodic execution of and scheduling of background tasks. It is required to take advantage of the <a href="../../platform-functionality/jobs/job-scheduling-and-approvals.html">job scheduling and approval</a> features.</p>
 <div class="admonition warning">
 <p class="admonition-title">Warning</p>

nautobot/project-static/docs/user-guide/administration/migration/migrating-from-postgresql.html

@@ -9308,14 +9308,14 @@
 <a id="__codelineno-0-5" name="__codelineno-0-5" href="#__codelineno-0-5"></a>    --traceback \
 <a id="__codelineno-0-6" name="__codelineno-0-6" href="#__codelineno-0-6"></a>    &gt; nautobot_dump.json
 </code></pre></div>
-<details class="version-changed">
-<summary>Changed in version 1.5.23</summary>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
 <ul>
 <li>We do not recommend at this time using <code>--natural-primary</code> as this can result in inconsistent or incorrect data for data models that use GenericForeignKeys, such as <code>Cable</code>, <code>Note</code>, <code>ObjectChange</code>, and <code>Tag</code>.</li>
 <li>We also do not recommend at this time using <code>--natural-foreign</code> as it can potentially result in errors if any data models incorrectly implement their <code>natural_key()</code> and/or <code>get_by_natural_key()</code> API methods.</li>
 <li><code>contenttypes</code> must not be excluded from the dump (it could be excluded previously due to the use of <code>--natural-foreign</code>).</li>
 </ul>
-</details>
+</div>
 <div class="admonition warning">
 <p class="admonition-title">Warning</p>
 <p>Because of the different SQL dialects used by PostgreSQL and MySQL, Django's JSON database dump format is being used as the go-between for migrating your database contents from the one system to the other. This is a different case than general database backup and recovery; for best practices there, please refer to <a href="../upgrading/database-backup.html">Database Backup</a>.</p>

nautobot/project-static/docs/user-guide/administration/tools/nautobot-server.html

@@ -9892,21 +9892,14 @@
 <p>This is a built-in Django command. Please see the <a href="https://docs.djangoproject.com/en/stable/ref/django-admin/#dbshell">official documentation on <code>dbshell</code></a> for more information.</p>
 </div>
 <h3 id="dumpdata"><code>dumpdata</code><a class="headerlink" href="#dumpdata" title="Permanent link">&para;</a></h3>
-<details class="version-changed">
-<summary>Changed in version 1.3.0</summary>
-<ul>
-<li><code>extras.job</code> should now be included in the dump (removed <code>--exclude extras.job</code> from the example usage)</li>
-<li><code>django_rq</code> should now be excluded from the dump (added <code>--exclude django_rq</code> to the example usage)</li>
-</ul>
-</details>
-<details class="version-changed">
-<summary>Changed in version 1.5.23</summary>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
 <ul>
-<li>We do not recommend at this time using <code>--natural-primary</code> as this can result in inconsistent or incorrect data for data models that use GenericForeignKeys, such as <code>Cable</code>, <code>Note</code>, <code>ObjectChange</code>, and <code>Tag</code>.</li>
-<li>We also do not recommend at this time using <code>--natural-foreign</code> as it can potentially result in errors if any data models incorrectly implement their <code>natural_key()</code> and/or <code>get_by_natural_key()</code> API methods.</li>
+<li>We do not recommend using <code>--natural-primary</code> as this can result in inconsistent or incorrect data for data models that use GenericForeignKeys, such as <code>Cable</code>, <code>Note</code>, <code>ObjectChange</code>, and <code>Tag</code>.</li>
+<li>We also do not recommend using <code>--natural-foreign</code> as it can potentially result in errors if any data models incorrectly implement their <code>natural_key()</code> and/or <code>get_by_natural_key()</code> API methods.</li>
 <li><code>contenttypes</code> must not be excluded from the dump (it could be excluded previously due to the use of <code>--natural-foreign</code>).</li>
 </ul>
-</details>
+</div>
 <details class="version-changed">
 <summary>Changed in version 2.0.0</summary>
 <ul>
@@ -9957,9 +9950,6 @@
 <div class="highlight"><pre><span></span><code><a id="__codelineno-22-1" name="__codelineno-22-1" href="#__codelineno-22-1"></a>e!j=vrlhz-!wl8p_3+q5s5cph29nzj$xm81eap-!&amp;n!_9^du09
 </code></pre></div>
 <h3 id="generate_test_data"><code>generate_test_data</code><a class="headerlink" href="#generate_test_data" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <p><code>nautobot-server generate_test_data [--flush] --seed SEED</code></p>
 <p>Populate the database with various data as a baseline for testing (automated or manual).</p>
 <p><code>--flush</code><br />
@@ -10010,10 +10000,6 @@ String to use as a random generator seed for reproducible results.</p>
 <a id="__codelineno-28-4" name="__codelineno-28-4" href="#__codelineno-28-4"></a>Installation metrics will be sent when running &#39;nautobot-server post_upgrade&#39;. Thank you!
 <a id="__codelineno-28-5" name="__codelineno-28-5" href="#__codelineno-28-5"></a>Configuration file created at /home/example/.nautobot/nautobot_config.py
 </code></pre></div>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-<p>The <code>nautobot-server init</code> command will now prompt you to set the initial value for the <a href="../configuration/settings.html#installation_metrics_enabled"><code>INSTALLATION_METRICS_ENABLED</code></a> setting. See the <a href="#send_installation_metrics"><code>send_installation_metrics</code></a> command for more information about the feature that this setting toggles.</p>
-</details>
 <p>For more information on configuring Nautobot for the first time or on more advanced configuration patterns, please see the guide on <a href="../configuration/index.html">Nautobot Configuration</a>.</p>
 <h3 id="loaddata"><code>loaddata</code><a class="headerlink" href="#loaddata" title="Permanent link">&para;</a></h3>
 <p><code>nautobot-server loaddata --traceback nautobot_dump.json</code></p>
@@ -10081,10 +10067,6 @@ String to use as a random generator seed for reproducible results.</p>
 <p><code>nautobot-server post_upgrade</code></p>
 <p>Performs common server post-upgrade operations using a single entrypoint.</p>
 <p>This will run the following management commands with default settings, in order:</p>
-<details class="version-changed">
-<summary>Changed in version 1.6.0</summary>
-<p>Added the <a href="#send_installation_metrics"><code>send_installation_metrics</code></a> command to the list of commands run by <code>post_upgrade</code>.</p>
-</details>
 <ul>
 <li><code>migrate</code></li>
 <li><code>trace_paths</code></li>
@@ -10161,21 +10143,12 @@ Do not automatically refresh the dynamic group member lists.</p>
 <a id="__codelineno-34-23" name="__codelineno-34-23" href="#__codelineno-34-23"></a>Removing expired sessions...
 </code></pre></div>
 <h3 id="refresh_dynamic_group_member_caches"><code>refresh_dynamic_group_member_caches</code><a class="headerlink" href="#refresh_dynamic_group_member_caches" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-</details>
 <p><code>nautobot-server refresh_dynamic_group_member_caches</code></p>
 <p>Refresh the cached members of all Dynamic Groups. This can also be achieved by running the <code>Refresh Dynamic Group Caches</code> system Job.</p>
 <h3 id="refresh_content_type_caches"><code>refresh_content_type_caches</code><a class="headerlink" href="#refresh_content_type_caches" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-</details>
 <p><code>nautobot-server refresh_content_type_caches</code></p>
 <p>Refresh the cached ContentType object property available via <code>Model._content_type_cached</code>. If content types are added or removed, this command will update the cache to reflect the current state of the database, but should already be done through the <code>post_upgrade</code> command.</p>
 <h3 id="remove_stale_scheduled_jobs"><code>remove_stale_scheduled_jobs</code><a class="headerlink" href="#remove_stale_scheduled_jobs" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.3.10</summary>
-</details>
 <p><code>nautobot-server remove_stale_scheduled_jobs [max-age of days]</code></p>
 <p>Delete non-recurring scheduled jobs that were scheduled to run more than <code>max-age</code> days ago.</p>
 <h3 id="renaturalize"><code>renaturalize</code><a class="headerlink" href="#renaturalize" title="Permanent link">&para;</a></h3>
@@ -10231,9 +10204,6 @@ JSON string that populates the <code>data</code> variable of the job.</p>
 </code></pre></div>
 <p>Please see the <a href="../../platform-functionality/jobs/index.html">guide on Jobs</a> for more information on working with and running jobs.</p>
 <h3 id="send_installation_metrics"><code>send_installation_metrics</code><a class="headerlink" href="#send_installation_metrics" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-</details>
 <p><code>nautobot-server send_installation_metrics</code></p>
 <p>Send anonymized installation metrics to the Nautobot maintainers. This management command is called by <a href="#post_upgrade"><code>post_upgrade</code></a> and is not intended to be run manually.</p>
 <p>If the <a href="../configuration/settings.html#installation_metrics_enabled"><code>INSTALLATION_METRICS_ENABLED</code></a> setting is <code>True</code>, this command will send a list of all installed <a href="../../../development/apps/index.html">Apps</a> and their versions, as well as the currently installed Nautobot and Python versions, to the Nautobot maintainers. A randomized UUID will be generated and saved in the <a href="../configuration/settings.html#deployment_id"><code>DEPLOYMENT_ID</code></a> setting to anonymously but uniquely identify this installation. The App names will be one-way hashed with SHA256 to further anonymize the data sent. This enables tracking the installation metrics of publicly released apps without disclosing the names of any private apps.</p>

nautobot/project-static/docs/user-guide/administration/upgrading/from-v1/tables/v2-code-location-changes.yaml

@@ -135,7 +135,7 @@
   Class/Function(s): "dynamic_import"
   New Module: "nautobot.core.api.utils"
 - Old Module: "nautobot.utilities.utils"
-  Class/Function(s): "ensure_content_type_and_field_name_inquery_params"
+  Class/Function(s): "ensure_content_type_and_field_name_in_query_params"
   New Module: "nautobot.core.utils.requests"
 - Old Module: "nautobot.utilities.utils"
   Class/Function(s): "flatten_dict"

nautobot/project-static/docs/user-guide/administration/upgrading/from-v1/upgrading-from-nautobot-v1.html

@@ -13948,7 +13948,7 @@ Most removed database fields in Nautobot 2.0 fall into the following general cat
 </tr>
 <tr>
 <td>nautobot.utilities.utils</td>
-<td>ensure_content_type_and_field_name_inquery_params</td>
+<td>ensure_content_type_and_field_name_in_query_params</td>
 <td>nautobot.core.utils.requests</td>
 </tr>
 <tr>

nautobot/project-static/docs/user-guide/administration/upgrading/upgrading.html

@@ -9479,10 +9479,6 @@ release notes under the release in which the change went into effect.</p>
 </tbody>
 </table>
 <details class="version-removed">
-<summary>Removed in version 1.6.0</summary>
-<p>Support for Python 3.7 was removed.</p>
-</details>
-<details class="version-removed">
 <summary>Removed in version 2.1.0</summary>
 <p>Support for versions of PostgreSQL older than 12.0 was removed.</p>
 </details>

nautobot/project-static/docs/user-guide/core-data-model/circuits/providernetwork.html

@@ -9122,9 +9122,6 @@
 
 
 <h1 id="provider-network">Provider Network<a class="headerlink" href="#provider-network" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>A provider network represents an abstract portion of network topology, just like in a topology diagram. For example, a provider network may be used to represent a provider's MPLS network.</p>
 <p>Each provider network must be assigned to a provider. A circuit may terminate to either a provider network or to a valid location.</p>
 

nautobot/project-static/docs/user-guide/core-data-model/dcim/consoleport.html

@@ -9136,10 +9136,6 @@
 <h1 id="console-ports">Console Ports<a class="headerlink" href="#console-ports" title="Permanent link">&para;</a></h1>
 <p>A console port provides connectivity to the physical console of a device. These are typically used for temporary access by someone who is physically near the device, or for remote out-of-band access provided via a networked console server. Each console port may be assigned a physical type.</p>
 <p>Cables can connect console ports to console server ports or pass-through ports.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a>. As a result, there are now two fields for assignment to a Device or Module. One of the <code>device</code> or <code>module</code> fields must be populated but not both. If a <code>module</code> is supplied, the <code>device</code> field must be null, and similarly the <code>module</code> field must be null if a <code>device</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/consoleporttemplate.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="console-port-templates">Console Port Templates<a class="headerlink" href="#console-port-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a console port that will be created on all instantiations of the parent device type. Each console port can be assigned a physical type.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a> through the <a href="moduletype.html">ModuleType</a> model. As a result, there are now two fields for assignment to a DeviceType or ModuleType. One of the <code>device_type</code> or <code>module_type</code> fields must be populated but not both. If a <code>module_type</code> is supplied, the <code>device_type</code> field must be null, and similarly the <code>module_type</code> field must be null if a <code>device_type</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/consoleserverport.html

@@ -9136,10 +9136,6 @@
 <h1 id="console-server-ports">Console Server Ports<a class="headerlink" href="#console-server-ports" title="Permanent link">&para;</a></h1>
 <p>A console server is a device which provides remote access to the local consoles of connected devices. They are typically used to provide remote out-of-band access to network devices. Each console server port may be assigned a physical type.</p>
 <p>Cables can connect console server ports to console ports or pass-through ports.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a>. As a result, there are now two fields for assignment to a Device or Module. One of the <code>device</code> or <code>module</code> fields must be populated but not both. If a <code>module</code> is supplied, the <code>device</code> field must be null, and similarly the <code>module</code> field must be null if a <code>device</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/consoleserverporttemplate.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="console-server-port-templates">Console Server Port Templates<a class="headerlink" href="#console-server-port-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a console server port that will be created on all instantiations of the parent device type. Each console server port can be assigned a physical type.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a> through the <a href="moduletype.html">ModuleType</a> model. As a result, there are now two fields for assignment to a DeviceType or ModuleType. One of the <code>device_type</code> or <code>module_type</code> fields must be populated but not both. If a <code>module_type</code> is supplied, the <code>device_type</code> field must be null, and similarly the <code>module_type</code> field must be null if a <code>device_type</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/devicebay.html

@@ -9130,10 +9130,6 @@
 <summary>Changed in version 2.3.0</summary>
 <p>Device bays are <strong>not</strong> suitable for modeling line cards (such as those commonly found in chassis-based routers and switches), as these components depend on the control plane of the parent device to operate. Previously, it was recommended that line cards and similarly non-autonomous hardware should be modeled as inventory items within a device, but as of version 2.3.0 the <a href="module.html">Module</a> model should be used instead.</p>
 </details>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 
 
 

nautobot/project-static/docs/user-guide/core-data-model/dcim/devicebaytemplate.html

@@ -9125,10 +9125,6 @@
 
 <h1 id="device-bay-templates">Device Bay Templates<a class="headerlink" href="#device-bay-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a device bay that will be created on all instantiations of the parent device type.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 
 
 

nautobot/project-static/docs/user-guide/core-data-model/dcim/deviceredundancygroup.html

@@ -9328,9 +9328,6 @@
 
 
 <h1 id="device-redundancy-groups">Device Redundancy Groups<a class="headerlink" href="#device-redundancy-groups" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <p>Device Redundancy Groups represent logical relationships between multiple devices. Typically, a redundancy group could represent a failover pair, failover group, or a load sharing cluster.
 Device Redundancy Groups are created first, before the devices are assigned to the group.</p>
 <p>A failover strategy represents intended operation mode of the group. Supported failover strategy are: Active/Active and Active/Standby.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/devicetype.html

@@ -9144,10 +9144,6 @@
 <p>This parent/child relationship is <strong>not</strong> suitable for modeling chassis-based devices, wherein child members share a common control plane. Instead, line cards and similarly non-autonomous hardware should be modeled as inventory items within a device, with any associated interfaces or other components assigned directly to the device.</p>
 </div>
 <h2 id="device-component-templates">Device Component Templates<a class="headerlink" href="#device-component-templates" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <p>Each device type is assigned a number of component templates which define the physical components within a device. These are:</p>
 <ul>
 <li>Console ports</li>

nautobot/project-static/docs/user-guide/core-data-model/dcim/frontport.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="front-ports">Front Ports<a class="headerlink" href="#front-ports" title="Permanent link">&para;</a></h1>
 <p>Front ports are pass-through ports used to represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in Nautobot as front ports. Each port is assigned a physical type, and must be mapped to a specific rear port on the same device. A single rear port may be mapped to multiple rear ports, using numeric positions to annotate the specific alignment of each.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a>. As a result, there are now two fields for assignment to a Device or Module. One of the <code>device</code> or <code>module</code> fields must be populated but not both. If a <code>module</code> is supplied, the <code>device</code> field must be null, and similarly the <code>module</code> field must be null if a <code>device</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/frontporttemplate.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="front-port-templates">Front Port Templates<a class="headerlink" href="#front-port-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a front-facing pass-through port that will be created on all instantiations of the parent device type. Front ports may have a physical type assigned, and must be associated with a corresponding rear port and position. This association will be automatically replicated when the device type is instantiated.</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a> through the <a href="moduletype.html">ModuleType</a> model. As a result, there are now two fields for assignment to a DeviceType or ModuleType. One of the <code>device_type</code> or <code>module_type</code> fields must be populated but not both. If a <code>module_type</code> is supplied, the <code>device_type</code> field must be null, and similarly the <code>module_type</code> field must be null if a <code>device_type</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/interface.html

@@ -9143,16 +9143,8 @@
 <li>Decommissioning</li>
 <li>Failed</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-<ul>
-<li>Added <code>bridge</code> field.</li>
-<li>Added <code>parent_interface</code> field.</li>
-<li>Added <code>status</code> field.</li>
-</ul>
-</details>
 <p>Interfaces may be physical or virtual in nature, but only physical interfaces may be connected via cables. Cables can connect interfaces to pass-through ports, circuit terminations, or other interfaces.</p>
-<p>Physical interfaces may be arranged into a link aggregation group (LAG) and associated with a parent LAG (virtual) interface. LAG interfaces can be recursively nested to model bonding of trunk groups. Like all virtual interfaces, LAG interfaces cannot be connected physically.</p>
+<p>Physical interfaces may be arranged into a link aggregation group (LAG) and associated with a parent LAG (virtual) interface. LAG interfaces can be recursively nested to model bonding of trunk groups. Like all virtual interfaces, LAG interfaces cannot be connected physically. Interfaces can be assigned to an <a href="interfaceredundancygroup.html">Interface Redundancy Group</a> to represent redundancy protocols such as HSRP or VRRP.</p>
 <details class="version-changed">
 <summary>Changed in version 2.0.0</summary>
 <p>The relationship to IP addresses has been changed to a many-to-many relationship. This allows an IP address to be assigned to multiple interfaces, and an interface to have multiple IP addresses assigned to it.</p>
@@ -9163,14 +9155,6 @@
 <p>Although devices and virtual machines both can have interfaces, a separate model is used for each. Thus, device interfaces have some properties that are not present on virtual machine interfaces and vice versa.</p>
 </div>
 <details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-<p>Interfaces can now be assigned to an <a href="interfaceredundancygroup.html">Interface Redundancy Group</a> to represent redundancy protocols such as HSRP or VRRP.</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.3.0</summary>
 <p>Interfaces now have an optional <code>role</code> field and can be assigned <a href="../../platform-functionality/role.html">Role</a> instances to track common configurations.</p>
 </details>

nautobot/project-static/docs/user-guide/core-data-model/dcim/interfaceredundancygroup.html

@@ -9196,9 +9196,6 @@
 
 
 <h1 id="interface-redundancy-groups">Interface Redundancy Groups<a class="headerlink" href="#interface-redundancy-groups" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-</details>
 <p>Interface Redundancy Groups represent groups of interfaces that share a single virtual address. This model is intended to represent redundancy protocols such as HSRP or VRRP that allow multiple devices to provide a fault-tolerant default gateway for a network.</p>
 <p>Interface Redundancy Groups must be created before interfaces can be assigned to the group.</p>
 <div class="admonition note">

nautobot/project-static/docs/user-guide/core-data-model/dcim/interfacetemplate.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="interface-templates">Interface Templates<a class="headerlink" href="#interface-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a network interface that will be created on all instantiations of the parent device type or module type. Each interface may be assigned a physical or virtual type, and may be designated as "management-only."</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a> through the <a href="moduletype.html">ModuleType</a> model. As a result, there are now two fields for assignment to a DeviceType or ModuleType. One of the <code>device_type</code> or <code>module_type</code> fields must be populated but not both. If a <code>module_type</code> is supplied, the <code>device_type</code> field must be null, and similarly the <code>module_type</code> field must be null if a <code>device_type</code> is supplied.</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/inventoryitem.html

@@ -9142,10 +9142,6 @@
 <p>Unless a specific use case is identified for inventory items, they are likely to be completely replaced by <a href="module.html">Modules</a> and removed in a future release of Nautobot.</p>
 </div>
 <details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.2.0</summary>
 <p>The <a href="softwareversion.html">Software Version</a> model has been introduced to represent the software version that is currently installed on an inventory item. An optional software version field has been added to inventory items.</p>
 </details>

nautobot/project-static/docs/user-guide/core-data-model/dcim/location.html

@@ -9122,9 +9122,6 @@
 
 
 <h1 id="locations">Locations<a class="headerlink" href="#locations" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>To locate network information more precisely than a Site defines, you can define a hierarchy of Locations within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to a specific building, wing, floor, room, etc. as appropriate to your needs.</p>
 <p>Once you have defined the hierarchy of Location Types that you wish to use, you can then define Locations. Any "top-level" Locations (those whose Location Type has no parent) belong directly to a Site, while "child" Locations belong to their immediate parent Location, rather than to the Site as a whole.</p>
 <div class="admonition info">

nautobot/project-static/docs/user-guide/core-data-model/dcim/locationtype.html

@@ -9122,14 +9122,9 @@
 
 
 <h1 id="location-types">Location Types<a class="headerlink" href="#location-types" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>Before defining individual Locations, you must first define the hierarchy of Location Types that you wish to use for the organization of your network. An example hierarchy might be <code>Building ← Floor ← Room</code>, but you might have more or fewer distinct types depending on your specific organizational requirements.</p>
 <p>Each Location Type can define a set of "content types" that are permitted to associate to Locations of this type. For example, you might permit assigning Prefixes and VLAN Groups to an entire Building or Floor, but only allow Devices and Racks to be assigned to Rooms, never to a more abstract location. Doing so can help ensure consistency of your data.</p>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-<p>Location Types can now be marked as <code>nestable</code>. When this flag is set, Locations of this type may nest within one another, allowing for variable-depth hierarchies of Locations and reducing the number of distinct Location Types you may need to define. For example, with two Location Types, "Building Group" and "Building", by flagging "Building Group" as nestable, you could model the following hierarchy of Locations:</p>
+<p>Location Types can be marked as <code>nestable</code>. When this flag is set, Locations of this type may nest within one another, allowing for variable-depth hierarchies of Locations and reducing the number of distinct Location Types you may need to define. For example, with two Location Types, "Building Group" and "Building", by flagging "Building Group" as nestable, you could model the following hierarchy of Locations:</p>
 <ul>
 <li>Main Campus (Building Group)<ul>
 <li>West Campus (Building Group)<ul>
@@ -9160,7 +9155,6 @@
 </ul>
 </li>
 </ul>
-</details>
 <div class="admonition tip">
 <p class="admonition-title">Tip</p>
 <p>Although it is possible to define a "tree" of Location Types with multiple "branches", in the majority of cases doing so adds more unnecessary complexity than it's worth. Consider the following hypothetical Location Type tree:</p>

nautobot/project-static/docs/user-guide/core-data-model/dcim/platform.html

@@ -9126,10 +9126,6 @@
 <p>Platforms may optionally be limited by manufacturer: If a platform is assigned to a particular manufacturer, it can only be assigned to devices with a type belonging to that manufacturer.</p>
 <p>The platform model can be used to indicate which "network driver" Nautobot (and Jobs, Apps, etc.) should use when connecting to a remote device running this platform. This is a generic string corresponding loosely to a <a href="https://github.com/ktbyers/netmiko">Netmiko</a> driver name. As there are many different libraries and applications for connecting to a device, rather than having a separate model field for each such connection type, Nautobot uses <a href="https://netutils.readthedocs.io/en/latest/">netutils</a> to translate the generic network driver string into a variety of library-specific driver strings (Ansible "collection name", PyATS "OS" value, Scrapli "platform", etc.) which can be accessed via the UI, REST API, and GraphQL as needed. An administrator can extend or override the default translations provided by netutils by configuring the <a href="../../administration/configuration/settings.html#network_drivers"><code>NETWORK_DRIVERS</code></a> dictionary appropriately. (If your extensions are generally applicable, please consider making a pull request against <a href="https://github.com/networktocode/netutils">netutils</a> to update the package!)</p>
 <details class="version-added">
-<summary>Added in version 1.6.0</summary>
-<p>The <code>network_driver</code> database field and the <code>network_driver_mappings</code> derived property were added to the Platform data model. Support for the <code>NETWORK_DRIVERS</code> setting was added.</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.0.0</summary>
 <p>Support for <code>netutils_parser</code> key was added to <code>network_driver_mappings</code>.</p>
 </details>

nautobot/project-static/docs/user-guide/core-data-model/dcim/poweroutlet.html

@@ -9232,10 +9232,6 @@
 <p>Power outlets represent the outlets on a power distribution unit (PDU) or other device that supply power to dependent devices. Each power port may be assigned a physical type, and may be associated with a specific feed leg (where three-phase power is used) and/or a specific upstream power port. This association can be used to model the distribution of power within a device.</p>
 <p>For example, imagine a PDU with one power port which draws from a three-phase feed and 48 power outlets arranged into three banks of 16 outlets each. Outlets 1-16 would be associated with leg A on the port, and outlets 17-32 and 33-48 would be associated with legs B and C, respectively.</p>
 <p>Cables can connect power outlets only to downstream power ports. (Pass-through ports cannot be used to model power distribution.)</p>
-<details class="version-added">
-<summary>Added in version 1.4.5</summary>
-<p>The fields <code>created</code> and <code>last_updated</code> were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to <code>None</code> (null).</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>This model has been updated to support being installed in <a href="module.html">Modules</a>. As a result, there are now two fields for assignment to a Device or Module. One of the <code>device</code> or <code>module</code> fields must be populated but not both. If a <code>module</code> is supplied, the <code>device</code> field must be null, and similarly the <code>module</code> field must be null if a <code>device</code> is supplied.</p>