Changes at "Alternative ways for delivering export results"
Title
- +{"en"=>"Alternative ways for delivering export results"}
Body
-
+["
Is your feature request related to a problem? Please describe.
Currently we can export almost any record set at the Decidim administrator panel. After a while, the exported dataset is delivered to the user's email box.This can be a problem with some transactional email providers as they set the size limit for attachments to very low amounts, such as 2 MB for the whole message, including its headers, body and attachments, base64 encoded.
Describe the solution you'd like
I would like to explore alternative ways for delivering the data exports. The problem we have with them is that they can take a lot of time which is why they are processed in the background. Once the background job completes, it does not have any way to \"push\" its result back to the user other than sending it through email.I propose that we would have a temporary admin storage (or user specific) where these files could be stored at. After a specific period, the older files would be cleared off from this storage automatically, so the user could only access those files during a certain period. Also, this would require these files to be protected from unauthorized access so in other words, accessing these files should be only possible for admin users (or the specific user with the user specific direction).
The delivery notification could be still sent through email but instead of the email containing the file as an attachment, it would contain a protected link to that file (which would check that the user is signed in and has access to that file).
Describe alternatives you've considered
Using other transactional email services, but this might still be a problem with some of the larger exports.Additional context
When using cloud storage providers (Amazon S3, Google Cloud Storage, Azure Files, etc), these files should not live within the same data container / bucket as the publicly facing files, such as proposal attachments, process images, etc.These files should live in a separate private container which is only accessed by the Rails application itself. And the delivery of these files should happen through a normal controller which would first download the file from the cloud storage and then deliver it to the user.
Does this issue could impact on users private data?
No, unless the files contain some private data. But access to these files should be protected to start with.Funded by
"]
N/A
Share