Step (discuss): How do we identify files to download on the page? Current method not sufficient

[plocket]

The download step uses the given string to find an href that contains the given string in it. In the AL interviews, almost all current interviews have a table with a 'View' button, a 'Download' button, and a 'Download zip' button. Examples of hrefs:

• View: href="/uploadedfile/89149/pdf_doc_1.pdf"
• Download: href="/uploadedfiledownload/89149/pdf_doc_1.pdf"
• Download zip: href="/uploadedfile/89152/multi_bundle_1.zip"

The numbers in there are different each time you run the interview. For the current download step you'd only be able to use 'pdf_doc_1.pdf' to identify the link and both the 'View' and 'Download' buttons would look the same.

I believe the difference we see with with the download file (uploadedfiledownload) is the use of attachment=True when calling the url_for() method of a document to create those links in the buttons.

Also, when writing tests for the ALDocument classes, I ended up showing the same document on the page multiple times. Are there reasons a regular developer may do the same? A file with the same href ending on the same page? That doesn't mean the documents would be the same, just that the filenames would be the same. Would they have the same text surrounding them too?

Options I can think of in some combination:

• Require that when a button will download something, it has to use attachment=True and then search for something that contains uploadedfiledownload and the given string.
• Allow user to provide regex to identify the href contents.
• Allow the user to pick the ordinal of the link (first, second, etc.) (i.e. if four links with the same file name appear, which item should be selected)
• Not language agnostic and probably not useful - Allow the user to identify text that's in an ancestor of the link. That would work for multiple files of the same name in different AL download tables where the row contains the title of the document as long as the titles were different. I'm not really sure that would be sufficient at all considering other factors.

None of these really seem sufficient. The most flexible one is ordinals, but that's also pretty fragile and, when code did change and tests failed, it would be hard to figure out why.

• [ ] When making these choices, we also need to double check what a regular attachment page's links look like [e.g. the docassemble default display of attachments with, I think attachments:], especially when files of the same name are included in the list of attachments.

[plocket]

Another idea to add to the mix: Allow downloading multiple docs in one step - loop through the docs one by one, setting the custom timeout for each one so that, like story table rows, they each get the developer-defined amount of time to download. [We'd match however many links we could. Would that work for 'View' buttons, or would they error because nothing got downloaded? Should the download step error if nothing gets downloaded?]

[plocket]

~For documents that have the same name [(on the same page?)], maybe we could just detect that number in each of them and only download one file per each unique number. I wonder if our code is already able to download 'View' files. Would be good to test.~

[We've decided interview dev need to give files unique names. That's a good practice anyway.]