As an External Operator, I want to be able to upload attachments to my application, so that I can submit all relevant documentation as part of my application

[LindsayMacfarlane]

Description:

Ability for proponents to upload and submit application-related documentation. The applications require a fixed set of specific documents to be uploaded, and will be presented with one upload field per document. For this iteration, the attachments page will remain the same for both EP and IA projects, and will need one "field" for Appendix A and one for Appendix B. The upload component has already been built for CCBC and can be borrowed from them.

Wireframe: https://www.figma.com/file/84BpebYIR1iYetxJThLsW6/CIF---External-User-Portal?node-id=141-1588&t=grieAJ8m5Qvvtl3C-4

Acceptance Criteria:

Given I am a Proponent When I am on the attachments page for an application Then I see a list of documents I need to upload and a changes saved indicator and a return to dashboard link

Given I am a Proponent When I click the Upload document button for a specific required document Then I am presented with a file selection window, and can select a file to upload

Given I am a Proponent When I uploaded a file and the field expects only one attachment Then the 'Upload' button changes to 'Remove'

Given I am a Proponent When I uploaded a file and the field expects more than one attachment Then the 'Upload' button allows uploading more than one file

Given I am a Proponent When I have submitted my attachments Then I can click on the uploaded file and see the file in another tab / download those attachments to confirm they are the correct ones

Development Checklist:

• [ ] Create the attachments page and wire it up to the stepper (EI version of the tasklist)
• [ ] Every time a user uploads an attachment, create a form change (an entry to the attachments table should be created automatically)
• [ ] Appendix A and B fields using the CCBC component for attachments (a file widget example)
• [ ] Remove functionality is NOT to be implemented in this card, but in #1519
• [ ] Meets the DOD

Notes:

• Commiting the form changes will happen when the user submits the whole project, same as on the internal side

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

• [x] User story is included
• [x] User role and type are identified
• [x] Acceptance criteria are included
• [x] Wireframes are included (if required)
• [x] Design / Solution is accepted by Product Owner
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

• [ ] Acceptance criteria are tested by the CI pipeline
• [ ] UI meets accessibility requirements
• [ ] Configuration changes are documented, documentation and designs are updated
• [ ] Passes code peer-review
• [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
• [ ] Ticket is ready to be merged to main branch
• [ ] Can be demoed in Sprint Review
• [ ] Bugs or future work cards are identified and created
• [ ] Reviewed and approved by Product Owner

[BCerki]

@pbastia, will we still want a separate application attachment table, or can attachments go into the regular attachments table?

[pbastia]

@BCerki The attachment table right now just matches files between a project and the google cloud file UUID (and a project status that looks irrelevant now). We don't have a mechanic to assign attachment types yet - either a reporting requirement id, or an enum on the schedules. In this case we can probably have an additional application_attachment that joins an attachment record and a schedule / attachment type for the initial submission - and reuse that pattern for the reporting requirements attachments

[Dianadec]

Hey team! Please add your planning poker estimate with Zenhub @BCerki @dleard @pbastia @sam-warren @Sepehr-Sobhani @tmastrom @gurjmatharu

[pbastia]

@dleard @sam-warren @tmastrom do you mind adding your estimate?