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

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/tools/nautobot-shell.html

@@ -9265,7 +9265,7 @@
 <p>Nautobot includes a Python management shell within which objects can be directly queried, created, modified, and deleted. To enter the shell, run the following command:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>nautobot-server nbshell
 </code></pre></div>
-<p>This will launch a lightly customized version of <a href="https://django-extensions.readthedocs.io/en/latest/shell_plus.html">the django-extensions <code>shell_plus</code> shell</a>, which is an extension of <a href="https://docs.djangoproject.com/en/stable/ref/django-admin/#shell">the built-in Django shell</a> with all relevant Nautobot models pre-loaded.</p>
+<p>This will launch a lightly customized version of <a href="https://django-extensions.readthedocs.io/en/latest/shell_plus.html">the <code>django-extensions</code> <code>shell_plus</code> shell</a>, which is an extension of <a href="https://docs.djangoproject.com/en/stable/ref/django-admin/#shell">the built-in Django shell</a> with all relevant Nautobot models pre-loaded.</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>nautobot-server nbshell
 </code></pre></div>
 <p>Example output:</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>
@@ -14418,15 +14418,18 @@ Most removed database fields in Nautobot 2.0 fall into the following general cat
 <p>With the removal of the atomic transaction, the <code>commit</code> flag has been removed. The ability to bypass job approval on dryrun can be achieved by using an optional <code>dryrun</code> argument. Job authors who wish to allow users to bypass approval when the <code>dryrun</code> flag is set should set a <code>dryrun</code> attribute with a value of <code>DryRunVar()</code> on their job class. <code>DryRunVar</code> can be imported from <code>nautobot.extras.jobs</code>.</p>
 <div class="admonition example">
 <p class="admonition-title">Example</p>
-<div class="highlight"><pre><span></span><code><a id="__codelineno-13-1" name="__codelineno-13-1" href="#__codelineno-13-1"></a><span class="kn">from</span> <span class="nn">nautobot.extras.jobs</span> <span class="kn">import</span> <span class="n">DryRunVar</span><span class="p">,</span> <span class="n">Job</span>
-<a id="__codelineno-13-2" name="__codelineno-13-2" href="#__codelineno-13-2"></a>
-<a id="__codelineno-13-3" name="__codelineno-13-3" href="#__codelineno-13-3"></a><span class="k">class</span> <span class="nc">ExampleJob</span><span class="p">(</span><span class="n">Job</span><span class="p">):</span>
-<a id="__codelineno-13-4" name="__codelineno-13-4" href="#__codelineno-13-4"></a>    <span class="n">dryrun</span> <span class="o">=</span> <span class="n">DryRunVar</span><span class="p">()</span>
-<a id="__codelineno-13-5" name="__codelineno-13-5" href="#__codelineno-13-5"></a>
-<a id="__codelineno-13-6" name="__codelineno-13-6" href="#__codelineno-13-6"></a>    <span class="k">def</span> <span class="nf">run</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">dryrun</span><span class="p">):</span>
-<a id="__codelineno-13-7" name="__codelineno-13-7" href="#__codelineno-13-7"></a>        <span class="o">...</span>
-</code></pre></div>
 </div>
+<!-- pyml disable-num-lines 2 proper-names -->
+<div class="highlight"><pre><span></span><code>```py
+from nautobot.extras.jobs import DryRunVar, Job
+
+class ExampleJob(Job):
+    dryrun = DryRunVar()
+
+    def run(self, dryrun):
+        ...
+```
+</code></pre></div>
 <p>A new <code>supports_dryrun</code> field has been added to the <code>Job</code> model and <code>Job</code> class that returns true if the <code>Job</code> class implements the <code>dryrun = DryRunVar()</code> attribute. This is used to determine if jobs that require approval can be dry run without prior approval.</p>
 <p>The <code>commit_default</code> job field has been renamed to <code>dryrun_default</code> and the default value has been changed from <code>True</code> to <code>False</code>.</p>
 <div class="admonition important">

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>

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

@@ -9135,10 +9135,6 @@
 
 <h1 id="power-outlet-templates">Power Outlet Templates<a class="headerlink" href="#power-outlet-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a power outlet that will be created on all instantiations of the parent device type or module type. Each power outlet can be assigned a physical type, and its power source may be mapped to a specific feed leg and power port template. 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/powerport.html

