Permit Generation: Permittee Data autopopulated

bboddiger commented 4 years ago

Background As a permittee, I need the relevant information I entered into the permit order form to be automatically populated on my permit, so that I can legally get wood.

This story covers the generation of the pdf permit.

Acceptance criteria

[x] Permit is auto populated with permittee name, permit number, dates purchased/valid
[ ] Permit is auto populated with permittee address
[x] Permit is auto populated quantity
[ ] Permit is auto populated with where the permit allows me to cut
[ ] Permit is auto populated with transaction type (?) Any other data that needs to be included?

Tasks

[x] Determine the MVP for the initial permit. i.e. Does the existing permit design be reused
[x] Design and Dev tasks TBD
[ ] Validation of acceptance criteria completed
[ ] Manual accessibility testing complete
[ ] Code review
[ ] PO Approved

Definition of done

[ ]  e2e tests are updated for application routing changes.
[ ] e2e tests are functioning.
[ ] Child routes for existing pages are working.
[ ] Pull requests meet technical definition of done.

carlsonem commented 4 years ago

FS2400-1 is the existing permit

carlsonem commented 3 years ago

https://www.fs.fed.us/servicefirst/docs/tb-admin-permits-multi-agency-special-forest-prod-permit-form-fs-2400-1-blm-5450-24.pdf

*Everything is required but vehicle information

carlsonem commented 3 years ago

Make sure we have the latest form that is located on Pinyon

aQuib commented 3 years ago

This wouldn't require design tasks per #157.

carlsonem commented 3 years ago

@briandavidson I think this is the main task you are currently working on. If so, please move it to in progress. As Mike and I discussed, this is very similar to what was done with Huckleberry permitting, please coordinate with Ishan so understand that proven approach that we can hopefully adopt for this application. This is the main development task this sprint, so want to get it moving so we get this issue complete by next Friday. Thanks!

bboddiger commented 3 years ago

@carlsonem @briandavidson @mtlaney Closed #159 but added a couple extra criteria from 159 to #158.

briandavidson commented 3 years ago

@carlsonem @mtlaney @aQuib -- not sure who to direct this question towards, so any clarity on this would be appreciated:

I'm making good progress on the PDF functionality, but I'm unclear where exactly this is supposed to be in the application. I'm guessing on the Order Confirmation page? Do we want a button or something that allows the user to save the PDF?

carlsonem commented 3 years ago

@carlsonem @mtlaney @aQuib -- not sure who to direct this question towards, so any clarity on this would be appreciated:

I'm making good progress on the PDF functionality, but I'm unclear where exactly this is supposed to be in the application. I'm guessing on the Order Confirmation page? Do we want a button or something that allows the user to save the PDF?

My understanding is that this would generate a PDF file that a user can print. The PDF will need to be included in the email that gets sent to the user, I'm unaware if there is also a way for printing it directly from the confirmation page.

aQuib commented 3 years ago

