nautobot 2.0.4__py3-none-any.whl → 2.1.0b1__py3-none-any.whl

nautobot/docs/user-guide/platform-functionality/graphqlquery.md

@@ -1,28 +0,0 @@
-# GraphQL Queries
-
-Nautobot provides the ability to store GraphQL queries in the database for simple maintaining and re-running.
-
-## Saved Query Views
-
-Navigate to Extensibility > Data Management > GraphQL Queries under the navigation bar. Located here are the views to manage saved query objects in the database.
-
-When queries get saved to the database from the form, the query is first loaded into GraphQL to ensure that syntax is correct. If there is an issue with the query, an error message is displayed below the textarea.
-
-## GraphiQL Interface
-
-Modifications have been made to the GraphiQL page to allow the running, editing and saving of this model.
-
-A dropdown button called "Queries" has been added to the GraphiQL toolbar. This lists all saved queries in the database allowing the user to open them into GraphiQL.
-
-If a saved query has been opened, a button will appear next to the name inside the "Queries" dropdown called "Save Changes". This allows the user to save any changes to the model object.
-
-If the user wants to create a new query, at the bottom of the "Queries" tab there is an option called "Save Current Query As...". This will open a modal form to input data, such as the name of the query, and then save the query to the database.
-
-## API Endpoint
-
-An API endpoint has be created to allow running of saved queries through a simple POST request.
-
-* Request: `POST`
-* URL: `{server_address}/api/extras/graphql-queries/{uuid}/run/`
-* Content-type: `application/json`
-* Body: JSON of query variables `{"variable_1": "value_1", "variable_2": "value_2"}`

nautobot/docs/user-guide/platform-functionality/imageattachment.md

