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

nautobot/project-static/docs/user-guide/core-data-model/virtualization/vminterface.html

@@ -9131,14 +9131,6 @@
 <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>
 <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 VM interfaces, and a VM interface to have multiple IP addresses assigned to it.</p>

nautobot/project-static/docs/user-guide/feature-guides/custom-fields.html

@@ -2364,7 +2364,7 @@
           <li class="md-nav__item">
   <a href="#retrieve-custom-field-data-in-the-rest-api" class="md-nav__link">
     <span class="md-ellipsis">
-      Retrieve Custom Field Data in the Rest API
+      Retrieve Custom Field Data in the REST API
     </span>
   </a>
   
@@ -2439,7 +2439,7 @@
           <li class="md-nav__item">
   <a href="#modify-custom-field-data-in-the-rest-api" class="md-nav__link">
     <span class="md-ellipsis">
-      Modify Custom Field Data in the Rest API
+      Modify Custom Field Data in the REST API
     </span>
   </a>
   
@@ -9713,7 +9713,7 @@
           <li class="md-nav__item">
   <a href="#retrieve-custom-field-data-in-the-rest-api" class="md-nav__link">
     <span class="md-ellipsis">
-      Retrieve Custom Field Data in the Rest API
+      Retrieve Custom Field Data in the REST API
     </span>
   </a>
   
@@ -9788,7 +9788,7 @@
           <li class="md-nav__item">
   <a href="#modify-custom-field-data-in-the-rest-api" class="md-nav__link">
     <span class="md-ellipsis">
-      Modify Custom Field Data in the Rest API
+      Modify Custom Field Data in the REST API
     </span>
   </a>
   
@@ -9858,10 +9858,10 @@
 <p>The default value for a select or multi-select field must match one of the existing choices. If the desired default value is not in the list of choices, the choices must be updated and saved before the default can be changed. As a result of this behavior, default values cannot be set on select and multi-select fields when a custom field is created.</p>
 </div>
 <h4 id="filter-logic">Filter Logic<a class="headerlink" href="#filter-logic" title="Permanent link">&para;</a></h4>
-<details class="version-changed">
-<summary>Changed in version 1.4.0</summary>
+<div class="admonition tip">
+<p class="admonition-title">Tip</p>
 <p>Custom field <a href="../platform-functionality/rest-api/filtering.html#lookup-expressions">extended filtering</a> introduced extended lookup expression filters for <code>exact</code> and <code>icontains</code>, duplicating the functionality of both the <code>Strict</code> and <code>Loose</code> settings.</p>
-</details>
+</div>
 <p>The filter logic setting applies to filtering on custom fields in the UI and API. For example, when filtering in the API to find a device with the custom field <code>cf1</code> set to <code>"abc"</code> you would query <code>/api/dcim/devices/?cf_cf1=abc</code>. If the filter logic setting is set to <code>Loose</code> this would match on <code>"ABC"</code> and <code>"abcdef"</code>. If the filter logic setting is set to <code>Strict</code> only devices with the custom field set to exactly "abc" (case sensitive) would be returned. If the filter logic setting is set to <code>disabled</code>, no filters will be available for this custom field, including extended lookup filters. The <code>Loose</code> and <code>Strict</code> settings only change the behavior of the default filter (<code>cf_customfieldname</code>) on <code>text</code>, <code>url</code> and <code>json</code> custom fields.</p>
 <h4 id="move-to-advanced-tab">Move to Advanced Tab<a class="headerlink" href="#move-to-advanced-tab" title="Permanent link">&para;</a></h4>
 <p>When selected, the custom field will appear in the "Advanced" tab of the object detail view instead of the default tab.</p>
@@ -9879,7 +9879,7 @@
 <h4 id="maximum-value">Maximum value<a class="headerlink" href="#maximum-value" title="Permanent link">&para;</a></h4>
 <p>Maximum allowed value for <code>Integer</code> fields. Maximum allowed length for <code>Text</code>, <code>URL</code>, <code>JSON</code>, and <code>Markdown</code> fields. Maximum allowed length of each defined choice for a <code>Select</code> or <code>Multiple Selection</code> field.</p>
 <h4 id="validation-regex">Validation Regex<a class="headerlink" href="#validation-regex" title="Permanent link">&para;</a></h4>
-<p>Regular expression to enforce on <code>Text</code>, <code>URL</code>, <code>JSON</code>, <code>Markdown</code>, <code>Selection</code> and <code>Multiple selection</code> field values. Regex validation is handled by the <a href="https://docs.python.org/3/library/re.html">python re engine</a> which uses a PCRE or perl-like regular expression syntax. Examples of common regex validations:</p>
+<p>Regular expression to enforce on <code>Text</code>, <code>URL</code>, <code>JSON</code>, <code>Markdown</code>, <code>Selection</code> and <code>Multiple selection</code> field values. Regex validation is handled by the <a href="https://docs.python.org/3/library/re.html">Python <code>re</code> engine</a> which uses a PCRE or perl-like regular expression syntax. Examples of common regex validations:</p>
 <p>Must start with companyname</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>^companyname
 </code></pre></div>
@@ -9923,7 +9923,7 @@
 <a id="__codelineno-6-10" name="__codelineno-6-10" href="#__codelineno-6-10"></a><span class="s1">&#39;1970-01-01&#39;</span>
 </code></pre></div>
 <p>The <code>key</code> of the custom field is used as the key for the associated object's data dictionary.</p>
-<h3 id="retrieve-custom-field-data-in-the-rest-api">Retrieve Custom Field Data in the Rest API<a class="headerlink" href="#retrieve-custom-field-data-in-the-rest-api" title="Permanent link">&para;</a></h3>
+<h3 id="retrieve-custom-field-data-in-the-rest-api">Retrieve Custom Field Data in the REST API<a class="headerlink" href="#retrieve-custom-field-data-in-the-rest-api" title="Permanent link">&para;</a></h3>
 <p>Custom fields are returned in the API for all supported models in the <code>custom_fields</code> key:</p>
 <details class="info">
 <summary><code>GET http://localhost:8080/api/dcim/devices/ffd8df99-6d1a-41c3-b19f-b8357eefc481/</code></summary>
