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

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>

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

@@ -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>

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>
@@ -9518,16 +9511,8 @@
 <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

@@ -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/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>
 

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

@@ -9404,22 +9404,16 @@
 <li><strong>One-to-many</strong> - where one side of the connection can only have one object. For example, where a controller has many supplicants like FEX and parent switch. A FEX can be uplinked to one parent switch (in most cases), but the parent switch can have many FEX.</li>
 <li><strong>One-to-one</strong> - where there can be only one object on either side of the relationship. For example, an IP address serving as a router-id for a device. Each device has at most one router-id, and each IP address can be a router-id for at most one device.</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
 <p>Additionally, there are two <em>symmetric</em> relationship types that can be used when defining a relationship between objects of the same type. These relationship types treat the two <em>sides</em> of a relationship as interchangeable (much like the A/Z sides of a circuit, or the endpoints of a cable) rather than distinguishing between the <em>source</em> and <em>destination</em> of a relationship as the non-symmetric relationship types above do.</p>
 <ul>
-<li><strong>Symmetric Many-to-many</strong> - as in Many-to-many, but acting more as an <em>undirected graph</em> of similar objects. For example, this could be used to define a set of devices participating in a routing topology, where each device has some number of peers and there's no distinction between <em>source</em> and <em>destination</em> peers.</li>
+<li><strong>Symmetric Many-to-many</strong> - as in Many-to-many, but acting more as an <em>undirected graph</em> of several objects of the same type. For example, this could be used to define a set of devices participating in a routing topology, where each device has some number of peers and there's no distinction between <em>source</em> and <em>destination</em> peers.</li>
 <li><strong>Symmetric One-to-one</strong> - as in One-to-one, but defining a relationship between exactly two objects of the same type. For example, a HSRP/VRRP pair of redundant devices, where each device has exactly one peer device.</li>
 </ul>
-</details>
 <div class="admonition note">
 <p class="admonition-title">Note</p>
 <p>A symmetric many-to-many relationship can be, but is not necessarily, a <em>complete graph</em> or <em>full mesh</em>. For example, in the routing topology example above, if Device <em>A</em> and Device <em>B</em> are peers, and Device <em>B</em> and Device <em>C</em> are peers, this does not automatically imply a relationship between Devices <em>A</em> and <em>C</em> -- they <strong>might or might not</strong> also be peers, depending on how you define and populate the specific associations for this relationship.</p>
 </div>
 <h2 id="required-relationships">Required Relationships<a class="headerlink" href="#required-relationships" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <p>Relationships can be marked as being required. By default, relationships are not marked as being required.</p>
 <p>To mark a relationship as being required, select "Source objects MUST implement this relationship" or conversely "Destination objects MUST implement this relationship" from the "Required on" field when editing or creating a relationship:</p>
 <ul>
@@ -9483,9 +9477,6 @@ From the Devices/Circuits example above, you might label the relationship so tha
 </code></pre></div>
 <h3 id="configuring-the-relationship-between-objects">Configuring the Relationship between Objects<a class="headerlink" href="#configuring-the-relationship-between-objects" title="Permanent link">&para;</a></h3>
 <h4 id="via-object-endpoints">Via Object Endpoints<a class="headerlink" href="#via-object-endpoints" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>To get object relationships and associations from the REST API, you can query any object endpoint with the <a href="rest-api/filtering.html#filtering-included-fields"><code>?include=relationships</code> query parameter</a> included, for example <code>GET /api/dcim/devices/f472bb77-7f56-4e79-ac25-2dc73eb63924/?include=relationships</code>. The API response will include a nested dictionary of relationships and associations applicable to the object(s) retrieved.</p>
 <p>Similarly, you can update the relationship associations for a given object via an HTTP <code>POST</code> or <code>PATCH</code> request, generally by including the nested key <code>["relationships"][&lt;relationship_key&gt;]["source"|"destination"|"peer"]["objects"]</code> with a list of objects to associate.</p>
 <p>For more details on this feature, refer to the <a href="rest-api/overview.html">REST API documentation</a>.</p>

nautobot/project-static/docs/user-guide/platform-functionality/rest-api/authentication.html

@@ -9219,9 +9219,6 @@
 <a id="__codelineno-3-3" name="__codelineno-3-3" href="#__codelineno-3-3"></a><span class="p">}</span>
 </code></pre></div>
 <h2 id="initial-token-provisioning">Initial Token Provisioning<a class="headerlink" href="#initial-token-provisioning" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>Ideally, each user should provision his or her own REST API token(s) via the web UI. However, you may encounter where a token must be created by a user via the REST API itself. Nautobot provides a special endpoint to provision tokens using a valid username and password combination.</p>
 <p>To provision a token via the REST API, make a <code>POST</code> request to the <code>/api/users/tokens/</code> endpoint:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>curl<span class="w"> </span>-X<span class="w"> </span>POST<span class="w"> </span><span class="se">\</span>