@@ -1,10 +0,0 @@
-# Image Attachments
-
-Certain objects in Nautobot support the attachment of uploaded images. These will be saved to the Nautobot server and made available whenever the object is viewed.
-
-The location of where image attachments are stored can be customized using the [`MEDIA_ROOT`](../administration/configuration/optional-settings.md#media_root) setting in your `nautobot_config.py`.
-
-Currently, the following types of image attachments can be stored in Nautobot:
-
-- Device type images are stored at `$MEDIA_ROOT/devicetype-images`
-- Generic image attachments are stored at `$MEDIA_ROOT/image-attachments`

nautobot/docs/user-guide/platform-functionality/jobs/index.md

@@ -1,193 +0,0 @@
-# Jobs
-
-Jobs are a way for users to execute custom logic on demand from within the Nautobot UI. Jobs can interact directly with Nautobot data to accomplish various data creation, modification, and validation tasks, such as:
-
-* Automatically populate new devices and cables in preparation for a new location deployment
-* Create a range of new reserved prefixes or IP addresses
-* Fetch data from an external source and import it to Nautobot
-* Check and report whether all top-of-rack switches have a console connection
-* Check and report whether every router has a loopback interface with an assigned IP address
-* Check and report whether all IP addresses have a parent prefix
-
-...and so on. Jobs are Python code and exist outside of the official Nautobot code base, so they can be updated and changed without interfering with the core Nautobot installation. And because they're completely customizable, there's practically no limit to what a job can accomplish.
-
-+/- 2.0.0
-    Backwards compatibility with NetBox scripts and reports has been removed. This includes removal of automatic calls to the `post_run()` and `test_*()` methods.
-
-!!! note
-    Jobs unify and supersede the functionality previously provided in NetBox by "custom scripts" and "reports". User input is supported via [job variables](../../../development/jobs/index.md#variables).
-
-## Managing Jobs
-
-As of Nautobot 1.3, each Job class installed in Nautobot is represented by a corresponding Job data record in the Nautobot database. These data records are refreshed when the `nautobot-server migrate` or `nautobot-server post_upgrade` command is run, or (for Jobs from a Git repository) when a Git repository is enabled or re-synced in Nautobot. These data records make it possible for an administrative user (or other user with appropriate access privileges) to exert a level of administrative control over the Jobs created and updated by Job authors.
-
-### Enabling Jobs for Running
-
-When a new Job record is created for a newly discovered Job class, it defaults to `enabled = False`, which prevents the Job from being run by any user. This is intended to provide a level of security and oversight regarding the installation of new Jobs into Nautobot.
-
-!!! important
-    One exception to this default is when upgrading from a Nautobot release before 1.3 to Nautobot 1.3.0 or later. In this case, at the time of the upgrade, any Job class that shows evidence of having been run or scheduled under the older Nautobot version (that is, there is at least one JobResult and/or ScheduledJob record that references this Job class) will result in the creation of a Job database record with `enabled = True`. The reasoning for this feature is the assertion that because the Job has been run or scheduled previously, it has presumably already undergone appropriate review at that time, and so it should remain possible to run it as it was possible before the upgrade.
-
-An administrator or user with `extras.change_job` permission can edit the Job to change it to `enabled = True`, permitting running of the Job, when they have completed any appropriate review of the new Job to ensure that it meets their standards. Similarly, an obsolete or no-longer-used Job can be prevented from inadvertent execution by changing it back to `enabled = False`.
-
- By default when a Job is installed into Nautobot it is installed in a disabled state. In order to enable a Job:
-
-* Navigate to Jobs > Jobs menu
-* Select a job that has been installed
-* Select **Edit** button
-* In the second section titled **Job**, select the **Enabled** checkbox
-* Select **Update** button at the bottom
-
-#### Enabling Job Hooks
-
- Job hooks are enabled in a similar fashion, but by using the **default** filters when navigating to the Jobs page the Job Hooks will not be visible. To enable job hooks:
-
-* Navigate to Jobs > Jobs menu
-* Select the **Filter** button to bring up the Filter Jobs context
-* Look for **Is job hook receiver** and change the drop down to **Yes**
-* Select **Apply** button
-* Select a job that has been installed
-* Select **Edit** button
-* In the second section titled **Job**, select the **Enabled** checkbox
-* Select **Update** button at the bottom
-
-### Overriding Metadata
-
-An administrator or user with `extras.change_job` permission can also edit a Job database record to optionally override any or all of the following metadata attributes defined by the Job module or class:
-
-* `grouping`
-* `name`
-* `description`
-* `approval_required`
-* `dryrun_default`
-* `has_sensitive_variables`
-* `hidden`
-* `soft_time_limit`
-* `time_limit`
-* `task_queues`
-
-This is done by setting the corresponding "override" flag (`grouping_override`, `name_override`, etc.) to `True` then providing a new value for the attribute in question. An overridden attribute will remain set to its overridden value even if the underlying Job class definition changes and `nautobot-server <migrate|post_upgrade>` gets run again. Conversely, clearing the "override" flag for an attribute and saving the database record will revert the attribute to the underlying value defined within the Job class source code.
-
-### Deleting Jobs
-
-When a previously installed Job class is removed, after running `nautobot-server <migrate|post_upgrade>` or refreshing the providing Git repository, the Job database record will *not* be automatically deleted, but *will* be flagged as `installed = False` and can no longer be run or scheduled.
-
-An administrator or user with `extras.delete_job` permissions *may* delete such a Job database record if desired, but be aware that doing so will result in any existing JobResult or ScheduledJob records that originated from this Job losing their association to the Job; this association will not be automatically restored even if the Job is later reinstalled or reintroduced.
-
-## Running Jobs
-
-!!! note
-    To run any job, a user must be assigned the `extras.run_job` permission. This is achieved by assigning the user (or group) a permission on the `extras > job` object and specifying the `run` action in the admin UI as shown below.
-
-    Similarly, to [approve a job request by another user](./job-scheduling-and-approvals.md), a user must be assigned the `extras.approve_job` permission via the same process. Job approvers also need the `extras.change_scheduledjob` and/or `extras.delete_scheduledjob` permissions as job approvals are implemented via the `ScheduledJob` data model.
-
-    ![Adding the run action to a permission](../../../media/admin_ui_run_permission.png)
-
-### Jobs and `class_path`
-
-+/- 2.0.0
-    The `class_path` concept has been simplified compared to Nautobot 1.x.
-
-It is a key concept to understand the 2 `class_path` elements:
-
-* `module_name`: which is the importable Python path to the job definition (with `.` in place of `/` in the directory path, and not including the `.py` file extension, as per Python syntax standards).
-    * For a plugin-provided job, this might be something like `my_plugin_name.jobs.my_job_filename` or `nautobot_golden_config.jobs`
-    * For a locally installed job, this would match the file name, such as `my_job_filename`
-    * For a Git-provided job, this includes the repository's defined `slug`, such as `my_repository.jobs.my_job_filename`
-* `JobClassName`: which is the name of the class inheriting from `nautobot.extras.jobs.Job` contained in the above file.
-
-The `class_path` is often represented as a string in the format of `<module_name>.<JobClassName>`, such as `example.MyJobWithNoVars` or `nautobot_golden_config.jobs.BackupJob`. Understanding the definitions of these elements will be important in running jobs programmatically.
-
-+/- 1.3.0
-    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 `class_path`.
-
-+/- 2.0.0
-    The Job database model `name` field is now enforced to be globally unique and so is also an option for uniquely identifying Job records.
-
-### Via the Web UI
-
-Jobs can be run via the web UI by navigating to the job, completing any required form data (if any), and clicking the "Run Job" button.
-
-Once a job has been run, the latest [`JobResult`](./models.md#job-results) for that job will be summarized in the job list view.
-
-### Via the REST API
-
---- 2.0.0
-    The `commit` parameter was removed. All job input should be provided via the `data` parameter.
-
-To run a job via the REST API, issue a POST request to the job's endpoint `/api/extras/jobs/<uuid>/run/` **or** `/api/extras/jobs/<name>/run/`. You can optionally provide JSON data to specify any required user input `data`, optional `task_queue`, and/or provide optional scheduling information as described in [the section on scheduling and approvals](./job-scheduling-and-approvals.md).
-
-+++ 2.0.0
-    The `/api/extras/jobs/<name>/` REST API endpoints were added as an alternative to `/api/extras/jobs/<uuid>/`.
-
-For example, to run a job, by UUID, with no user inputs:
-
-```no-highlight
-curl -X POST \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; version=1.3; indent=4" \
-http://nautobot/api/extras/jobs/$JOB_ID/run/
-```
-
-Or to run a job, by name, that expects user inputs:
-
-```no-highlight
-curl -X POST \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; version=1.3; indent=4" \
-http://nautobot/api/extras/jobs/$JOB_NAME/run/ \
---data '{"data": {"string_variable": "somevalue", "integer_variable": 123}}'
-```
-
-When providing input data, it is possible to specify complex values contained in `ObjectVar`s, `MultiObjectVar`s, and `IPAddressVar`s.
-
-* `ObjectVar`s can be specified by either using their primary key directly as the value, or as a dictionary containing a more complicated query that gets passed into the Django ORM as keyword arguments.
-* `MultiObjectVar`s can be specified as a list of primary keys.
-* `IPAddressVar`s can be provided as strings in CIDR notation.
-
-#### Jobs with Files
-
-To run a job that contains `FileVar` inputs via the REST API, you must use `multipart/form-data` content type requests instead of `application/json`. This also requires a slightly different request payload than the example above. The `task_queue` and `schedule` data are flattened and prefixed with underscore to differentiate them from job-specific data. Job specific data is also flattened and not located under the top-level `data` dictionary key.
-
-An example of running a job with both `FileVar` (named `myfile`) and `StringVar` (named `interval`) input:
-
-```no-highlight
-curl -X POST \
--H 'Authorization: Token $TOKEN' \
--H 'Content-Type: multipart/form-data' \
--H "Accept: application/json; version=1.3; indent=4" \
-'http://nautobot/api/extras/jobs/$JOB_NAME/run/' \
--F '_schedule_interval="immediately"' \
--F '_schedule_start_time="2022-10-18T17:31:23.698Z"' \
--F 'interval="3"' \
--F 'myfile=@"/path/to/my/file.txt"' \
-```
-
-### Via the CLI
-
-Jobs can be run from the CLI by invoking the management command:
-
-```no-highlight
-nautobot-server runjob [--username <username>] [--local] [--data <data>] <class_path>
-```
-
-!!! note
-    [See above](#jobs-and-class_path) for `class_path` definitions.
-
-+++ 1.3.10
-    The `--data` and `--local` parameters were added.
-
-    The `--data` parameter must be a JSON string, e.g. `--data='{"string_variable": "somevalue", "integer_variable": 123}'`
-
-Using the same example shown in the API:
-
-```no-highlight
-nautobot-server runjob --username myusername example.MyJobWithNoVars
-```
-
-!!! warning
-    The `--username <username>` must be supplied to specify the user that will be identified as the requester of the job.
-
-    Note that `nautobot-server` commands, like all management commands and other direct interactions with the Django database, are not gated by the usual Nautobot user authentication flow. It is possible to specify any existing `--username` with the `nautobot-server runjob` command in order to impersonate any defined user in Nautobot. Use this power wisely and be cautious who you allow to access it.

nautobot/docs/user-guide/platform-functionality/jobs/job-scheduling-and-approvals.md

@@ -1,78 +0,0 @@
-# Job Scheduling and Approvals
-
-+++ 1.2.0
-
-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.
-
-## Job Scheduling
-
-Jobs can be scheduled to be run immediately, at some point in the future, or at an interval.
-
-Jobs can be scheduled through the UI or the API.
-
-!!! warning
-    A Job **must** be [enabled](./index.md#enabling-jobs-for-running) and cannot have [has_sensitive_variables](./index.md#hassensitivevariables) set to `True` in order to be scheduled. If these requirements are not met, a warning banner will appear on the run Job view with the reason why Job Scheduling is not an option.
-
-### Scheduling via the UI
-
-The Job Scheduling views can be accessed via the navigation at `Jobs > Jobs`, selecting a Job as appropriate.
-
-The UI allows you to select a scheduling type. Further fields will be displayed as appropriate for that schedule type.
-
-If `Recurring custom` is chosen, you can schedule the recurrence in the `Crontab` field in [crontab](https://en.wikipedia.org/wiki/Cron#Overview) syntax.
-
-If the job requires no approval, it will then be added to the queue of scheduled jobs or run immediately. Otherwise, the job will be added to the approval queue where it can be approved by other users.
-
-### Scheduling via the API
-
-Jobs can also be scheduled via the REST API. The endpoint used for this is the regular job endpoint; specifying the optional `schedule` parameter will act just as scheduling in the UI.
-
-```no-highlight
-curl -X POST \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; version=1.3; indent=4" \
-http://nautobot/api/extras/jobs/$JOB_ID/run/ \
---data '{"schedule": {"name": "test", "interval": "future", "start_time": "2030-01-01T01:00:00.000Z"}}'
-```
-
-For custom interval, a `crontab` parameter must be added.
-
-`start_time` becomes optional when `interval` is set to `custom`.
-
-`--data '{"schedule": {"name": "test", "interval": "custom", "start_time": "2030-01-01T01:00:00.000Z", "crontab": "*/15 * * * *"}}'`
-
-## Job Approvals
-
-Jobs that have `approval_required` set to `True` on their `Meta` object require another user to approve a scheduled job.
-
-!!! warning
-    Requiring approval for execution of Job Hooks by setting the `Meta.approval_required` attribute to `True` on your `JobHookReceiver` 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.
-
-Scheduled jobs can be approved or denied via the UI and API by any user that has the `extras.approve_job` permission for the job in question, as well as the appropriate `extras.change_scheduledjob` and/or `extras.delete_scheduledjob` permissions.
-
-+/- 1.3.0
-    The `extras.approve_job` permission is now required for job approvers.
-
-!!! note
-    Jobs that are past their scheduled run date can still be approved, but the approver will be asked to confirm the operation.
-
-### Approval via the UI
-
-The queue of jobs that need approval can be found under `Jobs > Job Approval Queue`. This view lists all currently requested jobs that need approval before they are run. To approve a job, select it and click the button to approve. Please note that you will be  asked for confirmation if a job is being approved that is past its scheduled date and time.
-
-If the approver is unsure what a job would do, a dry run can also be started via that same view.
-
-### Approval via the API
-
-Approvals can also be given via the REST API. The endpoints to approve, deny, and dry run a scheduled job are found on the scheduled job endpoint under `approve`, `deny`, and `dry-run`, respectively.
-
-```no-highlight
-curl -X POST \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; version=1.3; indent=4" \
-http://nautobot/api/extras/scheduled-jobs/$JOB_ID/approve?force=true
-```
-
-The approval endpoint additionally provides a `force` query parameter that needs to be set if a job is past its scheduled datetime. This mimics the confirmation dialog in the UI.

nautobot/docs/user-guide/platform-functionality/jobs/jobbutton.md

@@ -1,79 +0,0 @@
-# Job Buttons
-
-+++ 1.5.14
-
-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.
-
-Job Buttons can be created in web UI located in the navbar under Jobs > 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 [context data](#context-data) to dynamically update or [even be hidden under certain conditions](#conditional-rendering).
-
-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 `weight` with the lowest `weight` 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 `weight` in the group and will be sorted from top to bottom with the lowest `weight` button on top.
-
-## Configuration
-
-* **Name** - A unique name for the Job Button.
-* **Object type(s)** - The type or types of Nautobot object that the button will be associated to.
-* **Text** - The text that will be displayed on the button.
-* **Job** - The [Job Button Receiver](../../../development/jobs/index.md#job-button-receivers) that this button will run.
-* **Weight** - The number used for determining the order the buttons will appear.
-* **Group** - The name of the dropdown group to add this button into (optional).
-* **Button Class** - The button CSS class, which dictates the color.
-* **Confirmation** - Should the button pop up a confirmation dialog before running.
-
-!!! warning
-    As you can see, there is no `commit` option for a Job Button like there is for a normal Job. All Job Buttons will run with `commit=True` **implicitly**.
-
-![Job Button Form](../../../media/models/jobbutton_form.png "Job Button Form")
-
-For any Job that is loaded into Nautobot, the Job must be enabled to run. See [Enabling Jobs for Running](./index.md#enabling-jobs-for-running) for more details.
-
-## Required Permissions
-
-!!! note
-    In order to run any job via a Job Button, a user must be assigned the `extras.run_job` **as well as** the `extras.run_jobbutton` permissions. This is achieved by assigning the user (or group) a permission on the `extras > job` and `extras > jobbutton` objects and specifying the `run` action in the **Additional actions** section. Any user lacking these permissions may still see the button on the respective page(s) - if not using [conditional rendering](#conditional-rendering) - but they will be disabled.
-
-## Context Data
-
-The following context data is available within the template when rendering a Job Button's text.
-
-| Variable  | Description                                                                                                       |
-| --------- | ----------------------------------------------------------------------------------------------------------------- |
-| `obj`     | The Nautobot object being displayed                                                                               |
-| `debug`   | A boolean indicating whether debugging is enabled                                                                 |
-| `request` | The current WSGI request                                                                                          |
-| `user`    | The current user (if authenticated)                                                                               |
-| `perms`   | The [permissions](https://docs.djangoproject.com/en/stable/topics/auth/default/#permissions) assigned to the user |
-
-All [built-in Jinja2 filters](../template-filters.md) are available and it's also possible to [develop and register custom Jinja2 filters](../../../development/apps/api/platform-features/jinja2-filters.md).
-
-## Conditional Rendering
-
-Only buttons which render with non-empty text are included on the page. You can employ conditional Jinja2 logic to control the conditions under which a button gets rendered.
-
-For example, if you only want to display a button for active devices, you could set the button text to
-
-```jinja2
-{% if obj.status.name == 'Active' %}Provision{% endif %}
-```
-
-The button will not appear when viewing a device with any status other than `Active`.
-
-As another example, if you wanted to show only devices belonging to a certain manufacturer, you could do something like this:
-
-```jinja2
-{% if obj.device_type.manufacturer.name == 'Cisco' %}Provision{% endif %}
-```
-
-The button will only appear when viewing a device with a manufacturer name of `Cisco`.
-
-As a last example, you can hide the button for users that lack the proper permissions to run a job like this:
-
-```jinja2
-{% if perms.extras.run_job %}Provision{% endif %}
-```
-
-The button will only appear if they have the permission to run jobs.
-
-![Job Buttons on Location object](../../../media/models/site_jobbuttons.png "Job Buttons on Location object")
-
-!!! note
-    To access custom fields of an object within a template, use the `cf` attribute. For example, `{{ obj.cf.color }}` will return the value (if any) for the custom field with a key of `color` on `obj`.

nautobot/docs/user-guide/platform-functionality/jobs/jobhook.md

@@ -1,15 +0,0 @@
-# Job Hooks
-
-+++ 1.4.0
-
-A Job Hook is a mechanism for automatically starting a [job](./index.md) when an object is changed. Job Hooks are similar to [webhooks](../webhook.md) except that an object change event initiates a `JobHookReceiver` job instead of a web request. Job hooks are configured in the web UI under **Jobs > Job Hooks**.
-
-## Configuration
-
-* **Name** - A unique name for the job hook.
-* **Content type(s)** - The type or types of Nautobot object that will trigger the job hook.
-* **Job** - The [job hook receiver](../../../development/jobs/index.md#job-hook-receivers) that this job hook will run.
-* **Enabled** - If unchecked, the job hook will be inactive.
-* **Events** - A job hook may trigger on any combination of create, update, and delete events. At least one event type must be selected.
-
-For any Job that is loaded into Nautobot, the Job must be enabled to run. See [Enabling Jobs for Running](./index.md#enabling-jobs-for-running) for more details.

nautobot/docs/user-guide/platform-functionality/jobs/models.md

@@ -1,65 +0,0 @@
-# Job Models
-
-## Job
-
-+++ 1.3.0
-
-The Job data model provides a database representation of metadata describing a specific installed Job. It also serves as an anchor point for other data models (JobResult and ScheduledJob in particular) to link against.
-
-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. `grouping`) and also setting the corresponding `override` flag (e.g. `grouping_override`) to `True`. If the `override` flag for a field is cleared (set back to `False`) then the corresponding flag will automatically revert to the original value defined by the Job class source code when the record is saved.
-
-!!! note
-    For metadata fields that are not explicitly overridden, changes in the job source code will be detected and reflected in the corresponding database records when `nautobot-server migrate` or `nautobot-server post_upgrade` is next run; changes are not detected "live" while the server is running.
-
-    For jobs stored in Git repositories, re-syncing the Git repository will also refresh the Job records corresponding to this repository.
-
-Records of this type store the following data as read-only (not modifiable via the UI or REST API):
-
-* The source of the job (local installation, Git repository, plugin)
-* The name of the module containing the Job
-* The name of the Job class
-* Whether the job is installed presently
-* Whether the job is read-only
-* Whether the job is a [Job Hook Receiver](jobhook.md#job-hook-receivers)
-* Whether the job is a [Job Button Receiver](jobbutton.md#job-button-receivers)
-
-!!! note
-    As presently implemented, after a job is uninstalled, when the database is next refreshed, the corresponding Job database record will *not* be deleted - only its `installed` flag will be set to False. This allows existing `JobResult` and `ScheduledJob` records to continue to reference the Job that they originated from.
-
-    An administrator or sufficiently privileged user can manually delete uninstalled Job records if desired, though this will result in the foreign-key from the corresponding `JobResult` and `ScheduledJob` records (if any exist) becoming null. In any case, for tracking and auditing purposes, deleting a Job does **not** automatically delete its related `JobResult` and `ScheduledJob` records.
-
-For any Job that is loaded into Nautobot, the Job must be enabled to run. See [Enabling Jobs for Running](./index.md#enabling-jobs-for-running) for more details.
-
-## Job Log Entry
-
-+++ 1.2.0
-
-Log messages from [Jobs](./index.md) are stored in as `JobLogEntry` objects. This allows more performant querying of log messages and even allows viewing of logs while the job is still running.
-
-Records of this type store the following data:
-
-* A reference to the `JobResult` object that created the log.
-* Timestamps indicating when the log message was created.
-* The logging level of the log message.
-* The log message.
-* If provided, the string format of the logged object and it's absolute url.
-
-+++ 1.2.2
-    REST API and GraphQL support for querying `JobLogEntry` records were added.
-
-## Job Results
-
-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.
-
-Records of this type store the following data:
-
-* A reference to the job model that the task was associated with
-* A reference to the user who initiated the task
-* If initiated by a scheduled job, a reference to that scheduled job instance
-* The arguments that were passed to the task (allowing for later queuing of the task for re-execution if desired)
-* Timestamps indicating when the task was created and when it completed
-* An overall status such as "pending", "running", "errored", or "completed".
-* A block of structured data representing the return value from the `.run()` method (often rendered as JSON).
-
-+/- 1.2.0
-    Note that prior to Nautobot 1.2, job log records were stored in the `data` field; they are now stored as distinct [`JobLogEntry`](#job-log-entry) records instead.

nautobot/docs/user-guide/platform-functionality/napalm.md

@@ -1,85 +0,0 @@
-# NAPALM
-
-Nautobot supports integration with the [NAPALM automation](https://github.com/napalm-automation/napalm/) library. NAPALM allows Nautobot to serve a proxy for operational data, fetching live data from network devices and returning it to a requester via its REST API. Note that Nautobot does not store any NAPALM data locally.
-
-!!! note
-    To enable this integration, the NAPALM library must be installed. See [installation steps](../administration/installation/nautobot.md#configuring-napalm) for more information.
-
-Below is an example REST API request and response:
-
-```no-highlight
-GET /api/dcim/devices/1/napalm/?method=get_environment
-
-{
-    "get_environment": {
-        ...
-    }
-}
-```
-
-!!! note
-    To make NAPALM requests via the Nautobot REST API, a Nautobot user must have assigned a permission granting the `napalm_read` action for the device object type.
-
-## Authentication
-
-As of Nautobot 1.2, there are three ways to specify the authentication credentials to use for a given device:
-
-1. `NAPALM_USERNAME` and `NAPALM_PASSWORD` configuration parameters, setting global defaults to use for all devices.
-2. Assigning an appropriately defined [secrets group](./secret.md#secret-groups) to the device to specify its specific credentials.
-3. In a REST API call, specifying the credentials as HTTP headers.
-
-### Configuration Parameters
-
-By default, the [`NAPALM_USERNAME`](../administration/configuration/optional-settings.md#napalm_username) and [`NAPALM_PASSWORD`](../administration/configuration/optional-settings.md#napalm_password) configuration parameters are used for NAPALM authentication.
-
-### Secrets Groups
-
-If a given device has an associated secrets group, and that secrets group contains [secrets](./secret.md) assigned as *access type* `Generic` and *secrets types* `Username` and `Password` (and optionally an additional `Secret` entry as well, which will be used for a Cisco enable secret as needed), these credentials will be used for NAPALM authentication, overriding any global defaults specified in `nautobot_config.py`.
-
-Note that in the case where many devices in your network share common credentials (such as a standardized service account), it's straightforward to define an appropriate secrets group and then use the device "bulk editing" functionality in Nautobot to quickly assign this group to a collection of devices.
-
-### REST API HTTP Headers
-
-The NAPALM credentials specified by either of the above methods can be overridden for an individual REST API call by specifying the `X-NAPALM-Username` and `X-NAPALM-Password` headers.
-
-```bash
-curl "http://localhost/api/dcim/devices/1/napalm/?method=get_environment" \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; indent=4" \
--H "X-NAPALM-Username: foo" \
--H "X-NAPALM-Password: bar"
-```
-
-## Method Support
-
-The list of supported NAPALM methods depends on the [NAPALM driver](https://napalm.readthedocs.io/en/latest/support/index.html#general-support-matrix) configured for the platform of a device. Because there is no granular mechanism in place for limiting potentially disruptive requests, Nautobot supports only read-only [get](https://napalm.readthedocs.io/en/latest/support/index.html#getters-support-matrix) methods.
-
-## Multiple Methods
-
-It is possible to request the output of multiple NAPALM methods in a single API request by passing multiple `method` parameters. For example:
-
-```no-highlight
-GET /api/dcim/devices/1/napalm/?method=get_ntp_servers&method=get_ntp_peers
-
-{
-    "get_ntp_servers": {
-        ...
-    },
-    "get_ntp_peers": {
-        ...
-    }
-}
-```
-
-## Optional Arguments
-
-The behavior of NAPALM drivers can be adjusted according to the [optional arguments](https://napalm.readthedocs.io/en/latest/support/index.html#optional-arguments). Nautobot exposes those arguments using headers prefixed with `X-NAPALM-`. For example, the SSH port is changed to 2222 in this API call:
-
-```bash
-curl "http://localhost/api/dcim/devices/1/napalm/?method=get_environment" \
--H "Authorization: Token $TOKEN" \
--H "Content-Type: application/json" \
--H "Accept: application/json; indent=4" \
--H "X-NAPALM-port: 2222"
-```

nautobot/docs/user-guide/platform-functionality/note.md

@@ -1,7 +0,0 @@
-# Note
-
-+++ 1.4.0
-
-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 `Retired`.
-
-The note field supports [Markdown Basic Syntax](https://www.markdownguide.org/cheat-sheet/#basic-syntax).