@@ -10006,7 +10006,7 @@
 </code></pre></div>
 </details>
 <h4 id="filter-queries-on-custom-field-data-in-graphql">Filter Queries on Custom Field Data in GraphQL<a class="headerlink" href="#filter-queries-on-custom-field-data-in-graphql" title="Permanent link">&para;</a></h4>
-<p>Queries can also be filtered by custom field values using any of the filters available in the UI and Rest API:</p>
+<p>Queries can also be filtered by custom field values using any of the filters available in the UI and REST API:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-12-1" name="__codelineno-12-1" href="#__codelineno-12-1"></a># Retrieve devices where custom field support_group
 <a id="__codelineno-12-2" name="__codelineno-12-2" href="#__codelineno-12-2"></a># does not contain &quot;Network Operations&quot; (case insensitive)
 <a id="__codelineno-12-3" name="__codelineno-12-3" href="#__codelineno-12-3"></a>{
@@ -10034,7 +10034,7 @@
 </details>
 <h2 id="modifying-custom-field-data">Modifying Custom Field Data<a class="headerlink" href="#modifying-custom-field-data" title="Permanent link">&para;</a></h2>
 <h3 id="modify-custom-field-data-in-nautobot-shell">Modify Custom Field Data in Nautobot Shell<a class="headerlink" href="#modify-custom-field-data-in-nautobot-shell" title="Permanent link">&para;</a></h3>
-<p>Custom field data behaves like a python dictionary in the Nautobot Shell. When modifying custom fields through the Nautobot Shell, make sure to use the <code>.validated_save()</code> method to save the object to ensure that custom field validation is performed.  Example:</p>
+<p>Custom field data behaves like a Python dictionary in the Nautobot Shell. When modifying custom fields through the Nautobot Shell, make sure to use the <code>.validated_save()</code> method to save the object to ensure that custom field validation is performed.  Example:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-14-1" name="__codelineno-14-1" href="#__codelineno-14-1"></a><span class="o">&gt;&gt;&gt;</span> <span class="n">device</span><span class="o">.</span><span class="n">cf</span><span class="p">[</span><span class="s2">&quot;support_group&quot;</span><span class="p">]</span>
 <a id="__codelineno-14-2" name="__codelineno-14-2" href="#__codelineno-14-2"></a><span class="s1">&#39;Network Operations (555-4357)&#39;</span>
 <a id="__codelineno-14-3" name="__codelineno-14-3" href="#__codelineno-14-3"></a><span class="o">&gt;&gt;&gt;</span> <span class="n">device</span><span class="o">.</span><span class="n">cf</span><span class="p">[</span><span class="s2">&quot;support_group&quot;</span><span class="p">]</span> <span class="o">=</span> <span class="s2">&quot;Network Testing (555-8080)&quot;</span>
@@ -10043,12 +10043,12 @@
 <a id="__codelineno-14-6" name="__codelineno-14-6" href="#__codelineno-14-6"></a><span class="s1">&#39;Network Testing (555-8080)&#39;</span>
 </code></pre></div>
 <p>If you do not use <code>.validated_save()</code> when creating or updating objects, the custom field dictionary will not be populated with default values or even empty values and this can lead to unintuitive behaviour.</p>
-<h3 id="modify-custom-field-data-in-the-rest-api">Modify Custom Field Data in the Rest API<a class="headerlink" href="#modify-custom-field-data-in-the-rest-api" title="Permanent link">&para;</a></h3>
-<p>Individual custom field data can be modified by sending a PATCH to the Rest API and setting the new value in the <code>custom_fields</code> key:</p>
+<h3 id="modify-custom-field-data-in-the-rest-api">Modify Custom Field Data in the REST API<a class="headerlink" href="#modify-custom-field-data-in-the-rest-api" title="Permanent link">&para;</a></h3>
+<p>Individual custom field data can be modified by sending a PATCH to the REST API and setting the new value in the <code>custom_fields</code> key:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-15-1" name="__codelineno-15-1" href="#__codelineno-15-1"></a>PATCH http://localhost:8080/api/dcim/devices/ffd8df99-6d1a-41c3-b19f-b8357eefc481/
 <a id="__codelineno-15-2" name="__codelineno-15-2" href="#__codelineno-15-2"></a>{
 <a id="__codelineno-15-3" name="__codelineno-15-3" href="#__codelineno-15-3"></a>    &quot;custom_fields&quot;: {
-<a id="__codelineno-15-4" name="__codelineno-15-4" href="#__codelineno-15-4"></a>        &quot;support_group&quot;: &quot;Rest API test&quot;
+<a id="__codelineno-15-4" name="__codelineno-15-4" href="#__codelineno-15-4"></a>        &quot;support_group&quot;: &quot;REST API test&quot;
 <a id="__codelineno-15-5" name="__codelineno-15-5" href="#__codelineno-15-5"></a>    }
 <a id="__codelineno-15-6" name="__codelineno-15-6" href="#__codelineno-15-6"></a>}
 </code></pre></div>
@@ -10061,7 +10061,7 @@
 <a id="__codelineno-16-5" name="__codelineno-16-5" href="#__codelineno-16-5"></a><span class="w">    </span><span class="nt">&quot;dmz_device&quot;</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="p">,</span>
 <a id="__codelineno-16-6" name="__codelineno-16-6" href="#__codelineno-16-6"></a><span class="w">    </span><span class="nt">&quot;eol_date&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;1970-01-01&quot;</span><span class="p">,</span>
 <a id="__codelineno-16-7" name="__codelineno-16-7" href="#__codelineno-16-7"></a><span class="w">    </span><span class="nt">&quot;cmdb_id&quot;</span><span class="p">:</span><span class="w"> </span><span class="mi">12345</span><span class="p">,</span>
-<a id="__codelineno-16-8" name="__codelineno-16-8" href="#__codelineno-16-8"></a><span class="w">    </span><span class="nt">&quot;support_group&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;Rest API test&quot;</span>
+<a id="__codelineno-16-8" name="__codelineno-16-8" href="#__codelineno-16-8"></a><span class="w">    </span><span class="nt">&quot;support_group&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;REST API test&quot;</span>
 <a id="__codelineno-16-9" name="__codelineno-16-9" href="#__codelineno-16-9"></a><span class="w">  </span><span class="p">}</span>
 <a id="__codelineno-16-10" name="__codelineno-16-10" href="#__codelineno-16-10"></a><span class="p">}</span>
 </code></pre></div>

