Add the ability to create a ZIP file based on document IDs

[reganwolfrom]

For now, this request would take a list of document IDs and start an asynchronous process to retrieve these documents and compress into a ZIP file. There would be no functionality at this time to include child documents automatically; if a document has child documents, they would need to be specifically requested using their document IDs.

Request Endpoint:
POST /compress
{
documentIds:['aaa-aaa-aaa-aaa', 'aaa-bbb-bbb-bbb']
}

This would trigger the process to create a ZIP. This could be a Lambda, or an AWS Fargate task, depending on what makes more sense. We may need to use SQS for this processing, and may even need a compression task id and even a status endpoint to determine status. Or it's possible that we could return an S3 object URL, and then compression could update the object from empty to finished ZIP file, but it's possible object could return while compression is ongoing, returning only some of the document selected to include.

Once the compression has completed (and the requestor can determine that completed status), we may want to have them access the signed URL, but alternatively, we may need better management on how many times the file can be accessed. It's possible to add an expiration time, or we could add a delete endpoint if we have an ID outside of the URL.

So if we need a "download id" for each compression event, we could use POST /downloads/compress and GET /downloads/{downloadId} to get status and/or create and retrieve an S3 signed URL, and DELETE /downloads/{downloadId} that could delete the ZIP file.

First step will be to determine if it's even possible to do without a "download id"; however, it may make more sense to just use a "download id" with the GET and DELETE endpoints, to enable more control by an application with this process.

[reganwolfrom]

@formkiqMike, can you take a look at this description and see if any info should be changed? Thanks!

[mfriesen]

I think it should work like Google Drive where you select a list of document and then those document are zipped up into a temporary file and downloaded.

This probably could be piggy backed on the DocumentActionsProcessor and the DocumentActionsQueue.

The response would return a presigned url to a file in the Documents Bucket tempdata folder then a LifeCycle rule would need to be added to the Documents Bucket like the OCR bucket already has.

  LifecycleConfiguration:
    Rules:
      - Id: ExpiryRule
        Prefix: tempfiles/
        Status: Enabled
        ExpirationInDays: 1

[RyanBuhrWA]

FWIW, seconded! This would be a super handy feature for us.

[ytsipun]

#160

[ytsipun]

Intoduced in v1.12.0.