Upon successful completion of the autoremediation process, the accessible version of the pdf should be saved to the submission.
The Workflow repository will need a webhook endpoint that the PDF API calls when it is done processing. It will call it with the job params event_type, and job: [:uuid, :status, :output_url, :processing_error_message (if failed]
The endpoint logic should handle the creation of a RemediatedFinalSubmission file.
First proposal: Final Submission File could have a has_one relationship with a similar model, Remediated_Final_Submission_File. When a remediated copy is created, it could belong to the original Final Submission File. This would give an easy check on if we need to do the remediation process again: if the length of a FSF's remediated_final_submission_files field is more than zero, the process is unnecessary.
After saving the Remediated Final Submission File to the db, we should do a Solr reindex so the changes show up in ETDA Workflow.
Upon successful completion of the autoremediation process, the accessible version of the pdf should be saved to the submission.
The Workflow repository will need a webhook endpoint that the PDF API calls when it is done processing. It will call it with the job params event_type, and job: [:uuid, :status, :output_url, :processing_error_message (if failed]
The endpoint logic should handle the creation of a RemediatedFinalSubmission file.
First proposal: Final Submission File could have a has_one relationship with a similar model, Remediated_Final_Submission_File. When a remediated copy is created, it could belong to the original Final Submission File. This would give an easy check on if we need to do the remediation process again: if the length of a FSF's remediated_final_submission_files field is more than zero, the process is unnecessary.
After saving the Remediated Final Submission File to the db, we should do a Solr reindex so the changes show up in ETDA Workflow.