On Storage, Remote URL or Voucher file upload Webform Element

[DiegoPino]

What?

A new webform element that deals with Existing Files (e.g in S3), Remote URLs (like another Repo) and Vouchers (WIP by @pcambra). No need to have all this options at the same time, so these will be "settings" Webform builders can set.

Idea is:

• An Source selector (based on the allowed options)
• An Input field with the desired File Path, Voucher (this one with Entity Reference selection using current Logged in user as limit), URL based on Source selected/allowed
• A Destination JSON key (e.g existing "documents:") that will be used to "transplant" the new File Entity
• Validation
• Fetching capabilities
• All the other limits than a normal Upload field provides (max size, extension, mime type too etc)
• Additionally a Checksum and an algorithm (MD5, SHA256, SHA512) so we can validate that remote files or local files are the ones the user expects (can be enforced to be provided or just be optional)

Am I missing something? I see this as a "one by one" case, not multiple URLS, paths, but can also do many.

What should I look for? Am I missing some complexities? I plan on "rewriting" the normal File upload

Another option would be:
Make this one also capable of Direct Upload. That way I do not need to have a "A Destination JSON key" and this can be used as replacement for our existing upload ones...

[DiegoPino]

@alliomeria @giancarlobi @patdunlavey ideas here? I can reuse a big chunk of AMI code for the processing (means moving to a more centralized location). Any security concerns? @pcambra what would you need to make this play "voucher" ?

[alliomeria]

@DiegoPino this all sounds great!

Have a few questions/comments (apologies if any reflect misunderstanding on my part):

• For the Existing Files (e.g in S3) route, are you thinking of access restrictions of any kind? In other words, would a user need to have corresponding permission to the particular location/S3 folder/directory?
• Would a user need to specify (manually) the “Destination JSON key”?
• I second your thinking that "one by one" will be the most commonly seen (needed) case, but I can also see the usefulness of have a path/directory as well, similar to what you are thinking of for AMI (Enable ZIP source file and also full directories processing ami#11).

[DiegoPino]

@alliomeria this is good! (please never ever apologize!)

For the Existing Files (e.g in S3) route, are you thinking of access restrictions of any kind? In other words, would a user need to have corresponding permission to the particular location/S3 folder/directory?

Good question here: On one side the Voucher Project is exactly to avoid this issue and to hide storage from the end user. But I see that to complement Voucher/in the meantime we can have a safe base path setting per user. Means alund can have only access to "some base setting path in S3" + /alund folder which would mean only folders inside that or filenames would be accessible. This paths can also be by role? We should discuss this and document and find a place where this is going to be setup (probably Voucher will provide a lot of this without us doing here this exercise).

Would a user need to specify (manually) the “Destination JSON key”?

No, this would be a Webform building (at the element) Setting setup. But this is only needed if this new Webform element is a totally different to the actual Upload element and not a replacement that also allows uploads... In that case the "current key" would be the key (as we do know). So much to discuss! Because making this replacement also Means a lot of code (its already a lot)

I second your thinking that "one by one" will be the most commonly seen (needed) case, but I can also see the usefulness of have a path/directory as well, similar to what you are thinking of for AMI (esmero/ami#11).

Thanks. My only fear is that a full folder will be a bit obscure (user will not know what is inside and can lead to a HUGE ADO). That also applies to AMI (so double thinking that now). But maybe a ZIP file upload (path to a zip) can solve that too?Open to hear PROS and CONS

So much good stuff here @alliomeria, thanks so much. Please follow up with more questions, concerns and good ideas.

[DiegoPino]

Almost thinking that what people will eventually ask for (not sure I can deliver) is a File Browser, but remote.

[pcambra]

Media does have the concept of external media sources, maybe some of that could be leveraged https://www.drupal.org/docs/8/core/modules/media/creating-a-custom-mediasource-plugin-for-external-assets

…

On Wed, 24 Mar 2021 at 19:23, Diego Pino Navarro ***@***.***> wrote: Almost thinking that what people will eventually ask for (not sure I can deliver) is a File Browser, but remote. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZTUD2MTCUXSAIQATTQKLTFIU2VANCNFSM4ZV2BPUA> .