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

nautobot/project-static/docs/development/core/best-practices.html

@@ -8333,15 +8333,6 @@
       </ul>
     </nav>
   
-</li>
-      
-        <li class="md-nav__item">
-  <a href="#using-nautobotuiviewset-for-app-development" class="md-nav__link">
-    <span class="md-ellipsis">
-      Using NautobotUIViewSet for App Development
-    </span>
-  </a>
-  
 </li>
       
     </ul>
@@ -9578,15 +9569,6 @@
       </ul>
     </nav>
   
-</li>
-      
-        <li class="md-nav__item">
-  <a href="#using-nautobotuiviewset-for-app-development" class="md-nav__link">
-    <span class="md-ellipsis">
-      Using NautobotUIViewSet for App Development
-    </span>
-  </a>
-  
 </li>
       
     </ul>
@@ -9761,10 +9743,6 @@ For most purposes, this is not the case you are intending to check!</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-5-1" name="__codelineno-5-1" href="#__codelineno-5-1"></a><span class="kn">from</span> <span class="nn">nautobot.core.utils.lookup</span> <span class="kn">import</span> <span class="n">get_route_for_model</span>
 </code></pre></div>
 <p>This utility function supports both UI and API views for both Nautobot core apps and Nautobot Apps.</p>
-<details class="version-added">
-<summary>Added in version 1.4.3</summary>
-<p>Support for generating API routes was added to <code>get_route_for_model()</code> by passing the argument <code>api=True</code>.</p>
-</details>
 <h3 id="ui-routes">UI Routes<a class="headerlink" href="#ui-routes" title="Permanent link">&para;</a></h3>
 <p>Instead of:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-6-1" name="__codelineno-6-1" href="#__codelineno-6-1"></a><span class="n">route</span> <span class="o">=</span> <span class="sa">f</span><span class="s2">&quot;</span><span class="si">{</span><span class="n">model</span><span class="o">.</span><span class="n">_meta</span><span class="o">.</span><span class="n">app_label</span><span class="si">}</span><span class="s2">:</span><span class="si">{</span><span class="n">model</span><span class="o">.</span><span class="n">_meta</span><span class="o">.</span><span class="n">model_name</span><span class="si">}</span><span class="s2">_list&quot;</span>
@@ -10054,11 +10032,6 @@ For most purposes, this is not the case you are intending to check!</p>
 <li>For exceptions such as <code>DeviceFilterSet.has_primary_ip</code> where it checks for both <code>Device.primary_ip4</code> OR <code>Device.primary_ip6</code>, method filters may still be necessary, however, they would be <strong>the exception and not the norm.</strong></li>
 <li>The good news is that in the core there are not that many of these filter methods defined, but we also don’t want to see them continue to proliferate.</li>
 </ul>
-<h2 id="using-nautobotuiviewset-for-app-development">Using NautobotUIViewSet for App Development<a class="headerlink" href="#using-nautobotuiviewset-for-app-development" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-<p>Using <code>NautobotUIViewSet</code> for <a href="../apps/api/views/nautobotuiviewset.html">App development</a> is strongly recommended.</p>
-</details>
 
 
 

nautobot/project-static/docs/development/core/docker-compose-advanced-use-cases.html

@@ -8208,6 +8208,30 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Remote Debugging Configuration">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#running-inside-the-nautobot-workspace" class="md-nav__link">
+    <span class="md-ellipsis">
+      Running inside the Nautobot workspace
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#adding-nautobot-folder-to-an-existing-workspace" class="md-nav__link">
+    <span class="md-ellipsis">
+      Adding Nautobot folder to an existing workspace
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
         
       </ul>
@@ -9450,6 +9474,30 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Remote Debugging Configuration">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#running-inside-the-nautobot-workspace" class="md-nav__link">
+    <span class="md-ellipsis">
+      Running inside the Nautobot workspace
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#adding-nautobot-folder-to-an-existing-workspace" class="md-nav__link">
+    <span class="md-ellipsis">
+      Adding Nautobot folder to an existing workspace
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
         
       </ul>
