ExportJob components should adapt more to job's status

[Dtphelan1]

Examples include:

• On the user job-list, we should have the option of editing forms that have been filled out once so long as the job isn't complete
• On the user job-list, if there is more information about the completion/rejection of a job we should display it.
• On the admin page, if the job isn't in-review we shouldn't have the option to upload attachments

[vlad-ignatov]

Also, completed jobs (retrieved ) cannot support any further actions - approve, reject, manage attachments... However:

• One can still download the exported stuff
• I'll have to see if a "delete" action can be added to immediately delete completed exports

Currently, when you "Approve" a job it switches to "requested" state. Use that to fix the UI and hide/disable the approve button and the attachments DnD. Later you will have to check periodically while the job status is "requested".

[vlad-ignatov]

Some of these we need to do for the demo (hiding or disabling components depending on the job state). Other are just enhancements that we can do later.

[Dtphelan1]

Question @vlad-ignatov: I'm unclear on the precise desired behavior for ExportJobDetailView across all statuses. Some are straightforward, but others we haven't agreed in-writing on the details. Below are my planned changes for each status, and I would like your approval/feedback on these plans whenever you get the chance:

• "awaiting-input": Approve/Reject and Attachments disabled.
• "in-review": All actions enabled. Basically what the page looks like today.
• "requested": Approve/Reject and Attachments disabled.
• "retrieved": Approve/Reject and Attachments disabled. Download button available on the list view and on the detail view.
• "aborted": Approve/Reject and Attachments disabled.
• "rejected": Approve/Reject and Attachments disabled.

Pretty sure there shouldn't be surprises here, but wanted to clarify before making the changes final in the form of a PR.

[vlad-ignatov]

How about this:

State	Approve	Reject	Attachments	Notes
awaiting-input	hidden or disabled	enabled	hidden	Reject handles rare use cases where users start exports but do not finalize them (although those should also auto-expire)
in-review	enabled	enabled	enabled
requested	hidden or disabled	disabled	hidden or read-only	Reject labeled "Delete" or "Delete Now".
retrieved	hidden	enabled	hidden or read-only	Reject labeled "Delete" or "Delete Now". Download buttons available
aborted and rejected	hidden	enabled	hidden or read-only	Reject labeled "Delete" or "Delete Now". If you don't click it the job is scheduled for auto-delete, and if you do it should be deleted immediately.

[vlad-ignatov]

Correction: lets not have delete on requested because when the user clicks it the export may already be completed and that will result in immediate delete instead of abort/cancel

[Dtphelan1]

Follow-up questions:

• The RPC-style interface for updating job's via POST requests to /jobs/:id doesn't have an option for deleting jobs. In the case of aborted/rejected jobs' Delete button, I plan on making a DELETE request to the jobs/:id/status endpoint. Does that line up with your expectations?
• I don't think your concern about a reject button for requested job's won't be a problem. Since the components representation layer and onClick handler are both determined by the local-job's status, even if the job's real status changes in the time from-render-to-click, the request we make will still be for a requested job (i.e. the request will still a POST against the RPC-like interface with action 'reject'.) Considering that, would you still like the Abort/Cancel button?

[vlad-ignatov]

I plan on making a DELETE request to the jobs/:id/status

Yes, that is the plan. Calling this should delete the job immediately while calling the "reject" action will only update status to rejected and put it in the delete queue. In other words, the same button will have to have different labels and do different things depending on the state

As for the second item, on real system you might want to abort the job while exporting, but for us that happens very quickly. You can either make the DELETE call to abort and delete if running, or you can call the "reject" RPC but that should not be called unless the job is in-review or awaiting-input (I may have to add some code on the server to verify that).

So, say you have an "Abort" or "Cancel" button on requested jobs. That is the intuitive label for the button at that state but it implies that the export will stop but the user may be able to proceed or restart. We don't support that. Instead, if you make the DELETE call (which is you only option at this point), the job gets deleted and it disappears... It might work but can be confusing UX.

I have another idea for this (and I updated the table above): Do the delete button for retrieved, aborted and rejected. Then also show it on requested but keep it disabled/greyed-out. The user will accept that this is not available while running. Later, after the demo, you can do some pooling to check when the export is complete. Then this button will just enable itself after a while along with a few other UI changes.

[vlad-ignatov]

And regarding attachments, where it says hidden or read-only, what I mean is this:
Is it easy or hard to split this in file list and upload UI?

• If not easy, then just hide everything
• Otherwise render the file list only (which is the "read-only" portion of the attachments UI)

[Dtphelan1]

That's all very helpful, thank you for answering my questions. I'll move forward with the updated table above. As for the attachments, the file-input AttachmentUpload and the list of attachments are already separated, so the more UX friendly approach should be feasible. I'll let you know if I start running into issues though and have to change the plan.