Support optional approval of Jobs before execution

[lampwins]

Environment

• Python version: 3.7
• Nautobot version: 1.0.0b2

Proposed Functionality

Support the ability for Jobs to require the approval of a Nautobot user before the job is executed. When such a job has been defined, user Bob will be able to provide input to the job as normal and may execute the job in Dry-run mode, but may not execute the job in non-dry-run mode. When Bob is happy with his input, he may save the job which will request approval from user Sally. Sally has permission to approve executions of this particular job, and sees a queue of executions awaiting her approval. Sally may view the input to the job and the dry-run results. Sally may also run the job in dry-run mode again to see if anything is different, given the time delay in the approval. Once happy, Sally may approve the job in which case it is finally executed in non-dry-run mode. The job execution is attributed to Bob, but Sally is marked as the approver.

Adding the ability to store the job input and recall it later is straightforward, but there are a few options for specifying the necessary approval components. There are two prevailing paradigms for identifying and granting approval permissions to jobs:

1. The possible list of approver users and/or groups is defined in the Job's Meta inner class. I.e. defined in the job code itself.
2. An approver permission is automatically created in the Nautobot core, based on the name of the job. Administrators would need to assign this permission to applicable users/groups using the existing permissions framework. In this case, the Job still needs a way to specify if approval is actually necessary. This would likely be a boolean flag on the Job's Meta inner class.

From there we need a queue list view to show all jobs awaiting approval, with the ability to remove them from the queue when needed. It also makes sense to support an API endpoint for approving a job.

Use Case

Many types of data changes in Nautobot are both sensitive and critical in nature and thus correctness of the change execution is very important. Jobs offer a great step in the direction of correctness but many users and organizations would benefit from an added layer of peer review and timing orchestration to data changes. Today this can be managed with external tooling using the many extensibility features, but a direct approval step on Job execution would provide a simple but powerful mechanism to address many of these concerns.

Database Changes

A couple of changes to the Jobs mechanics are needed, particularly the ability to save the input for a job, to be executed later.

External Dependencies

None

[jedelman8]

Really like this. Going to tentatively put in for 1.1

[jedelman8]

This didn't make 1.1.0, but is definitely in progress and will be released in 1.2.0.

[glennmatthews]

Part 1 of this functionality was implemented in #805.

[glennmatthews]

Addressed by #805, #874, #879, #908.