nautobot/project-static/docs/user-guide/feature-guides/git-data-source.html

@@ -9766,7 +9766,7 @@ Navigate to <strong>Git Repositories</strong> and select the repository in quest
 <a id="__codelineno-6-4" name="__codelineno-6-4" href="#__codelineno-6-4"></a>├── query2.gql
 </code></pre></div>
 <h2 id="additional-git-data-sources">Additional Git Data Sources<a class="headerlink" href="#additional-git-data-sources" title="Permanent link">&para;</a></h2>
-<p>As seen in <a href="#fill-out-repository-details">Fill out Repository Details</a>, the standard installation of Nautobot will come natively with export templates, jobs, and config contexts.  Additional data sources can be incorporated using the Nautobot App system.  For example, the <a href="https://github.com/nautobot/nautobot-app-golden-config">nautobot-golden-config</a> App implements four additional data sources.</p>
+<p>As seen in <a href="#fill-out-repository-details">Fill out Repository Details</a>, the standard installation of Nautobot will come natively with export templates, jobs, and config contexts.  Additional data sources can be incorporated using the Nautobot App system.  For example, the <a href="https://github.com/nautobot/nautobot-app-golden-config">Golden Configuration</a> App implements four additional data sources.</p>
 <ul>
 <li>Config Contexts</li>
 <li>Backup Configs</li>

nautobot/project-static/docs/user-guide/feature-guides/graphql.html

