As a permittee, I can print a permit and the rules from my personal or a public computer so that I can avoid visiting a Forest Service office

[MelissaBraxton]

Background This story covers how a user can print the permit and conditions from the confirmation page url.

Acceptance criteria

• [ ] User has the ability to print permit and rules from external FS computer
• [ ] Ability to print a computer days after initially purchasing a permit

Tasks

• [x] Determine if the permit needs to be printed from the email only, or from within the Open Forest platform itself
• [x] Determine how to handle help desk tickets if a user loses their email confirmation
• [x] Design review of mockups
• [ ] Develop code to be able to print permit and rules - [ ] Code the application to return to print page at a later date
• [ ] Code the application to have a retrieval page to resend a confirmation email when requested
• [ ] Code review
• [ ] Design review of UI
• [ ] PO Approved
• [ ] User test print functionality

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.

[MelissaBraxton]

Here is the mocked confirmation page from which folks may print.

[MelissaBraxton]

Added a few tasks and definition of done. @bboddiger and @csstarling - I'm not sure about the history of the second acceptance criteria we have on folks being able to return to the url to print at a later date. Possible issue with this is that we'd need to have their permit (and associated information) saved so that we/they could recall it, which may not be possible.

[MelissaBraxton]

Hey @aQuib - It seems like this may be the right issue to cover this under, but in chatting with @bboddiger we'll want to make sure that we have a process in place for tracking user requests for reprints (assoc. with task #2 up above to determine "how to handle handle help desk tickets if a user loses their email confirmation"). Given that timber // firewood is different than Christmas trees, we'll need to keep better track of these requests for the firewood pilot than we did for xmas trees.

One idea - is there a way for the help desk to be able to send a tokenized url to a permittee on request? (it would have to have an expy and not be tied to PII)

[aQuib]

Here is the proposed process for users to print a permit (and supporting documents) after initially purchasing a permit if lost and experience technical issues. This process would require users to print from their email and from the confirmation page after purchase permit and other documents.

[aQuib]

Here is the mockup of the Firewood Retrieval Page:

[carlsonem]

@jstrothman please do a design review on this issue

[jstrothman]

Design Review Notes Below are some minor requests for design adjustments:

General capitalization note: The Open Forest design system, and thus the firewood permitting, uses sentence case for page titles, form field labels, and button text (e.g. initial capitalization only).

1. Change page title to "Retrieve firewood permit" (adding the word 'firewood', changing to sentence case)
2. To increase readability by making it shorter and using active voice, please change instructions from: "Please complete the fields below with the same information you supplied when you applied for your permit. Your permit will be emailed to you." to: "Please provide the information you used when you applied for your permit. Then we will be email your permit to you."
3. Change form labels to sentence case, bold, and 17px (Open Forest and the existing permitting forms have bold labels)
4. Are we going to be asking for their driver's license or other identification? If yes, what are the options they will have? If only driver's license, then change the label to "Last four digits of driver's license" If there are other options, then change just the text in parentheses to: "(example: driver's license)" [because usability testing shows that "e.g." is unfamiliar to many people]
5. Remove the placeholder text in the input fields. Open Forest design system doesn't use placeholder text, and neither do the existing fire permitting forms.
6. Change button text to sentence case, i.e. "Email my permit"
7. Remove "Cancel" button. Where would it take you? It's sufficient that people can navigate away from the page
8. If it's true that the error status alert will display after form submission, i.e. on page reload, let's move the error status alert to the top of the page (below the header, above the page title -- unless there's a different location where alerts are already built to display)--moving this so people see it regardless of the height of their browser window.
9. In the error alert message, after, "Email the forest for assistance if needed", add a colon and link the forest's contact email addressed, e.g. "Email the forest for assistance if needed: help@forestname.gov"

[aQuib]

@jstrothman - Thanks for the recommendations. All were implemented.

[aQuib]

Here is updated mockup.

[jstrothman]

Looks great. I'm not sure whom to assign next.

[carlsonem]

@briandavidson please confirm this is a duplicate

[briandavidson]

Per the acceptance criteria:

• "User has the ability to print permit and rules from external FS computer" Just to be clear, the user will receive an email that has a PDF file attached to it which can be printed. This was taken care of in other issues.

• "Ability to print a computer days after initially purchasing a permit" I'm going to assume what was meant is the ability to print the permit, in which case this is taken care of in other issues.

Since the acceptance criteria for this as I understand them, was completed in other issues, I'm going to go ahead and close this issue as redundant/dupe.

cc @carlsonem