nautobot/project-static/docs/user-guide/platform-functionality/rest-api/filtering.html

@@ -9372,9 +9372,6 @@
 <li><code>?include=computed_fields</code> - Any object supporting <a href="../computedfield.html">Computed Fields</a>. Computed field values are not included by default, but can be added by specifying this query parameter.</li>
 <li><code>?exclude_m2m=true</code> - Any object with many-to-many relations to another type of object. These related objects are included by default, but can be excluded (in many cases improving the REST API performance) by specifying this query parameter.</li>
 </ul>
-<details class="version-added">
-<summary>Added in version 1.4.0 — Added <code>include=relationships</code> and <code>include=computed_fields</code> support</summary>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.0.0 — Changed config contexts to excluded by default, added <code>include=config_context</code> support</summary>
 </details>
@@ -9385,10 +9382,6 @@
 <p>The objects returned by an API list endpoint can be filtered by attaching one or more query parameters to the request URL. For example, <code>GET /api/dcim/locations/?status=active</code> will return only locations with a status of "active."</p>
 <p>Multiple parameters can be joined to further narrow results. For example, <code>GET /api/dcim/locations/?status=active&amp;parent=europe&amp;location_type=country</code> will return only active "country" type locations in Europe.</p>
 <p>Generally, passing multiple values for a single parameter will result in a logical OR operation. For example, <code>GET /api/dcim/locations/?parent=north-america&amp;parent=south-america&amp;location_type=country</code> will return "country" type locations in North America <em>or</em> South America. However, a logical AND operation will be used in instances where a field may have multiple values, such as tags. For example, <code>GET /api/dcim/locations/?tag=foo&amp;tag=bar</code> will return only locations which have both the "foo" <em>and</em> "bar" tags applied.</p>
-<details class="version-changed">
-<summary>Changed in version 1.4.0 — <code>STRICT_FILTERING</code> by default</summary>
-<p>If <a href="../../administration/configuration/settings.html#strict_filtering"><code>STRICT_FILTERING</code></a> is True (its default value), unrecognized filter parameters now result in a 400 Bad Request response instead of being silently ignored.</p>
-</details>
 <h3 id="filtering-by-choice-field">Filtering by Choice Field<a class="headerlink" href="#filtering-by-choice-field" title="Permanent link">&para;</a></h3>
 <p>Some models have fields which are limited to specific choices, such as the <code>type</code> field on the Interface model. To find all available choices for this field, make an authenticated <code>OPTIONS</code> request to the model's list endpoint, and use <code>jq</code> to extract the relevant parameters:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>curl -s -X OPTIONS \
@@ -9433,10 +9426,6 @@
 <p>For custom field filters, due to historical details of implementation, only a single filter value can be specified when matching a given field. In other words, in the above example, you could <em>not</em> add <code>&amp;cf_foo=456</code> to the query in order to get all locations where custom field <code>foo</code> is 123 <em>or</em> 456; instead you would need to run two separate queries. This restriction does not apply to custom field filters using lookup expressions (next section) and will likely be changed in a future major version of Nautobot.</p>
 </div>
 <p>Custom fields can be mixed with built-in fields to further narrow results. When creating a custom string field, the type of filtering selected (loose versus exact) determines whether partial or full matching is used.</p>
-<details class="version-added">
-<summary>Added in version 1.4.0 — Custom field support for lookup expressions</summary>
-<p>Custom fields can now use the <a href="#lookup-expressions">lookup expressions</a> listed in the next section.</p>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.0.0 — Custom field filters changed from <code>name</code> to <code>key</code> based</summary>
 <p>Custom field filters are now based on the custom field <code>key</code> string (in 1.x they used the field's <code>name</code>).</p>
@@ -9484,9 +9473,6 @@
 <li><code>__isnull</code> - is null (only if this field is nullable, which most string fields in Nautobot are not)</li>
 </ul>
 <details class="version-added">
-<summary>Added in version 1.3.0 — Added regular expression lookup expressions</summary>
-</details>
-<details class="version-added">
 <summary>Added in version 2.1.0 — Added <code>__isnull</code> lookup expression</summary>
 </details>
 <h3 id="foreign-keys-other-fields">Foreign Keys &amp; Other Fields<a class="headerlink" href="#foreign-keys-other-fields" title="Permanent link">&para;</a></h3>