@@ -9541,9 +9541,6 @@
 <a id="__codelineno-6-9" name="__codelineno-6-9" href="#__codelineno-6-9"></a><span class="w">  </span><span class="p">}</span>
 <a id="__codelineno-6-10" name="__codelineno-6-10" href="#__codelineno-6-10"></a><span class="p">}</span>
 </code></pre></div>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>You can also paginate the results returned to you when the data set gets larger. To do so, use the keywords "limit" and "offset". The "limit" keyword will limit the count of results returned after the "offset". If no "offset" is specified, then the default offset is zero.</p>
 <div class="highlight"><pre><span></span><code>```graphql
 query {
@@ -9622,9 +9619,6 @@ query {
 </code></pre></div>
 <p>In the updated script, we add the <code>variables = {"location_name": "ams"}</code> variable. We then update the query to let GraphQL know that we will be sending parameters to to filter by <code>location</code>. The updated output is still a JSON object. Instead of fetching all devices, we are filtering by devices in the <code>ams</code> location. The PyNautobot SDK has some <a href="https://pynautobot.readthedocs.io/en/latest/api/core/graphql.html">excellent GraphQL examples</a>. Be sure to check out the documentation.</p>
 <h3 id="saving-queries">Saving Queries<a class="headerlink" href="#saving-queries" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.1.0</summary>
-</details>
 <p>Queries can now be stored inside of Nautobot, allowing the user to easily rerun previously defined queries.</p>
 <p>Inside of <strong>Extensibility -&gt; Data Management -&gt; GraphQL Queries</strong>, there are views to create and manage GraphQL queries.</p>
 <p>Saved queries can be executed from the detailed query view or via a REST API request. The queries can also be populated from the detailed query view into GraphiQL by using the "Open in GraphiQL" button. Additionally, in the GraphiQL UI, there is now a menu item, "Queries", which can be used to populate GraphiQL with any previously saved query.</p>

nautobot/project-static/docs/user-guide/platform-functionality/computedfield.html

@@ -9230,9 +9230,6 @@
 
 
 <h1 id="computed-fields">Computed Fields<a class="headerlink" href="#computed-fields" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.1.0</summary>
-</details>
 <p>Computed fields are very similar in design and implementation to custom fields. See the overview of <a href="customfield.html">Custom Fields</a>. As the name suggests, computed fields serve the need for a custom field where the value is generated using data that Nautobot stores in its database and merging it into a Jinja2 template and associated filters.</p>
 <p>As an example, within your automation system, you may want to be able to have an automatically generated field on the Device model that combines the name of the device and the location name in uppercase. To do that, you would define a Jinja2 template for this field that looks like such:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>{{ obj.name }}_{{ obj.location.name | upper }}

nautobot/project-static/docs/user-guide/platform-functionality/customfield.html

@@ -9295,24 +9295,12 @@
 <li>Selection: A selection of one of several pre-defined custom choices</li>
 <li>Multiple selection: A selection field which supports the assignment of multiple values</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-<p>Support for JSON-type custom fields was added.</p>
-</details>
-<details class="version-added">
-<summary>Added in version 1.6.0</summary>
-<p>Support for Markdown-type custom fields was added.</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.1.8</summary>
 <p>Prior to this release, text-type custom fields were always limited to a maximum of 255 characters. In this and later releases, text-type custom fields have no intrinsic length limit unless one is <a href="#custom-field-validation">explicitly defined</a>.</p>
 </details>
 <p>Each custom field must have a key; this should be a simple database-friendly string, e.g. <code>tps_report</code>. You may also assign a corresponding human-friendly label (e.g. "TPS report"); the label will be displayed on web forms. A weight is also required: Higher-weight fields will be ordered lower within a form. (The default weight is 100.) If a description is provided, it will appear beneath the field in a form.</p>
 <details class="version-changed">
-<summary>Changed in version 1.4.0</summary>
-<p>Custom fields now have both a <code>name</code> and a <code>slug</code>; in older versions there was no <code>slug</code> field. When migrating existing data to Nautobot 1.4.0 or later, the <code>label</code> and <code>slug</code> will be automatically populated for existing custom fields if necessary.</p>
-</details>
-<details class="version-changed">
 <summary>Changed in version 2.0.0</summary>
 <p>The custom field <code>slug</code> has been renamed to <code>key</code>, and <code>name</code> to <code>label</code>, in order to provide more clarity around their usage. Existing custom fields will automatically be migrated when upgrading to Nautobot 2.0.0 or later.</p>
 <p>Additionally, the <code>key</code> now <strong>must</strong> be a valid GraphQL identifier, which in general means that it must start with a lowercase letter and contain only lowercase letters, numbers, and underscores.</p>
@@ -9323,10 +9311,10 @@
 </div>
 <p>Marking a field as required will force the user to provide a value for the field when creating a new object or when saving an existing object. A default value for the field may also be provided. Use "true" or "false" for boolean fields, or the exact value of a choice for selection fields.</p>
 <p>The filter logic controls how values are matched when filtering objects by the custom field. Loose filtering (the default) matches on a partial value, whereas exact matching requires a complete match of the given string to a field's value. For example, exact filtering with the string "red" will only match the exact value "red", whereas loose filtering will match on the values "red", "red-orange", or "bored". Setting the filter logic to "disabled" disables filtering by the field entirely.</p>
-<details class="version-changed">
-<summary>Changed in version 1.4.0</summary>
+<div class="admonition tip">
+<p class="admonition-title">Tip</p>
 <p>Custom field <a href="rest-api/filtering.html#lookup-expressions">extended filtering</a> introduced extended lookup expression filters for <code>exact</code> and <code>icontains</code>, duplicating the functionality of both the <code>Strict</code> and <code>Loose</code> settings.</p>
-</details>
+</div>
 <p>A custom field must be assigned to one or more object types, or models, in Nautobot. Once created, custom fields will automatically appear as part of these models in the web UI and REST API.</p>
 <p>When creating a custom field, if "Move to Advanced tab" is checked, this custom field won't appear on the object's main detail tab in the UI, but will appear in the "Advanced" tab. This is useful when the requirement is to hide this field from the main detail tab when, for instance, it is only required for machine-to-machine communication and not user consumption.</p>
 <h3 id="custom-field-validation">Custom Field Validation<a class="headerlink" href="#custom-field-validation" title="Permanent link">&para;</a></h3>

nautobot/project-static/docs/user-guide/platform-functionality/dynamicgroup.html

@@ -9468,9 +9468,6 @@
 
 
 <h1 id="dynamic-groups">Dynamic Groups<a class="headerlink" href="#dynamic-groups" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>Dynamic Groups provide a general-purpose way to collect related objects of a given Content Type, such as Devices associated with a given Location(s) and Status(es), Circuits attached to a given set of Devices, and so forth. A given Dynamic Group may contain any number of objects of the appropriate type as members, and an object may belong to any number of Dynamic Groups of the appropriate content-type as a member of each. It is possible both to query the members of a given Dynamic Group, and also to query which Dynamic Groups a given object is a member of.</p>
 <p>There are currently three ways to define the object members of a Dynamic group:</p>
 <ol>
@@ -9479,10 +9476,6 @@
 <li>Static assignment directly to the group (for example, "Device XYZ01, Device XYZ02, and Device XYZ04")</li>
 </ol>
 <details class="version-added">
-<summary>Added in version 1.4.0 — Set-based group assignment</summary>
-<p>Support for set-based assignment to groups was added.</p>
-</details>
-<details class="version-added">
 <summary>Added in version 2.3.0 — Static group assignment</summary>
 <p>Support for static assignment to groups was added, and the distinction between filter-based and set-based assignment was formally established.</p>
 </details>
@@ -9515,19 +9508,11 @@
 </div>
 <h2 id="dynamic-group-types">Dynamic Group Types<a class="headerlink" href="#dynamic-group-types" title="Permanent link">&para;</a></h2>
 <h3 id="filter-based-dynamic-groups">Filter-Based Dynamic Groups<a class="headerlink" href="#filter-based-dynamic-groups" title="Permanent link">&para;</a></h3>
-<p>Assignment of objects to a filter-based Dynamic Group is powered by Nautobot <strong>FilterSet</strong> classes underneath the hood. The <a href="https://django-filter.readthedocs.io/en/stable/">django-filter</a> documentation may be a useful reference for users wanting to develop an in-depth understanding of FilterSets, but is by no means required to understand Dynamic Groups.</p>
+<p>Assignment of objects to a filter-based Dynamic Group is powered by Nautobot <strong>FilterSet</strong> classes underneath the hood. The <a href="https://django-filter.readthedocs.io/en/stable/"><code>django-filter</code></a> documentation may be a useful reference for users wanting to develop an in-depth understanding of FilterSets, but is by no means required to understand Dynamic Groups.</p>
 <p>A filter-based Dynamic Group defines a <code>filter</code> field, which is stored in the database as a JSON dict. An object is considered to be a member of such a Dynamic Group if it has the correct Content Type and it is not excluded by the filter criteria defined by the group. By default, a freshly created Dynamic Group has an empty filter (<code>{}</code>), which means that all objects of the matching Content Type are members of this group, just as a default list view of these objects would display all such objects prior to any filter fields being selected in the web UI.</p>
 <p>For example, for a Dynamic Group with Content Type of <code>dcim.device</code> and an empty filter, the list of members would be equivalent to the default Device list view, which in turn is equivalent to the queryset for <code>Device.objects.all()</code> from the database ORM.</p>
-<details class="version-changed">
-<summary>Changed in version 1.4.0 — Change in empty filter behavior</summary>
-<p>In Nautobot v1.3.0 the default for a Dynamic Group with an empty filter was to "fail closed" and have zero members.</p>
-<p>As of v1.4.0, this behavior has been inverted to default to include all objects matching the Content Type, instead of matching no objects as was previously the case. This was necessary to implement the progressive layering of child filters similarly to how we use filters to reduce desired objects from basic list view filters. This will be described in more detail below.</p>
-</details>
 <p>When editing a filter-based Dynamic Group, under the <strong>Filter Options</strong> section, you will find a <strong>Filter Fields</strong> tab that allows you to select filter criteria. The filter fields available for a given Content Type are backed and validated by underlying FilterSet classes (for example <code>nautobot.dcim.filters.DeviceFilterSet</code>) and are represented in the web interface as a dynamically-generated filter form that corresponds to each eligible filter field.</p>
 <h3 id="set-based-dynamic-groups">Set-Based Dynamic Groups<a class="headerlink" href="#set-based-dynamic-groups" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>Set-based Dynamic Groups do not directly define a filter for identifying member objects; instead, they define their members based on set operations (AND, OR, and NOT, or Union, Intersection, and Difference if you prefer) involving <em>other</em> Dynamic Groups.</p>
 <div class="admonition tip">
 <p class="admonition-title">Tip</p>
@@ -9571,9 +9556,6 @@
 <p>Keep in mind that the <code>Filter Query Logic</code> will also contain any descendants of the selected model instance.  As we can see above the <code>Filter Query Logic</code> uses both location "BKK01" and "AMSO1" and their descendants.</p>
 </div>
 <h3 id="advanced-filtering-defining-a-set-based-dynamic-group-to-combine-two-others">Advanced Filtering: Defining a Set-Based Dynamic Group to Combine Two Others<a class="headerlink" href="#advanced-filtering-defining-a-set-based-dynamic-group-to-combine-two-others" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>Now, let's say that you add a third location to your network. This location is currently being built out, and you don't care about Devices from this location that are Offline status at present. What you want for your "Devices of Interest" Dynamic Group is logic similar to:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>(
 <a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a>  (
@@ -9612,9 +9594,6 @@
 <a id="__codelineno-2-11" name="__codelineno-2-11" href="#__codelineno-2-11"></a>)
 </code></pre></div>
 <h3 id="advanced-filtering-nested-groups-and-negation">Advanced Filtering: Nested Groups and Negation<a class="headerlink" href="#advanced-filtering-nested-groups-and-negation" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>Next, let's say you add a fourth location to your network. This location is in bad shape, and has Devices in a wide range of statuses. You want your "Devices of Interest" group to include all Devices from this location, <em>except for those in Decommissioning status</em>. To express this logic and add these devices to our parent group, we will need to use a combination of groups and the "Exclude (NOT)" operator.</p>
 <p>First, you will create an "Location D All Devices" group. This will simply match Devices at Location "DEL01", regardless of their status.</p>
 <p><img alt="Another Child Group" src="../../media/models/dynamicgroup_workflow_advanced_2_01.png" /></p>
@@ -9803,11 +9782,6 @@
 <p class="admonition-title">Note</p>
 <p>Please refer to either the source code definition of the <code>{model_name}FilterSet</code> (e.g. for <code>Device</code> it would be <code>nautobot.dcim.filters.DeviceFilterSet</code>) or the API documentation for the list endpoint (e.g. <code>/api/dcim/devices/</code>) for a given model object, to view the available filter fields and their expectations.</p>
 </div>
-<details class="version-changed">
-<summary>Changed in version 1.4.0</summary>
-<p>Prior to v1.4.0, any invalid field names that are not eligible for filtering objects will be discarded upon validation.</p>
-<p>As of v1.4.0, <a href="../administration/configuration/settings.html#strict_filtering">strict filtering is enabled by default</a>, which causes any invalid field names to result in a <code>ValidationError</code>.</p>
-</details>
 <h3 id="managing-dynamic-groups-in-the-rest-api">Managing Dynamic Groups in the REST API<a class="headerlink" href="#managing-dynamic-groups-in-the-rest-api" title="Permanent link">&para;</a></h3>
 <h4 id="creating-a-dynamic-group-via-rest">Creating a Dynamic Group via REST<a class="headerlink" href="#creating-a-dynamic-group-via-rest" title="Permanent link">&para;</a></h4>
 <p>A Dynamic Group may be created by performing a <code>POST</code> to the Dynamic Groups list endpoint at <code>/api/extras/dynamic-groups/</code>.</p>

nautobot/project-static/docs/user-guide/platform-functionality/gitrepository.html

@@ -9541,10 +9541,6 @@
 <p class="admonition-title">Important</p>
 <p>Nautobot's Git integration depends on the availability of the <code>git</code> program. If <code>git</code> is not installed, Nautobot will be unable to pull data from Git repositories.</p>
 </div>
-<details class="version-changed">
-<summary>Changed in version 1.6.2</summary>
-<p>To proactively avoid conflicts in data, it is no longer possible to configure multiple Git repository entries that both have the same <code>remote_url</code> and also provide the same data type(s). Configuration of multiple entries with the same <code>remote_url</code> is still permitted if they are configured to provide entirely distinct types of data.</p>
-</details>
 <h2 id="repository-configuration">Repository Configuration<a class="headerlink" href="#repository-configuration" title="Permanent link">&para;</a></h2>
 <p>When defining a Git repository for Nautobot to consume, the <code>name</code>, <code>remote URL</code>, and <code>branch</code> parameters are mandatory - the name acts as a unique identifier, and the remote URL and branch are needed for Nautobot to be able to locate and access the specified repository. Additionally, if the repository is private you may specify a <code>secrets group</code> that can be used to gain access to the repository.</p>
 <div class="admonition note">
@@ -9594,10 +9590,6 @@ in order for the repository to sync.</p>
 <li><strong>Implicit</strong>: They're defined using a specific folder and file structure to apply the config context to a specific scope.</li>
 <li><strong>Local</strong>: Defined at the device/virtual machine level and only being applied to the specific device/virtual machine.</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.5.6</summary>
-<p>Config contexts provided in a Git repository can now be filtered by <code>locations</code> in addition to all previously supported filters.</p>
-</details>
 <h4 id="metadata">Metadata<a class="headerlink" href="#metadata" title="Permanent link">&para;</a></h4>
 <p>The metadata used to create the config context has the following options and is specified by the <code>_metadata</code> key.</p>
 <table>

nautobot/project-static/docs/user-guide/platform-functionality/graphql.html

@@ -9113,7 +9113,7 @@
         <li class="md-nav__item">
   <a href="#querying-the-graphql-interface-over-the-rest-api" class="md-nav__link">
     <span class="md-ellipsis">
-      Querying the GraphQL interface over the rest API
+      Querying the GraphQL interface over the REST API
     </span>
   </a>
   
@@ -9216,8 +9216,8 @@
 <a id="__codelineno-1-23" name="__codelineno-1-23" href="#__codelineno-1-23"></a><span class="p">}</span>
 </code></pre></div>
 <p>It is possible to explore the Graph and create some queries in a human friendly UI at the endpoint <code>graphql/</code>. This interface (called <code>graphqli</code>) provides a great playground to build new queries as it provides full autocompletion and type validation.</p>
-<h2 id="querying-the-graphql-interface-over-the-rest-api">Querying the GraphQL interface over the rest API<a class="headerlink" href="#querying-the-graphql-interface-over-the-rest-api" title="Permanent link">&para;</a></h2>
-<p>It is possible to query the GraphQL interface via the rest API as well, the endpoint is available at <code>api/graphql/</code> and supports the same Token based authentication as all other Nautobot APIs.</p>
+<h2 id="querying-the-graphql-interface-over-the-rest-api">Querying the GraphQL interface over the REST API<a class="headerlink" href="#querying-the-graphql-interface-over-the-rest-api" title="Permanent link">&para;</a></h2>
+<p>It is possible to query the GraphQL interface via the REST API as well, the endpoint is available at <code>api/graphql/</code> and supports the same Token based authentication as all other Nautobot APIs.</p>
 <p>A GraphQL Query must be encapsulated in a JSON payload with the <code>query</code> key and sent with a POST request. Optionally it is possible to provide a list of <code>variables</code> in the same payload as presented below.</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a><span class="p">{</span>
 <a id="__codelineno-2-2" name="__codelineno-2-2" href="#__codelineno-2-2"></a><span class="w">  </span><span class="nt">&quot;query&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;query ($id: Int!) { device(id: $id) { name }}&quot;</span><span class="p">,</span>
@@ -9382,9 +9382,6 @@
 <p>Computed Fields with the prefixed <code>cpf_</code> are only available in GraphQL <strong>after</strong> the computed field is created <strong>and</strong> the web service is restarted.</p>
 </div>
 <h2 id="saved-queries">Saved Queries<a class="headerlink" href="#saved-queries" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.1.0</summary>
-</details>
 <p>Queries can now be stored inside of Nautobot, allowing the user to easily rerun previously defined queries.</p>
 <p>Inside of <strong>Extensibility -&gt; Data Management -&gt; GraphQL Queries</strong>, there are views to create and manage GraphQL queries.</p>
 <p>Saved queries can be executed from the detailed query view or via a REST API request. The queries can also be populated from the detailed query view into GraphiQL by using the "Open in GraphiQL" button. Additionally, in the GraphiQL UI, there is now a menu item, "Queries", which can be used to populate GraphiQL with any previously saved query.</p>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/index.html

@@ -9324,10 +9324,6 @@
 </ul>
 <p>The <code>class_path</code> is often represented as a string in the format of <code>&lt;module_name&gt;.&lt;JobClassName&gt;</code>, such as <code>example.MyJobWithNoVars</code> or <code>nautobot_golden_config.jobs.BackupJob</code>. Understanding the definitions of these elements will be important in running jobs programmatically.</p>
 <details class="version-changed">
-<summary>Changed in version 1.3.0</summary>
-<p>With the addition of Job database models, it is now generally possible and preferable to refer to a job by its UUID primary key, similar to other Nautobot database models, rather than its <code>class_path</code>.</p>
-</details>
-<details class="version-changed">
 <summary>Changed in version 2.0.0</summary>
 <p>The Job database model <code>name</code> field is now enforced to be globally unique and so is also an option for uniquely identifying Job records.</p>
 </details>
@@ -9386,11 +9382,7 @@
 <p class="admonition-title">Note</p>
 <p><a href="#jobs-and-class_path">See above</a> for <code>class_path</code> definitions.</p>
 </div>
-<details class="version-added">
-<summary>Added in version 1.3.10</summary>
-<p>The <code>--data</code> and <code>--local</code> parameters were added.</p>
 <p>The <code>--data</code> parameter must be a JSON string, e.g. <code>--data='{"string_variable": "somevalue", "integer_variable": 123}'</code></p>
-</details>
 <p>Using the same example shown in the API:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>nautobot-server runjob --username myusername example.MyJobWithNoVars
 </code></pre></div>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/job-scheduling-and-approvals.html

@@ -9292,9 +9292,6 @@
 
 
 <h1 id="job-scheduling-and-approvals">Job Scheduling and Approvals<a class="headerlink" href="#job-scheduling-and-approvals" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
-</details>
 <p>Oftentimes jobs will need to be run at a later date or periodically, or require approval from someone before they can be started. To this end, Nautobot offers facilities for scheduling and approving jobs.</p>
 <h2 id="job-scheduling">Job Scheduling<a class="headerlink" href="#job-scheduling" title="Permanent link">&para;</a></h2>
 <p>Jobs can be scheduled to be run immediately, at some point in the future, or at an interval.</p>
@@ -9327,10 +9324,6 @@
 <p>Requiring approval for execution of Job Hooks by setting the <code>Meta.approval_required</code> attribute to <code>True</code> on your <code>JobHookReceiver</code> subclass is not supported. The value of this attribute will be ignored. Support for requiring approval of Job Hooks will be added in a future release.</p>
 </div>
 <p>Scheduled jobs can be approved or denied via the UI and API by any user that has the <code>extras.approve_job</code> permission for the job in question, as well as the appropriate <code>extras.change_scheduledjob</code> and/or <code>extras.delete_scheduledjob</code> permissions.</p>
-<details class="version-changed">
-<summary>Changed in version 1.3.0</summary>
-<p>The <code>extras.approve_job</code> permission is now required for job approvers.</p>
-</details>
 <div class="admonition note">
 <p class="admonition-title">Note</p>
 <p>Jobs that are past their scheduled run date can still be approved, but the approver will be asked to confirm the operation.</p>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/jobbutton.html

@@ -9232,9 +9232,6 @@
 
 
 <h1 id="job-buttons">Job Buttons<a class="headerlink" href="#job-buttons" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.5.14</summary>
-</details>
 <p>Job Buttons are predefined buttons that allow users to run jobs directly from within Nautobot object views. It uses the object where the button was pressed as the only input to the job. These are helpful when you want to start a job that requires minimal or no input without having to use the standard job form. For example, you may have a job that only requires a user to select a device. Instead, they can now go to that device in the web UI and click the associated Job Button instead.</p>
 <p>Job Buttons can be created in web UI located in the navbar under Jobs &gt; Job Buttons. Each button can be associated with multiple Nautobot object types (location, device, prefix, etc.) and will be displayed on all of the associated object detail views. The text displayed on the button supports Jinja2 templating which allows for using <a href="#context-data">context data</a> to dynamically update or <a href="#conditional-rendering">even be hidden under certain conditions</a>.</p>
 <p>The buttons appear at the top right corner of an object's individual detail page for each object type they are associated to. They can be either individual buttons or grouped together in a dropdown for better organization. Buttons will be sorted from left to right based on their <code>weight</code> with the lowest <code>weight</code> button on the left. Any groups of buttons will be displayed to the right of all ungrouped buttons. Group dropdown buttons will inherit the button class from the button with the lowest <code>weight</code> in the group and will be sorted from top to bottom with the lowest <code>weight</code> button on top.</p>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/jobhook.html

@@ -9178,9 +9178,6 @@
 
 
 <h1 id="job-hooks">Job Hooks<a class="headerlink" href="#job-hooks" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>A Job Hook is a mechanism for automatically starting a <a href="index.html">job</a> when an object is changed. Job Hooks are similar to <a href="../webhook.html">webhooks</a> except that an object change event initiates a <code>JobHookReceiver</code> job instead of a web request. Job hooks are configured in the web UI under <strong>Jobs &gt; Job Hooks</strong>.</p>
 <h2 id="configuration">Configuration<a class="headerlink" href="#configuration" title="Permanent link">&para;</a></h2>
 <ul>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/jobqueue.html

@@ -9125,8 +9125,8 @@
 <details class="version-added">
 <summary>Added in version 2.4.0</summary>
 </details>
-<p>JobQueue instances represent the queues that nautobot <a href="index.html">jobs</a> can be run on. It is introduced as an alternative to <code>task_queues</code> attribute on the Job model to define the eligible queues for this job.</p>
-<p>The JobQueue model has <code>name</code> and <code>queue_type</code> as required attributes. The <code>name</code> attribute has to be unique on each Job Queue and there are currently two supported queue types: "celery" and "kubernetes". The user can optionally assign a <a href="../../core-data-model/tenancy/tenant.html">tenant</a> instance to a Job Queue.</p>
+<p>JobQueue instances represent the queues that Nautobot <a href="index.html">jobs</a> can be run on. It is introduced as an alternative to <code>task_queues</code> attribute on the Job model to define the eligible queues for this job.</p>
+<p>The JobQueue model has <code>name</code> and <code>queue_type</code> as required attributes. The <code>name</code> attribute has to be unique on each Job Queue and there are currently two supported queue types: <code>"celery"</code> and <code>"kubernetes"</code>. The user can optionally assign a <a href="../../core-data-model/tenancy/tenant.html">tenant</a> instance to a Job Queue.</p>
 <p>You can access the Job instances that the Job Queue is assigned to through the <code>jobs</code> attribute from the Job Queue side.</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="o">&gt;&gt;&gt;</span> <span class="n">JobQueue</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">first</span><span class="p">()</span>
 <a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="o">&lt;</span><span class="n">JobQueue</span><span class="p">:</span> <span class="n">celery</span><span class="p">:</span> <span class="n">celery</span> <span class="n">Job</span> <span class="n">Queue</span> <span class="o">-</span> <span class="mi">2</span><span class="o">&gt;</span>

nautobot/project-static/docs/user-guide/platform-functionality/jobs/kubernetes-job-support.html

@@ -9412,8 +9412,8 @@
 </ol>
 <p>So if you have any concerns with running Celery workers in your Kubernetes deployment, executing jobs with Kubernetes might be for you.</p>
 <h2 id="how-to-configure-environment-variables">How to Configure Environment Variables<a class="headerlink" href="#how-to-configure-environment-variables" title="Permanent link">&para;</a></h2>
-<h3 id="nautobot_kubernetes_job_manifest">NAUTOBOT_KUBERNETES_JOB_MANIFEST<a class="headerlink" href="#nautobot_kubernetes_job_manifest" title="Permanent link">&para;</a></h3>
-<p>This environment variable should store a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/">Kubernetes Job</a> template as a python dictionary. Below is a sample kubernetes job manifest.</p>
+<h3 id="nautobot_kubernetes_job_manifest"><code>NAUTOBOT_KUBERNETES_JOB_MANIFEST</code><a class="headerlink" href="#nautobot_kubernetes_job_manifest" title="Permanent link">&para;</a></h3>
+<p>This environment variable should store a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/">Kubernetes Job</a> template as a Python dictionary. Below is a sample kubernetes job manifest.</p>
 <div class="admonition important">
 <p class="admonition-title">Important</p>
 <p>Ensure this job template uses the same Docker image as your Nautobot Kubernetes deployment. You can specify the image name in spec.template.spec.containers.image. Additionally, configure and map the required environment variables to corresponding <a href="https://kubernetes.io/docs/concepts/configuration/configmap/">Kubernetes ConfigMap</a> instances. These variables can be defined in the spec.template.spec.containers.env list. For consistency, it is recommended to use the same environment configuration for this Job manifest as that of your Nautobot Kubernetes deployment.</p>
@@ -9482,9 +9482,9 @@
 <a id="__codelineno-0-62" name="__codelineno-0-62" href="#__codelineno-0-62"></a>    <span class="p">},</span>
 <a id="__codelineno-0-63" name="__codelineno-0-63" href="#__codelineno-0-63"></a><span class="p">}</span>
 </code></pre></div>
-<h3 id="nautobot_kubernetes_job_pod_name">NAUTOBOT_KUBERNETES_JOB_POD_NAME<a class="headerlink" href="#nautobot_kubernetes_job_pod_name" title="Permanent link">&para;</a></h3>
-<p>The default value for this environment variable is "nautobot-job". You can modify this value as needed; however, ensure that <code>metadata.name</code> field in NAUTOBOT_KUBERNETES_JOB_MANIFEST is updated accordingly to maintain consistencty</p>
-<h3 id="nautobot_kubernetes_job_pod_namespace">NAUTOBOT_KUBERNETES_JOB_POD_NAMESPACE<a class="headerlink" href="#nautobot_kubernetes_job_pod_namespace" title="Permanent link">&para;</a></h3>
+<h3 id="nautobot_kubernetes_job_pod_name"><code>NAUTOBOT_KUBERNETES_JOB_POD_NAME</code><a class="headerlink" href="#nautobot_kubernetes_job_pod_name" title="Permanent link">&para;</a></h3>
+<p>The default value for this environment variable is <code>"nautobot-job"</code>. You can modify this value as needed; however, ensure that <code>metadata.name</code> field in <code>NAUTOBOT_KUBERNETES_JOB_MANIFEST</code> is updated accordingly to maintain consistencty</p>
+<h3 id="nautobot_kubernetes_job_pod_namespace"><code>NAUTOBOT_KUBERNETES_JOB_POD_NAMESPACE</code><a class="headerlink" href="#nautobot_kubernetes_job_pod_namespace" title="Permanent link">&para;</a></h3>
 <p>The default value for this environment variable is "default". However, this value could be inaccurate depending on the setup of your Nautobot deployment. To ensure you have the right value for this variable. You can run the command <code>kubectl describe pod &lt;nautobot-pod-name&gt;</code> and you should see an output similar to what is below:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>Name:<span class="w">             </span>nautobot-679bdc765-hl72m
 <a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a>Namespace:<span class="w">        </span>default
@@ -9501,7 +9501,7 @@
 <a id="__codelineno-1-13" name="__codelineno-1-13" href="#__codelineno-1-13"></a>...
 </code></pre></div>
 <p>Note that the field with label <code>Namespace</code> tells you exactly what namespace your Nautobot deployment is in and what value you should assign to the environment variable <code>NAUTOBOT_KUBERNETES_JOB_POD_NAMESPACE</code>. To ensure you have the right value for this variable. You can run the command <code>kubectl describe pod &lt;nautobot-pod-name&gt;</code> and you should see an output similar to what is below:</p>
-<h3 id="nautobot_kubernetes_default_service_address">NAUTOBOT_KUBERNETES_DEFAULT_SERVICE_ADDRESS<a class="headerlink" href="#nautobot_kubernetes_default_service_address" title="Permanent link">&para;</a></h3>
+<h3 id="nautobot_kubernetes_default_service_address"><code>NAUTOBOT_KUBERNETES_DEFAULT_SERVICE_ADDRESS</code><a class="headerlink" href="#nautobot_kubernetes_default_service_address" title="Permanent link">&para;</a></h3>
 <p>The default value for this environment variable is <a href="https://kubernetes.default.svc">https://kubernetes.default.svc</a>. However, this value may vary depending on your Nautobot deployment setup. The format for the base URL is <code>https://&lt;kubernetes-service-name&gt;.&lt;kubernetes-service-namespace&gt;.svc.</code></p>
 <p>If you know the namespace where your Kubernetes service is running, you can run the command <code>kubectl get services -n &lt;kubernetes-service-namespace&gt;</code> to retrieve the service details. The output will resemble the example shown below.</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>NAME<span class="w">         </span>TYPE<span class="w">        </span>CLUSTER-IP<span class="w">      </span>EXTERNAL-IP<span class="w">   </span>PORT<span class="o">(</span>S<span class="o">)</span><span class="w">    </span>AGE

nautobot/project-static/docs/user-guide/platform-functionality/jobs/models.html

@@ -9215,9 +9215,6 @@
 
 <h1 id="job-models">Job Models<a class="headerlink" href="#job-models" title="Permanent link">&para;</a></h1>
 <h2 id="job">Job<a class="headerlink" href="#job" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>The Job data model provides a database representation of metadata describing a specific installed Job class. It also serves as an anchor point for other data models (JobResult and ScheduledJob in particular) to link against.</p>
 <p>For any given Job record, most of its fields are populated initially from data defined in the source code of the corresponding job class. These fields may be explicitly overridden by editing the Job record via the Nautobot UI or REST API if desired. This is generally accomplished by setting a value for the desired field (e.g. <code>grouping</code>) and also setting the corresponding <code>override</code> flag (e.g. <code>grouping_override</code>) to <code>True</code>. If the <code>override</code> flag for a field is cleared (set back to <code>False</code>) then the corresponding flag will automatically revert to the original value defined by the Job class source code when the record is saved.</p>
 <div class="admonition note">
@@ -9242,9 +9239,6 @@
 </div>
 <p>For any Job that is loaded into Nautobot, the Job must be enabled to run. See <a href="index.html#enabling-jobs-for-running">Enabling Jobs for Running</a> for more details.</p>
 <h2 id="job-log-entry">Job Log Entry<a class="headerlink" href="#job-log-entry" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
-</details>
 <p>Log messages from <a href="index.html">Jobs</a> are stored in as <code>JobLogEntry</code> objects. This allows more performant querying of log messages and even allows viewing of logs while the job is still running.</p>
 <p>Records of this type store the following data:</p>
 <ul>
@@ -9254,10 +9248,6 @@
 <li>The log message.</li>
 <li>If provided, the string format of the logged object and it's absolute url.</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.2.2</summary>
-<p>REST API and GraphQL support for querying <code>JobLogEntry</code> records were added.</p>
-</details>
 <h2 id="job-results">Job Results<a class="headerlink" href="#job-results" title="Permanent link">&para;</a></h2>
 <p>Nautobot provides a generic data model for storing and reporting the results of background tasks, such as the execution of custom jobs or the synchronization of data from a Git repository.</p>
 <p>Records of this type store the following data:</p>
@@ -9271,10 +9261,6 @@
 <li>A block of structured data representing the return value from the <code>.run()</code> method (often rendered as JSON).</li>
 </ul>
 <details class="version-changed">
-<summary>Changed in version 1.2.0</summary>
-<p>Note that prior to Nautobot 1.2, job log records were stored in the <code>data</code> field; they are now stored as distinct <a href="#job-log-entry"><code>JobLogEntry</code></a> records instead.</p>
-</details>
-<details class="version-changed">
 <summary>Changed in version 2.3.0</summary>
 <p>The Additional Data tab has been removed, you can now find the data in the Advanced Tab.</p>
 </details>

nautobot/project-static/docs/user-guide/platform-functionality/note.html

@@ -9120,9 +9120,6 @@
 
 
 <h1 id="note">Note<a class="headerlink" href="#note" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>Notes provide a place for you to store notes or general information on an object, such as a Device, that may not require a specific field for. This could be a note on a recent upgrade, a warning about a problematic device, or the reason the Rack was marked with the Status <code>Retired</code>.</p>
 <p>The note field supports <a href="https://www.markdownguide.org/cheat-sheet/#basic-syntax">Markdown Basic Syntax</a> as well as <a href="template-filters.html#render_markdown">a limited subset of HTML</a>.</p>