@@ -9486,6 +9534,7 @@
 <li><code>compose_dir</code>: the full path to the directory containing the Docker Compose YAML files (default: <code>"&lt;nautobot source directory&gt;/development"</code>)</li>
 <li><code>compose_files</code>: the Docker Compose YAML file(s) to use (default: <code>["docker-compose.yml", "docker-compose.postgres.yml", "docker-compose.dev.yml"]</code>)</li>
 <li><code>docker_image_names_main</code> and <code>docker_image_names_develop</code>: Used when <a href="release-checklist.html#publish-docker-images">building Docker images for publication</a>; you shouldn't generally need to change these.</li>
+<li><code>ephemeral_ports</code>: Setting this value to <code>True</code> will make all Nautobot containers with published ports expose themselves with dynamic ports. This is useful when running multiple Nautobot versions at the same time on the same machine so you won't experience system port conflicts.</li>
 </ul>
 <p>These setting may be overridden several different ways (from highest to lowest precedence):</p>
 <ul>
@@ -9621,8 +9670,13 @@
 <li>As a last step open the folder <code>/opt/nautobot</code> in VS Code.</li>
 </ul>
 <h3 id="remote-debugging-configuration">Remote Debugging Configuration<a class="headerlink" href="#remote-debugging-configuration" title="Permanent link">&para;</a></h3>
-<p>Using the Remote-Attach functionality of VS Code debugger is an alternative to debugging in a development container. This allows a local VS Code instance to connect to a remote container and debug the code running in the container the same way as when debugging locally.</p>
-<p>Follow the steps below to configure VS Code to debug Nautobot and Celery Worker running in a remote container:</p>
+<p>Using the <a href="https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection">Remote-Attach functionality of VS Code</a> debugger is an alternative to debugging in a development container. This allows a local VS Code instance to connect to a remote container and debug the code running in the container the same way as when debugging locally. To learn more about debugging in VSCode, please <a href="https://code.visualstudio.com/docs/editor/debugging">follow the official docs</a>.</p>
+<p>Follow either of the options below to configure VS Code to debug Nautobot and Celery Worker running in a remote container:</p>
+<h4 id="running-inside-the-nautobot-workspace">Running inside the Nautobot workspace<a class="headerlink" href="#running-inside-the-nautobot-workspace" title="Permanent link">&para;</a></h4>
+<p>If you have opened the project via the workspace file <code>nautobot.code-workspace</code> then there are two debug configurations for remote debugging available. These can be run via one of the debug tasks:
+- <code>Python: Nautobot (Remote)</code> or
+- <code>Python: Nautobot-Celery (Remote)</code></p>
+<h4 id="adding-nautobot-folder-to-an-existing-workspace">Adding Nautobot folder to an existing workspace<a class="headerlink" href="#adding-nautobot-folder-to-an-existing-workspace" title="Permanent link">&para;</a></h4>
 <ol>
 <li>
 <p><strong>Configure <code>invoke.yml</code> to use the <code>docker-compose.vscode-rdb.yml</code> file.</strong></p>
@@ -9662,10 +9716,10 @@ then copy the <code>launch:</code> values to the <code>.vscode/launch.json</code
 <a id="__codelineno-9-12" name="__codelineno-9-12" href="#__codelineno-9-12"></a><span class="w">  </span><span class="p">]</span>
 <a id="__codelineno-9-13" name="__codelineno-9-13" href="#__codelineno-9-13"></a><span class="p">}</span>
 </code></pre></div>
-</li>
-</ol>
 <p>It is now possible to debug the containerized Nautobot and Celery Worker using the VS Code debugger.</p>
 <p>After restarting the Celery-Worker container you need to restart the debug session.</p>
+</li>
+</ol>
 
 
 

nautobot/project-static/docs/development/core/getting-started.html

@@ -10359,10 +10359,6 @@
 <p>You may install Poetry in your user environment by running:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-15-1" name="__codelineno-15-1" href="#__codelineno-15-1"></a>curl -sSL https://install.python-poetry.org | python3 -
 </code></pre></div>
-<details class="version-changed">
-<summary>Changed in version 1.5.6</summary>
-<p>Poetry 1.3+ is required to be able to install packages against the latest lockfile.</p>
-</details>
 <div class="admonition danger">
 <p class="admonition-title">Danger</p>
 <p>Always utilize this documented method to install Poetry for use when developing Nautobot.</p>
