Ability to attach a document by adding a link

[carolromero]

Is your feature request related to a problem? Please describe.
As an administrator, I often need to attach documents in the admin panel. Currently, the process is limited to direct uploads, and there is a need for having as well the option to provide a link to its location.

Describe the solution you'd like
I want the ability to attach documents in the admin panel by either uploading the file directly or providing a link to its location.

Does this issue could impact on users private data?
No, this issue does not involve private user data.

Acceptance Criteria:

• Given I'm an admin uploading a document,
  when I access the upload interface,
  then I should have the option to either upload the file directly or provide a link to its location.
• Given the link option is chosen for document upload,
  when I'm in the upload interface,
  then there should be a specific field to input the document's external link.
• Given an external link is provided for a document,
  when the link is submitted,
  then the system should validate it and support common document link formats.
• Given the document upload process is underway,
  when I interact with the user interface,
  then it should clearly display both direct upload and link input options.

[furilo]

@decidim/product some doubts:

A. so the idea is that if I provide a link to a doc, the system downloads the document as if the user had uploaded it, it is stored the same as if the doc has been manually uploaded, and the rest of behavior is the same (same fields, same required fields, validations...)?

If my assumptions are correct, I guess we have two options of where to include the UI for the "doc upload type"

1. In the "Add file" UI
   

2. In the Add file modal
   

In both cases I guess we should show two tabs: [ Upload via attachment ] [ Upload via link ]

I guess my preference is for # 2, if not we'd have to build two different modals that are mostly the same. If you agree, I'll design option # 2.

cc @ferblape @entantoencuanto @Crashillo @mllocs @aramollis

[aramollis]

+1 for the 2nd option (is more UX friendly option and easy to integrate if we would to extend in other contexts like proposal attachments, etc)

[furilo]

Another question is how we want the system to behave for an attachment via link when user goes to edit it: just show the file, or show the link? If we want to show the link, I guess we'd have to extend the model to store the URL etc which is more complex/more code to maintain, and I don't see much benefit for it.

[NilHomedes]

Hi @furilo!
The use case here is: An admin wants to create an attachment that is a link to GDocs, HackMD, or any kind of external service. So, the system doesn't need to download it, just create the attachment as a link. The file type shown in the frontend should be "link" then.

Important! This only affects attachments created by the admins. We don't want this option enabled for attachments created by participants (i.e. in proposals).

Regarding the Design:
We should go for option 2, and as you said, create two tabs: [ Upload via local file ] [ Upload via link ]

Another question is how we want the system to behave for an attachment via link when user goes to edit it: just show the file, or show the link? If we want to show the link, I guess we'd have to extend the model to store the URL etc which is more complex/more code to maintain, and I don't see much benefit for it.

We should show the link and allow the admin to edit it. I'm not understanding why this should be more complex in terms of code to mantain. This attachment should be just a link.

[furilo]

Mmm... it seems I got confused. So actually we are not downloading any file, just linking to it, right? If this is the case, what does "validate it and support common document link formats" exactly mean? Are you thinking on existing validations?

If you are linking to an actual file (a .pdf, .xls, etc) you could perform these validations - for some of them (ie. file dimensions) I don't know if they can be done remotely without downloading the file, which would introduce complexity.

But if you are linking to a GDoc/HackMD/etc - what would we be validating?

Do you expect to perform different validations depending on the link type (file, service...)?

[NilHomedes]

@furilo We only need to validate the URL format is correct, so if someone introduce an invalid URL it shouldn't be possible to continue.
Ignore the last part of the sentence where we say that "support common document link formats" I will remove it from the AC.

[furilo]

This could be the UI https://www.figma.com/proto/nnrzYuWsEretZRuQZPWTR9/Decidim-PX---BETA-Final-Version?node-id=20717-131311&viewport=-36565%2C-13564%2C1&t=4BrBYSwyp556ADqY-0&scaling=min-zoom&starting-point-node-id=6546%3A240324&show-proto-sidebar=1

Just to confirm, do we want localized versions for the URL? I guess not. I've included in the example, but if we confirm we won't be having localized versions, I'll remove it.

[NilHomedes]

Thanks @furilo
Looks good to me the UI you are proposing.

Just to confirm, do we want localized versions for the URL?

No we don't need it. The tittle and description of an attachment will be defined in the attachement form.

Regarding the guidelines, I would go for:

• Only correct URL formats are accepted.
• Please note that the links must be public so that all participants can access them.

PD: Please remember to tag me/us whenever you need feedback from product. Doing that, I receive a notification and I can be more quick to answer.

[furilo]

@mllocs the tabs are the same you can find in a meeting page ie. https://decidim-lot2.populate.tools/processes/polls-in-meetings/f/3/meetings/3 - ask @Crashillo if you need help

PD: Please remember to tag me/us whenever you need feedback from product. Doing that, I receive a notification and I can be more quick to answer.

@NilHomedes ok! I thought once you had been mentioned you received notifications for each reply.