Expand the v3/jobs API endpoint

[TheCoffeeDude]

The V3 jobs API endpoint woefully lacks any usefulness. The current endpoint only has a get jobs/{jobid} method that is not useful because a database admin must query the database to get a list of all job IDs. To add insult to injury, this method is only limited to the user whose job is running or queued.

These are new features that I am proposing

1. GET jobs/list—This method must be callable by all users. Parameters such as none (default—full list), running, or queued will display jobs with the appropriate status. The job ID of the running or queued job and the worker it is running on must be included in the resultset.

2. GET jobs/{ownerid} — This method must be callable by all users. Like the GET jobs/list above, the resultset must include the job ID of the running or queued job and the worker it is running on.

3. DELETE jobs/{jobid} — This method must be callable by the person who scheduled the job, the owner of the workflow, or the curator. This method is the equivalent of cancelling a job on the Server Admin page - #!/admin/jobs by a curator. All three mentioned people have a vested interest in the running or queued jobs on the server and must be able to cancel those jobs.

4. POST jobs/reassign/{jobid}/{new_job_tag} — This method is restricted to the curator and applies to any job in a queued state. It allows a curator to reassign a job to another job tag or the first available worker for reasons determined by the curator.

This is an enhancement that I am proposing
1. GET jobs/{jobid} — This method must be callable by all users. This will allow any user to get the details of any running or queued job.

Logging requirements

All DELETE or POST methods must be logged and purged based on the Persistence Option > Delete queue and results after (days).

[RajeshRavikumarSbux]

Very useful information 

[Alsmith]

This is a must

[Sunit125]

Valuable information.