@@ -10549,7 +10545,7 @@
 <p>Do not use <code>poetry run nautobot-server runserver</code> as it will crash unless you also pass the <code>--noreload</code> flag, which somewhat defeats the purpose of using the development server. It is recommended to use <code>nautobot-server runserver</code> from within an active virtualenv (e.g. <code>poetry shell</code>). This is a <a href="https://github.com/python-poetry/poetry/issues/2435">known issue with Django and Poetry</a>.</p>
 </div>
 <p>Please see the <a href="https://docs.djangoproject.com/en/stable/ref/django-admin/#runserver">official Django documentation on <code>runserver</code></a> for more information.</p>
-<p>You can connect to the development server at <code>localhost:8080</code>.</p>
+<p>You can connect to the development server in your local web browser at <code>http://localhost:8080</code>. If you are using the ephemeral ports feature (disabled by default), you can make use of the command, <code>invoke open-nautobot-web</code>. This will open up the default web-browser on your system pointing to the correct Nautobot admin port. Note that this command can be used regardless of ephemeral port mode.</p>
 <h3 id="starting-the-worker-server">Starting the Worker Server<a class="headerlink" href="#starting-the-worker-server" title="Permanent link">&para;</a></h3>
 <p>In order to run Nautobot Jobs or anything that requires a worker you must start a Celery worker.</p>
 <p>The worker is started in Docker Workflow with <a href="https://pythonhosted.org/watchdog/">watchdog</a> and can be setup to be started with watchdog in the Virtual Environment Workflow. Watchdog provides a similar experience to the Django lightweight HTTP/WSGI for restarting your application automatically. Watchdog can watch for changes on your filesystem, this is helpful when adjusting existing Python files to not have to restart the Celery worker when testing jobs.</p>
@@ -10752,10 +10748,10 @@
 <p class="admonition-title">Tip</p>
 <p>You may also use <code>invoke integration-test</code> in the Virtual Environment workflow given that the <code>selenium</code> container is running, and that the <code>INVOKE_NAUTOBOT_LOCAL=True</code> environment variable has been set.</p>
 </div>
-<details class="version-changed">
-<summary>Changed in version 1.5.11</summary>
+<div class="admonition tip">
+<p class="admonition-title">Tip</p>
 <p>The <code>--cache-test-fixtures</code> argument was added to the <code>invoke integration-test</code> and <code>nautobot-server test</code> commands to allow for caching of test factory data between test runs. See the <a href="testing.html#factory-caching">factories documentation</a> for more information.</p>
-</details>
+</div>
 <h5 id="customizing-integration-test-executions">Customizing Integration Test Executions<a class="headerlink" href="#customizing-integration-test-executions" title="Permanent link">&para;</a></h5>
 <p>The following environment variables can be provided when running tests to customize where Nautobot looks for Selenium and where Selenium looks for Nautobot. If using the default setup documented above, there is no need to customize these.</p>
 <ul>
@@ -10845,27 +10841,27 @@
 <p>Some features require documentation updates or new documentation to be written. The documentation files can be found in the <code>docs</code> directory. To preview these changes locally, you can use <code>mkdocs</code>.</p>
 <p>For substantial changes to the code (including new features, removal of existing features, or significant changes in behavior) you should always make corresponding documentation updates. Nautobot's documentation pipeline includes a custom plugin for <code>mkdocs</code> that adds a few useful macros for annotating such changes:</p>
 <ul>
-<li><code>+++ 1.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-added "Added in version 1.4.3"</code></li>
-<li><code>+/- 1.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-changed "Changed in version 1.4.3"</code></li>
-<li><code>--- 1.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-removed "Removed in version 1.4.3"</code></li>
+<li><code>+++ 2.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-added "Added in version 2.4.3"</code></li>
+<li><code>+/- 2.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-changed "Changed in version 2.4.3"</code></li>
+<li><code>--- 2.4.3</code>, on a line by itself, is a shorthand for <code>!!! version-removed "Removed in version 2.4.3"</code></li>
 </ul>
 <p>These admonitions in turn appear in the rendered documentation as follows:</p>
 <details class="version-added">