@@ -9235,10 +9235,6 @@
 <p>When creating a power port on a device which supplies power to downstream devices, the allocated and maximum draw numbers should be left blank. Utilization will be calculated by taking the sum of all power ports of devices connected downstream.</p>
 </div>
 <p>Cables can connect power ports only to power outlets or power feeds. (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>

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

@@ -9135,10 +9135,6 @@
 
 <h1 id="power-port-templates">Power Port Templates<a class="headerlink" href="#power-port-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a power port that will be created on all instantiations of the parent device type or module type. Each power port can be assigned a physical type, as well as a maximum and allocated draw in watts.</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/rearport.html

@@ -9139,10 +9139,6 @@
 <p class="admonition-title">Note</p>
 <p>Front and rear ports need not necessarily reside on the actual front or rear device face. This terminology is used primarily to distinguish between the two components in a pass-through port pairing.</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-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/rearporttemplate.html

@@ -9135,10 +9135,6 @@
 
 <h1 id="rear-port-templates">Rear Port Templates<a class="headerlink" href="#rear-port-templates" title="Permanent link">&para;</a></h1>
 <p>A template for a rear-facing pass-through port that will be created on all instantiations of the parent device type or module type. Each rear port may have a physical type and one or more front port templates assigned to it. The number of positions associated with a rear port determines how many front ports can be assigned to it (the maximum is 1024).</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/extras/configcontext.html

@@ -9210,12 +9210,6 @@
 <li>Tag</li>
 <li>Dynamic group - Need to set <code>settings.CONFIG_CONTEXT_DYNAMIC_GROUPS_ENABLED</code> to <code>True</code>. <a href="../../administration/configuration/settings.html#config_context_dynamic_groups_enabled">See notes here</a></li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.5.0 — Added support for filtering by device redundancy group</summary>
-</details>
-<details class="version-added">
-<summary>Added in version 1.5.12 — Added support for filtering by dynamic group</summary>
-</details>
 <p>Context data not specifically assigned to one or more of the above groups is by default associated with <strong>all</strong> devices and virtual machines.</p>
 <p>Configuration contexts may be managed within Nautobot via the UI and/or API; they may also be managed externally to Nautobot in a Git repository if desired.</p>
 <h2 id="hierarchical-rendering">Hierarchical Rendering<a class="headerlink" href="#hierarchical-rendering" title="Permanent link">&para;</a></h2>

nautobot/project-static/docs/user-guide/core-data-model/extras/configcontextschema.html

@@ -9122,9 +9122,6 @@
 
 
 <h1 id="config-context-schemas">Config Context Schemas<a class="headerlink" href="#config-context-schemas" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.1.0</summary>
-</details>
 <p>While config contexts allow for arbitrary data structures to be stored within Nautobot, at scale it is desirable to apply validation constraints to that data to ensure its consistency and to avoid data entry errors. To service this need, Nautobot supports optionally backing config contexts with <a href="https://json-schema.org/">JSON Schemas</a> for validation. These schema are managed via the config context schema model and are optionally linked to config context instances, in addition to devices and virtual machines for the purpose of validating their local context data.</p>
 <p>A JSON Schema is capable of validating the structure, format, and type of your data, and acts as a form of documentation useful in a number of automation use cases.</p>
 <p>A config context is linked to a single schema object and thus they are meant to model individual units of the overall context. In this way, they validate each config context object, not the fully rendered context as viewed on a particular device or virtual machine.</p>

nautobot/project-static/docs/user-guide/core-data-model/ipam/ipaddress.html

@@ -9257,10 +9257,6 @@
 </details>
 <h2 id="network-address-translation-nat">Network Address Translation (NAT)<a class="headerlink" href="#network-address-translation-nat" title="Permanent link">&para;</a></h2>
 <p>An IP address can be designated as the network address translation (NAT) inside IP address for one or more other IP addresses. This is useful primarily to denote a translation between public and private IP addresses. This relationship is followed in both directions: For example, if 10.0.0.1 is assigned as the inside IP for 192.0.2.1, 192.0.2.1 will be displayed as the outside IP for 10.0.0.1.</p>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-<p>Support for multiple outside NAT IP addresses was added.</p>
-</details>
 <h2 id="ipaddress-parenting-concrete-relationship">IPAddress Parenting Concrete Relationship<a class="headerlink" href="#ipaddress-parenting-concrete-relationship" title="Permanent link">&para;</a></h2>
 <details class="version-added">
 <summary>Added in version 2.0.0</summary>

nautobot/project-static/docs/user-guide/core-data-model/ipam/vlan.html

@@ -9235,10 +9235,6 @@
 </ul>
 <p>As with prefixes, each VLAN may also be assigned a functional role. Prefixes and VLANs share the same set of customizable roles.</p>
 <details class="version-changed">
-<summary>Changed in version 1.5.9</summary>
-<p>The maximum <code>name</code> length was increased from 64 characters to 255 characters.</p>
-</details>
-<details class="version-changed">
 <summary>Changed in version 2.0.0</summary>
 <ul>
 <li>Renamed <code>group</code> field to <code>vlan_group</code>.</li>