@briandavidson - The PDF will need to be available for print at the confirmation page via a 'print now' button (which relates to #140) and it will need to be attached to the confirmation email (which relates to #143). The data flow diagram shows when the permit PDF should be available in the workflow as well.

briandavidson commented 3 years ago

@briandavidson - The PDF will need to be available for print at the confirmation page via a 'print now' button (which relates to #140) and it will need to be attached to the confirmation email (which relates to #143). The data flow diagram shows when the permit PDF should be available in the workflow as well.

Perfect, thanks @aQuib and thanks @carlsonem for the quick responses, appreciate it!

Also @carlsonem, I don't think it'll be too much trouble but just a heads up that it might take a little longer than I initially expected to complete the issue but I'm still shooting for Friday - I didn't realize this would cover the email functionality as well.

briandavidson commented 3 years ago

@carlsonem @aQuib @MelissaBraxton (again not entirely sure who to direct this to) -- I think this issue is a good example of where we could potentially tighten up our workflow.

Basically, the point of this issue is:

email a PDF version of the filled out permit to the purchaser after they complete their purchase
add a "Print Now" button to the Order Confirmation page that prompts the user to print their permit

There is no mention in the ticket of a PDF, no mention of sending any email, and no mention of a print button. But this is the actual work that needs to get done, so it should be captured in the ticket. I've attached a screenshot that shows the current state of the ticket at the bottom of this comment for easy reference.

From my point of view, as the developer, I feel like I should just have this one ticket that captures everything I need to do to get the issue done -- It gets unnecessarily confusing when I have to reference various other issues like #140 and #143 in order to get to work on this one, #158. Earlier in the thread, there were also references to a #157 and #159 as well which adds to the cognitive overload.

In order to find the actual permit design I have to dig down through the comments to find it here. IMO this along with the data flow diagram, and any other relevant or necessary information / files for the issue, should be all be at the top of the ticket, added to the description or somewhere that makes it easy to quickly see what the task is, and where everything is located that is needed to get the job done.

This is probably better for a sprint retro as opposed to a comment here on github, but sometimes it's hard to remember these examples by the time it comes around.

cc @mtlaney & @Dmac26

carlsonem commented 3 years ago

@carlsonem @aQuib @MelissaBraxton (again not entirely sure who to direct this to) -- I think this issue is a good example of where we could potentially tighten up our workflow.

Basically, the point of this issue is:

email a PDF version of the filled out permit to the purchaser after they complete their purchase

add a "Print Now" button to the Order Confirmation page that prompts the user to print their permit

There is no mention in the ticket of a PDF, no mention of sending any email, and no mention of a print button. But this is the actual work that needs to get done, so it should be captured in the ticket. I've attached a screenshot that shows the current state of the ticket at the bottom of this comment for easy reference.

From my point of view, as the developer, I feel like I should just have this one ticket that captures everything I need to do to get the issue done -- It gets unnecessarily confusing when I have to reference various other issues like #140 and #143 in order to get to work on this one, #158. Earlier in the thread, there were also references to a #157 and #159 as well which adds to the cognitive overload.

In order to find the actual permit design I have to dig down through the comments to find it here. IMO this along with the data flow diagram, and any other relevant or necessary information / files for the issue, should be all be at the top of the ticket, added to the description or somewhere that makes it easy to quickly see what the task is, and where everything is located that is needed to get the job done.

This is probably better for a sprint retro as opposed to a comment here on github, but sometimes it's hard to remember these examples by the time it comes around.

cc @mtlaney & @Dmac26

Thanks for the feedback.

@briandavidson - The PDF will need to be available for print at the confirmation page via a 'print now' button (which relates to #140) and it will need to be attached to the confirmation email (which relates to #143). The data flow diagram shows when the permit PDF should be available in the workflow as well.

Perfect, thanks @aQuib and thanks @carlsonem for the quick responses, appreciate it!

Also @carlsonem, I don't think it'll be too much trouble but just a heads up that it might take a little longer than I initially expected to complete the issue but I'm still shooting for Friday - I didn't realize this would cover the email functionality as well.

We tried to break down the tasks into smaller chunks, so really this specific issue was focused only on generating the actual PDF file. The email part is issue #143....which is also part of this sprint, so if you can get both done by the end of this sprint, that would be great.

MelissaBraxton commented 3 years ago

This is good feedback! We should def talk about this during the retro. I think we've gotten a lot better at engaging during bi-weekly backlog grooming meetings and that folks are contributing sufficiently specifying the work so that everyone is on the same page re: what it will entail, and what is needed, but there's is clearly room for improvement!

MelissaBraxton commented 3 years ago

Clarified in the background that this issue is about generating the permit pdf.

jstrothman commented 3 years ago

@briandavidson Would you like to schedule a session to walk through manual pdf accessibility testing? I realize you're not at the point of testing yet, and I'm not sure how much background you already have in how people use pdfs with assistive technology (e.g. keyboard navigation, screen readers), or what's technically needed to auto-generate an accessible pdf. Here are some resources on creating accessible pdfs from GSA's Section508.gov.

carlsonem commented 3 years ago

@briandavidson what is the status on this issue? Thanks

briandavidson commented 3 years ago

@briandavidson Would you like to schedule a session to walk through manual pdf accessibility testing? I realize you're not at the point of testing yet, and I'm not sure how much background you already have in how people use pdfs with assistive technology (e.g. keyboard navigation, screen readers), or what's technically needed to auto-generate an accessible pdf. Here are some resources on creating accessible pdfs from GSA's Section508.gov.

It looks like most of the information you linked regards things to take into consideration when designing the PDF. I'm not actually creating any new design for the PDF, I'm just recreating this PDF version of the permit that already exists with some of the fields pre-filled. So I guess I'm not really sure what there is for me to do in regard to accessibility testing this but if we need to setup a session we can definitely do that.

briandavidson commented 3 years ago

@briandavidson what is the status on this issue? Thanks

@carlsonem I've finished recreating the PDF, just waiting on the issues with dev/staging environments to get resolved so that I can push it up and test it.

jstrothman commented 3 years ago

It looks like most of the information you linked regards things to take into consideration when designing the PDF. I'm not actually creating any new design for the PDF, I'm just recreating this PDF version of the permit that already exists with some of the fields pre-filled. So I guess I'm not really sure what there is for me to do in regard to accessibility testing this but if we need to setup a session we can definitely do that.

Hi @briandavidson ~ The PDF of the permit needs to meet Section 508 standards so that people can understand the information in the form regardless of how they access PDFs, such as with a screen reader. For example, is the information read in the correct order. The PDF needs to be accessible even if we're recreating a PDF that was not previously accessible. This is why we have manual accessibility testing on the acceptance criteria. The Section508.gov site has links on how to test and one for developers on generating accessible pdfs. Do you want to take a look at the resources and see if you'd like to talk through testing the accessibility of the pdf?

briandavidson commented 3 years ago

Hi @jstrothman - I did take a look at the resources and most of them seem to pertain to Adobe tools:

We aren't using Adobe, we're using Puppeteer. Here is a link to the Puppeteer API for generating a PDF if you'd like to see what sort of configuration options are available: https://github.com/puppeteer/puppeteer/blob/v5.2.1/docs/api.md#pagepdfoptions

I also installed the ANDI tool from those resources but it didn't seem to have any results.

Also It looks like the manual accessibility testing is actually a task and not part of the acceptance criteria, and I'm not exactly sure who's supposed to do that testing to be honest! If there's something specific from those resources that you think I need or may have missed please feel free to provide some links for them and I'll take a look. Or if you'd like to have a chat to hash things out just let me know.

jstrothman commented 3 years ago

@briandavidson You're right about the accessibility testing being a task rather than acceptance criteria--I misread. @aQuib and I also recently spoke about where/when that should happen, so we should clarify. It sounds like it may also be helpful if Section 508 compliance is mentioned as acceptance criteria in all issues where it applies (i.e. anything user-facing whether that's the public or USFS staff).

From a discussion at 18F yesterday about tools to dynamically generate pdf that can address accessibility, it looks like Puppeteer is a good option, as it looks like newer versions of Chromium (which it uses under the hood) do better with accessibility. (Hooray!) See: https://blog.chromium.org/2020/07/using-chrome-to-generate-more.html

So what's needed is to assess whether the pdf currently being generated includes sufficient & accurate tags to make the pdf accessible to someone using assistive technology. It sounds like we need some additional clarity about where in the workflow this is best addressed. I will follow up.

jstrothman commented 3 years ago

@briandavidson I sent an email with possible times for a quick chat. Ideally part of development is identifying approach to making the web content accessible and testing it as part of development, with a second pass of testing as part of overall acceptance testing.

briandavidson commented 3 years ago

Remaining development on this is blocked until the issues with puppeteer in the pipeline are resolved.

carlsonem commented 3 years ago

@briandavidson did the fix work so we can move all the various issues out of blocked?

USDAForestService / USFS-timber-permitting

Permit Generation: Permittee Data autopopulated #158