-<summary>Added in version 1.4.3</summary>
+<summary>Added in version 2.4.3</summary>
 </details>
 <details class="version-changed">
-<summary>Changed in version 1.4.3</summary>
+<summary>Changed in version 2.4.3</summary>
 </details>
 <details class="version-removed">
-<summary>Removed in version 1.4.3</summary>
+<summary>Removed in version 2.4.3</summary>
 </details>
 <p>You can also add text to any of these admonitions for further clarity, for example:</p>
-<div class="highlight"><pre><span></span><code>??? version-added &quot;Added in version 1.4.3&quot;
+<div class="highlight"><pre><span></span><code>??? version-added &quot;Added in version 2.4.3&quot;
     The custom `mkdocs` plugin was added.
 </code></pre></div>
 <p>will render as:</p>
 <details class="version-added">
-<summary>Added in version 1.4.3</summary>
+<summary>Added in version 2.4.3</summary>
 <p>The custom <code>mkdocs</code> plugin was added.</p>
 </details>
 <div class="admonition caution">

nautobot/project-static/docs/development/core/homepage.html

@@ -9176,9 +9176,6 @@
 
 
 <h1 id="populating-the-home-page">Populating the Home Page<a class="headerlink" href="#populating-the-home-page" title="Permanent link">&para;</a></h1>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
-</details>
 <p>Both core applications and Apps can contribute items to the Nautobot home page by defining <code>layout</code> inside of their app's <code>homepage.py</code>. Using a key and weight system, a developer can integrate amongst existing home page panels or can create entirely new panels as desired.</p>
 <h2 id="adding-a-new-home-page-panel">Adding a new Home Page Panel<a class="headerlink" href="#adding-a-new-home-page-panel" title="Permanent link">&para;</a></h2>
 <p>Each panel on the home page is defined by a <code>HomePagePanel</code> object. A <code>HomePagePanel</code> may contain either or both of <code>HomePageItem</code> and/or <code>HomePageGroup</code> objects, or may define custom content via a referenced Django template. A <code>HomePageGroup</code> may itself contain <code>HomePageItem</code> objects as well, and individual <code>HomePageItem</code> objects may also reference custom Django templates.</p>

nautobot/project-static/docs/development/core/style-guide.html

@@ -9471,10 +9471,6 @@
 <li>
 <p>The combination of <code>nautobot.core.forms.BootstrapMixin</code>, <code>nautobot.extras.forms.CustomFieldModelFormMixin</code>, <code>nautobot.extras.forms.RelationshipModelFormMixin</code> and <code>nautobot.extras.forms.NoteModelFormMixin</code> is such a common use case throughout the code base that they have a helper class which combines all of these at <code>nautobot.extras.forms.NautobotModelForm</code>. Use this helper class if you need the functionality from these classes.</p>
 </li>
-</ul>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-<ul>
 <li>
 <p>Similarly, for filter forms, <code>nautobot.extras.forms.NautobotFilterForm</code> combines <code>nautobot.core.forms.BootstrapMixin</code>, <code>nautobot.extras.forms.ContactTeamModelFilterFormMixin</code> (since Nautobot 2.3.0), <code>nautobot.extras.forms.CustomFieldModelFilterFormMixin</code>, and <code>nautobot.extras.forms.RelationshipModelFilterFormMixin</code>, and should be used where appropriate.</p>
 </li>
@@ -9491,7 +9487,6 @@
 <p>API Views for most models should inherit from <code>nautobot.extras.api.views.NautobotModelViewSet</code>. Only use more abstract base classes such as <code>ModelViewSet</code> where absolutely required.</p>
 </li>
 </ul>
-</details>
 <h2 id="branding">Branding<a class="headerlink" href="#branding" title="Permanent link">&para;</a></h2>
 <ul>
 <li>When referring to Nautobot in writing, use the proper form "<code>Nautobot</code>," with the letter N. The lowercase form "<code>nautobot</code>" should be used in code, filenames, etc.</li>

nautobot/project-static/docs/development/core/templates.html

