Closes #19589: Background job for bulk operations

[jeremystretch]

Closes: #19589

• Introduce AsyncViewJob to handle the background execution of arbitrary views
• Introduce the apply_request_processors() utility context manager for applying request processors
• Extend BulkImportView to support execution via a background job
• Add the background_job checkbox to BulkImportForm
• The string representation of a job now shows its name (rather than its task ID)

[jnovinger]

@jeremystretch , quick question, should a background import via pasted CSV (or via DataSource) also return a URL that points to the items modified by the request, e.g. http://127.0.0.1:8000/ipam/services/?modified_by_request=<request_id>? Or should that only be happening on the non-background job imports?

Apologies if I missed you describing that behavior before.

[jeremystretch]

I'm not sure it makes sense for background jobs to redirect to the filtered view because it's typically going to show no results (because the job hasn't completed yet). On the other hand, it allows the user to easily refresh the page to check for results without having to click through the notification.

[jnovinger]

I'm not sure it makes sense for background jobs to redirect to the filtered view because it's typically going to show no results (because the job hasn't completed yet). On the other hand, it allows the user to easily refresh the page to check for results without having to click through the notification.

That works for me, I just wanted to make sure I had the right expectation.