@@ -9308,9 +9308,6 @@ This document presents these templates and their features.</p>
 <p>You can use these templates as the basis for your templates by calling <code>{% extends '&lt;template_name&gt;' %}</code>
 at the top of your template file.</p>
 <h2 id="object-detail">Object Detail<a class="headerlink" href="#object-detail" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.2.0</summary>
-</details>
 <p>The most customizable template is <code>generic/object_retrieve.html</code>, as object detail views have a wide range of specific requirements to be accommodated. It provides the following blocks:</p>
 <ul>
 <li><code>header</code>: overloading this block allows for changing the entire top row of

nautobot/project-static/docs/development/core/testing.html

@@ -9549,9 +9549,6 @@
 <h3 id="troubleshooting-integration-tests">Troubleshooting Integration Tests<a class="headerlink" href="#troubleshooting-integration-tests" title="Permanent link">&para;</a></h3>
 <p>Because integration tests normally involve interacting with Nautobot through a browser via <a href="https://www.selenium.dev/selenium/docs/api/py/index.html">Selenium</a> and the <a href="https://splinter.readthedocs.io/en/latest/">Splinter</a> wrapper library, they can be difficult to troubleshoot directly from the Python code when a failure occurs. A common troubleshooting technique is to add a <code>breakpoint()</code> at the appropriate place in the Python test code (i.e., immediately prior to the observed failure). When the breakpoint is hit and the test pauses, you can then use a VNC viewer application (such as macOS's "Screen Sharing" app) to connect to the running Selenium instance (<code>localhost:15900</code> if using the Docker development environment; the default password if prompted is simply "<code>secret</code>"). This will allow you to interact live with the testing web browser in its current state and can often provide invaluable insight into the nature of any test failure.</p>
 <h2 id="factories">Factories<a class="headerlink" href="#factories" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <p>Nautobot uses the <a href="https://factoryboy.readthedocs.io/en/stable/"><code>factory_boy</code></a> library as a way to generate randomized but plausible database data for use in unit and integration tests, or for convenience in populating a local development instance.</p>
 <p>Factories for each Nautobot app's models are defined in the corresponding <code>nautobot/APPNAME/factory.py</code> files. Helper classes and functions for certain common patterns are defined in <code>nautobot/core/factory.py</code>. Factories can be used directly from <code>nautobot-server nbshell</code> so long as you have <code>factory_boy</code> installed. Examples:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="o">&gt;&gt;&gt;</span> <span class="kn">from</span> <span class="nn">nautobot.tenancy.factory</span> <span class="kn">import</span> <span class="n">TenantFactory</span><span class="p">,</span> <span class="n">TenantGroupFactory</span>
@@ -9580,9 +9577,6 @@
 <p>In short, we should only have one place in our tests where factories are called, and that's the <code>generate_test_data</code> management command. Individual tests should use standard <code>create()</code> or <code>save()</code> model methods, never factories.</p>
 </div>
 <h3 id="factory-caching">Factory Caching<a class="headerlink" href="#factory-caching" title="Permanent link">&para;</a></h3>
-<details class="version-added">
-<summary>Added in version 1.5.11</summary>
-</details>
 <p>To reduce the time taken between multiple test runs, a new argument has been added to the <code>nautobot-server test</code> command: <code>--cache-test-fixtures</code>. When running tests with <code>--cache-test-fixtures</code> for the first time, after the factory data has been generated it will be saved to a <code>factory_dump.json</code> file in the <code>development</code> directory. On subsequent runs of unit or integration tests, if <code>--cache-test-fixtures</code> is again specified (hint: it is included by default when running <code>invoke unittest</code> or <code>invoke integration-test</code>), the factory data will be loaded from the file instead of being generated again. This can significantly reduce the time taken to run tests.</p>
 <details class="version-changed">
 <summary>Changed in version 2.2.7 — Hashing of migrations in the factory dump</summary>
@@ -9601,9 +9595,6 @@
 </ol>
 </div>
 <h2 id="performance-tests">Performance Tests<a class="headerlink" href="#performance-tests" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <h3 id="running-performance-tests">Running Performance Tests<a class="headerlink" href="#running-performance-tests" title="Permanent link">&para;</a></h3>
 <p>Nautobot uses <a href="https://pypi.org/project/django-slowtests/"><code>django-slowtests</code></a> to run performance tests. To run performance tests, you need to install the <code>django-slowtests</code> package.
 Once you install the package, you can do <code>invoke performance-test</code> or <code>invoke unittest --performance-test</code> to run unit tests with <code>NautobotPerformanceTestRunner</code>. The invoke commands will automatically add <code>--testrunner nautobot.core.tests.runner.NautobotPerformanceTestRunner</code> to the <code>coverage run</code> command and this flag will replace the default <code>NautobotTestRunner</code> while retaining all its functionalities with the addition of performance evaluation after test runs.</p>

nautobot/project-static/docs/development/jobs/index.html

@@ -10100,9 +10100,6 @@ The checkbox to enable dryrun when executing a Job is unchecked by default in th
 <p>Default: <code>[]</code></p>
 <p>A list of strings (field names) representing the order your Job <a href="#variables">variables</a> should be rendered as form fields in the Job submission UI. If not defined, the variables will be listed in order of their definition in the code. If variables are defined on a parent class and no field order is defined, the parent class variables will appear before the subclass variables.</p>
 <h4 id="has_sensitive_variables"><code>has_sensitive_variables</code><a class="headerlink" href="#has_sensitive_variables" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.3.10</summary>
-</details>
 <p>Default: <code>True</code></p>
 <p>Unless set to False, it prevents the Job's input parameters from being saved to the database. This defaults to True so as to protect against inadvertent database exposure of input parameters that may include sensitive data such as passwords or other user credentials. Review whether each Job's inputs contain any such variables before setting this to False; if a Job <em>does</em> contain sensitive inputs, if possible you should consider whether the Job could be re-implemented using Nautobot's <a href="../../user-guide/platform-functionality/secret.html"><code>Secrets</code></a> feature as a way to ensure that the sensitive data is not directly provided as a Job variable at all.</p>
 <p>Important notes about Jobs with sensitive variables:</p>
@@ -10138,9 +10135,6 @@ A Boolean that if set to <code>True</code> prevents the job from running twice s
 <li>A checkbox on the job run form makes it possible to force the singleton lock to be overridden. This makes it possible to recover from failure scenarios such as the original singleton job being stopped before it can unset the lock.</li>
 </ul>
 <h4 id="read_only"><code>read_only</code><a class="headerlink" href="#read_only" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.1.0</summary>
-</details>
 <details class="version-changed">
 <summary>Changed in version 2.0.0 — No automatic functionality</summary>
 <p>The <code>read_only</code> flag no longer changes the behavior of Nautobot core and is up to the Job author to decide whether their Job should be considered read only.</p>
@@ -10148,9 +10142,6 @@ A Boolean that if set to <code>True</code> prevents the job from running twice s
 <p>Default: <code>False</code></p>
 <p>A boolean that can be set by the Job author to indicate that the Job does not make any changes to the environment. What behavior makes each Job "read only" is up to the individual Job author to decide. Note that user input may still be optionally collected with read-only Jobs via Job variables, as described below.</p>
 <h4 id="soft_time_limit"><code>soft_time_limit</code><a class="headerlink" href="#soft_time_limit" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>An int or float value, in seconds, which can be used to override the default <a href="../../user-guide/administration/configuration/settings.html#celery_task_soft_time_limit">soft time limit</a> for a Job task to complete.</p>
 <p>The <code>celery.exceptions.SoftTimeLimitExceeded</code> exception will be raised when this soft time limit is exceeded. The Job task can catch this to clean up before the <a href="../../user-guide/administration/configuration/settings.html#celery_task_time_limit">hard time limit</a> (10 minutes by default) is reached:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-7-1" name="__codelineno-7-1" href="#__codelineno-7-1"></a><span class="kn">from</span> <span class="nn">celery.exceptions</span> <span class="kn">import</span> <span class="n">SoftTimeLimitExceeded</span>
@@ -10171,9 +10162,6 @@ A Boolean that if set to <code>True</code> prevents the job from running twice s
 <a id="__codelineno-7-16" name="__codelineno-7-16" href="#__codelineno-7-16"></a>            <span class="n">cleanup_in_a_hurry</span><span class="p">()</span>
 </code></pre></div>
 <h4 id="task_queues"><code>task_queues</code><a class="headerlink" href="#task_queues" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.5.0</summary>
-</details>
 <p>Default: <code>[]</code></p>
 <p>A list of Job Queue names that the Job can be routed to. An empty list will default to only allowing the user to select the <a href="../../user-guide/administration/configuration/settings.html#celery_task_default_queue">default Celery queue</a> (<code>default</code> unless changed by an administrator). The queue specified in the Job's <code>default_job_queue</code> will be used if a queue is not specified in a Job run API call.</p>
 <details class="version-changed">
@@ -10185,9 +10173,6 @@ A Boolean that if set to <code>True</code> prevents the job from running twice s
 <p>A worker must be listening on the requested queue or the Job will not run. See the documentation on <a href="../../user-guide/administration/guides/celery-queues.html">task queues</a> for more information.</p>
 </div>
 <h4 id="template_name"><code>template_name</code><a class="headerlink" href="#template_name" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.4.0</summary>
-</details>
 <p>A path relative to the Job source code containing a Django template which provides additional code to customize the Job's submission form. This template should extend the existing Job template, <code>extras/job.html</code>, otherwise the base form and functionality may not be available.</p>
 <p>A template can provide additional JavaScript, CSS, or even display HTML. A good starting template would be:</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-8-1" name="__codelineno-8-1" href="#__codelineno-8-1"></a>{% extends &#39;extras/job.html&#39; %}
@@ -10211,9 +10196,6 @@ A Boolean that if set to <code>True</code> prevents the job from running twice s
 </details>
 <p>For another example checkout <a href="https://github.com/nautobot/nautobot/blob/main/examples/example_app/example_app/templates/example_app/example_with_custom_template.html">the template used in the Example App</a> in the GitHub repo.</p>
 <h4 id="time_limit"><code>time_limit</code><a class="headerlink" href="#time_limit" title="Permanent link">&para;</a></h4>
-<details class="version-added">
-<summary>Added in version 1.3.0</summary>
-</details>
 <p>An int or float value, in seconds, which can be used to override the
 default <a href="../../user-guide/administration/configuration/settings.html#celery_task_time_limit">hard time limit</a> (10 minutes by default) for a Job task to complete.</p>
 <p>Unlike the <code>soft_time_limit</code> above, no exceptions are raised when a <code>time_limit</code> is exceeded. The task will just terminate silently:</p>
@@ -10449,10 +10431,10 @@ Another example of using the nested reference would be to access <a href="../../
 </code></pre></div>
 </div>
 <p>Markdown rendering is supported for log messages, as well as <a href="../../user-guide/platform-functionality/template-filters.html#render_markdown">a limited subset of HTML</a>.</p>
-<details class="version-changed">
-<summary>Changed in version 1.3.4 — Log entry sanitization</summary>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
 <p>As a security measure, the <code>message</code> passed to any of these methods will be passed through the <code>nautobot.core.utils.logging.sanitize()</code> function in an attempt to strip out information such as usernames/passwords that should not be saved to the logs. This is of course best-effort only, and Job authors should take pains to ensure that such information is not passed to the logging APIs in the first place. The set of redaction rules used by the <code>sanitize()</code> function can be configured as <a href="../../user-guide/administration/configuration/settings.html#sanitizer_patterns"><code>settings.SANITIZER_PATTERNS</code></a>.</p>
-</details>
+</div>
 <details class="version-changed">
 <summary>Changed in version 2.0.0 — Significant API changes</summary>
 <p>The Job class logging functions (example: <code>self.log(message)</code>, <code>self.log_success(obj=None, message=message)</code>, etc) have been removed. Also, the convenience method to mark a Job as failed, <code>log_failure()</code>, has been removed. To replace the functionality of this method, you can log an error message with <code>self.logger.error()</code> and then raise an exception to fail the Job. Note that it is no longer possible to manually set the Job Result status as failed without raising an exception in the Job.</p>
@@ -10512,11 +10494,6 @@ Another example of using the nested reference would be to access <a href="../../
 <h2 id="testing-jobs">Testing Jobs<a class="headerlink" href="#testing-jobs" title="Permanent link">&para;</a></h2>
 <p>Jobs are Python code and can be tested as such, usually via <a href="https://docs.djangoproject.com/en/stable/topics/testing/">Django unit-test features</a>. That said, there are a few useful tricks specific to testing Jobs.</p>
 <p>While individual methods within your Job can and should be tested in isolation, you'll likely also want to test the entire execution of the Job.</p>
-<details class="version-added">
-<summary>Added in version 1.3.3</summary>
-<p>Entire Job execution testing was only introduced in 1.3.3 and newer.
-However the import paths used in the examples requires 1.5.2 and newer.</p>
-</details>
 <p>The simplest way to test the entire execution of Jobs is via calling the <code>nautobot.apps.testing.run_job_for_testing()</code> method, which is a helper wrapper around the <code>JobResult.enqueue_job</code> function used to execute a Job via Nautobot's Celery worker process.</p>
 <p>Because of the way <code>run_job_for_testing</code> and more specifically Celery tasks work, which is somewhat complex behind the scenes, you need to inherit from <code>nautobot.apps.testing.TransactionTestCase</code> instead of <code>django.test.TestCase</code> (Refer to the <a href="https://docs.djangoproject.com/en/stable/topics/testing/tools/#provided-test-case-classes">Django documentation</a> if you're interested in the differences between these classes - <code>TransactionTestCase</code> from Nautobot is a small wrapper around Django's <code>TransactionTestCase</code>).</p>
 <p>When using <code>TransactionTestCase</code> (whether from Django or from Nautobot) each tests runs on a completely empty database. Furthermore, Nautobot requires new Jobs to be enabled before they can run. Therefore, we need to make sure the Job is enabled before each run which <code>run_job_for_testing</code> handles for us.</p>
@@ -10547,9 +10524,6 @@ However the import paths used in the examples requires 1.5.2 and newer.</p>
 <p>For more advanced examples refer to the Nautobot source code, specifically <code>nautobot/extras/tests/test_jobs.py</code>.</p>
 </div>
 <h2 id="debugging-job-performance">Debugging Job Performance<a class="headerlink" href="#debugging-job-performance" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.5.17</summary>
-</details>
 <p>Debugging the performance of Nautobot Jobs can be tricky, because they are executed in the worker context. In order to gain extra visibility, <a href="https://docs.python.org/3/library/profile.html">cProfile</a> can be used to profile the Job execution.</p>
 <p>The 'profile' form field on Jobs is automatically available when the <code>DEBUG</code> settings is <code>True</code>. When you select that checkbox, a profiling report in the pstats format will be written to the file system of the environment where the Job runs. Normally, this is on the file system of the worker process, but if you are using the <code>nautobot-server runjob</code> command with <code>--local</code>, it will end up in the file system of the web application itself. The path of the written file will be logged in the Job.</p>
 <div class="admonition note">

nautobot/project-static/docs/overview/application_stack.html

@@ -9293,24 +9293,6 @@
 <h2 id="getting-started">Getting Started<a class="headerlink" href="#getting-started" title="Permanent link">&para;</a></h2>
 <p>See the <a href="../user-guide/administration/installation/index.html">installation guide</a> for help getting Nautobot up and running quickly.</p>
 <h2 id="dependency-history">Dependency History<a class="headerlink" href="#dependency-history" title="Permanent link">&para;</a></h2>
-<details class="version-added">
-<summary>Added in version 1.1.0 — MySQL support</summary>
-<p>MySQL support was added.</p>
-</details>
-<details class="version-changed">
-<summary>Changed in version 1.3.0 — Python 3.6, Python 3.10</summary>
-<ul>
-<li>Python 3.6 support was removed.</li>
-<li>Python 3.10 support was added.</li>
-</ul>
-</details>
-<details class="version-changed">
-<summary>Changed in version 1.6.0 — Python 3.7, Python 3.11</summary>
-<ul>
-<li>Python 3.7 support was removed.</li>
-<li>Python 3.11 support was added.</li>
-</ul>
-</details>
 <details class="version-removed">
 <summary>Removed in version 2.0.0 — <code>django-rq</code> and <code>django-cacheops</code></summary>
 <ul>