As a user I need to know that a season's dates for a particular forest has not been configured yet so that I can check back later

[sadlerw]

Acceptance Criteria

• [x] a user can tell that the current season is now over, i.e., after the season end date site clearly shows that permits can no longer be purchased until the next season begins (maybe use language like "check back in Fall 2018" instead of a particular date until the new season date is in the system.
• [x] user cannot buy a permit or access any portions of the site for buying a permit (backend, frontend urls all secured and redirected - check redirect url back from pay.gov too)
• [x] developers can easily flag whether season date is open or closed for testing etc. documented in readme

Tasks

• [x] update user flow
• [x] design what user sees when they click "buy" and the season is not yet open (text and view) (Jane/Bryan)
• [x] modify the forest page with new alert (will)
• [x] figure out how to run specs for season date started and season date not started (similar to authenticated on circle maybe) (will)
• [x] determine if the landing page should indicate season is not yet open (Jane/Bryan)
• [x] ensure that the existing links and buttons work when season is open (will)
• [x] backend return 404 on all permit purchase endpoints if season not started (toggle as above) (will)
• [x] same with /applications and all application routes on frontend (note that end date changes per forest) (will)
• [x] change undoAllSeed to undo both intake and christmas tree seed files (shekar)
• [x] remove console log from frontend code (error-message.component.ts)
• [x] add info alert to frontend to indicate forest data is manipulated (will)
• [x] fix special use sidebars (will)
• [x] tts approval
• [x] PO approval

Definition of Done

• [x] Code unit / e2e tested and comply with QWASP
• [x] No new security vulnerabilities
• [x] Internal team code review
• [x] Documentation / readme.md / CircleCI updated
• [x] Docker updated
• [x] Compare finished design with mockup
• [ ] Usability tested

[ASprinkle]

This story should be tied to #14 Epic - and I don't know how to do that :)

[sadlerw]

hit the gear next to epics to the right, then select it from the list

[JaneZC]

@ASprinkle @bryanmcfadden @sadlerw Do we know what the 'open' date for the online permitting process will be? Presumably, you would be able to buy a permit before the season actually starts, correct?

I'm asking the wording would need to reflect the difference between the date you can buy the permit v. the date you can start cutting down trees.

For example, should we assume that as of Sept. 1 anyone can buy a permit online? (Or some other date?)

[ASprinkle]

We do not know when the pilot for online Christmas tree permits will be open. A user should not be able to purchase a Christmas tree permit online outside of the season dates for the respective forest.
The season start date for a forest should be the same as the start date for when someone can purchase and print their Christmas tree permit. We should not assume that as of Sept. 1 anyone can buy a Christmas tree permit online. Buying a Christmas tree permit online should only occur if the Forest has opened their season for Christmas tree permits.

[JaneZC]

For the individual forests, I would recommend two messages - one that works for when the season closes and throughout most of the year ... and then one that displays once the FS administers updates content (meaning the season start date) for a new season.

This would be for when the season closes and most of the year.

The below would be for when the FS folks update the season dates. My thinking behind this is that people will update content before the permits become available for sale; so it may look awkward to have season dates on the page that do not match the content in the information box.

[JaneZC]

For the landing page task, I do think we should add some sort of messaging on the availability to buy permits. Since we have only four forests, we could keep it simple with a layout like the below. (This is somewhat modeled after how ticketmaster approaches multiple events and differing start dates. )

The story tasks just says "determine if we should" ... so I'm not sure if that actually means we should redesign the landing page now or move to another story? But, I wanted to propose the below as an option.

[sadlerw]

I think it might be OK to hide the buy permit buttons in this case since we can't really do much if someone clicks on them other than refocus the page at the top. The permit application page will have to redirect back to the forest page too.

[JaneZC]

@sadlerw I definitely think we should hide the buy permit button (in the left-nav too) or at least grey them out. I didn't because I remembered there was some sort of 508-rule that said it wasn't allowed? But, I'm definitely on board with the idea!!

[sadlerw]

@ASprinkle if the season is closed would we prevent someone from looking at a permit they purchased online and potentially printing it again? Or would we let them look but not print? I'm not sure it matters but wanted to check. thanks, Will

[ASprinkle]

Good question. If the season is closed a person should not be able to look at or print an expired permit. If I recall correctly, I think there was a story that addressed this, and there was a page set up that said something along the lines of their permit had been expired, and that the page showed a summary of the persons purchase information (purchase date, expiration date, number of trees).

[sadlerw]

Oh sorry - I forgot we were already handling expired permits. I think we are covered.

[sadlerw]

So for testing the various date scenarios I have configured Mt Hood to be open now (starts in 2017), Shoshone to be closed now and not configured (2017-11-21 to 2017-12-24) and the other two open in the future (11/2018). The assumption here is that this data is basically the "staging" data and is not the production data. Is that OK @lauraGgit or do we need to also configure "production" data that will seed the db and use the existing seeds to seed the db only for running the test suites? Or some other solution? /cc @lpendem @sethalt @cameronwolf

[MelissaBraxton]

I think the lightest weight option is to focus the current story on clarifying the information around season dates/buying a permit where we currently have it--the forest-specific page. My preference would be to write up the need for users to know whether they can/can't buy a permit for a specific forest on the forest finder page as a separate story.

I'm curious what the underlying need is for having season dates etc. on the forest finder page. Is it so that users can decide among forests based on the season dates/permit availability? Or something else?

Or is it something like, "As a user, I need to know whether I can/can't buy a permit for a particular forest before I select a forest, so that I can know whether I can buy my permit now or I need to check back again later." What do you think, @ASprinkle? How might we prioritize this?

@JaneZC I like the look of your mockup, but I have questions. In essence, it looks like a way of displaying a table of some forest data in response to a query. I'm not quite clear on what action users would take to get to this table. Right now, users select from a dropdown of forests and then click the go to forest button, so I'm not sure at what point this table would populate. We might consider a way to indicate the forest's permit season or status in the dropdown.

If we all agree that this is a new need, then we can continue this conversation on the new story, so @JaneZC please re-post your mock there!

[sadlerw]

My feeling is that whether the season is open or not is a criteria for choosing a forest - "hmm this one is closed, I'll go to this other instead..." I don't think that's really an issue here. People are going to find the forest near them and wait for it to open, not go to another forest because the first is closed.

There is also some benefit to getting them to the guidelines page despite the season being closed I think. So I'd vote to not put this information on the forest finder page.

Thanks, Will

[JaneZC]

@sadlerw @MelissaBraxton All good points!! :) In thinking about this some more over the weekend, I was also thinking this kind of layout might work best for only four forests ... but once you get to a lot larger numbers ... it may not work so well. (ie. who would scroll a long list just to see if permits are on sale? -- kind of like what @sadlerw was saying).

I do think, though, that we would still benefit from coming up with a better design for that landing page. I may go through the usablility research again with @bryanmcfadden to come up with a user story that works based on the research. Or, is there another way to go about this?

[bryanmcfadden]

In the sprint 07 research summary, there will be some evidence supporting some of Jane's design. It seems that half of the people interviewed would like to see some kind of notice about the forest season openings/closures on the landing page (formerly find-a-forest).

[MelissaBraxton]

Thanks @bryanmcfadden! Is this something people said they'd like to see or did it come up as a stumbling block to their completing their tasks? If its only the former, then it may not be a problem, or at least I'd rate the severity of the problem pretty low.

In any case, if we do decide we need to do something about it, I'd suggest writing it up as a separate story and then tag @ASprinkle for help prioritizing.

Sounds like the need might be something along the lines of the story below, but @bryanmcfadden and @JaneZC should feel free to refine based on what you know from your research.

"As a user, I need to know whether I can/can't buy a permit for a particular forest before I select a forest, so that I can know whether I can buy my permit now or I need to check back again later."

[sadlerw]

created issue #362

[sadlerw]

I'm blocking this until we can discuss how we need to use the seeders for production. Please see the comment above. Other tasks can be worked on until then and once the open PR is approved and deployed the design portions can be reviewed on staging.

[ASprinkle]

Prioritized #362 into the product backlog

[ASprinkle]

@sadlerw what's a "seeder for production" I am not clear on why 102 is blocked. Why do we still need 102 if we have 362? and why wouldn't 362 also get blocked?

[sadlerw]

The seed is a file that is used to load data into the app before testing or production. We just need to decide if we are using it for only test data, or if we also need it for production data. 362 is just a separate story for the forest finder/home page part of this, which I think we've decided not to do here, but instead take care of in 362 in a later sprint (if at all).

[bryanmcfadden]

Updated task flow can be found here: NOTE - the selection of forest has been changed to drop-down or map selection routes which can be found below the user.

user_task_flow_102.pdf

[MelissaBraxton]

As we discussed at sprint planning yesterday, any changes to the landing page (find-a-forest) will be handled under #362.

Per changes to the forest-specific page (mocks waaay at the top of the thread): I like these!

• One suggestion for the first one - consider including the forest name in the "i" box: Something like "Christmas tree season at Mt Hood National Forest is closed..."
• I like the idea about updating the message when an admin has updated the season start date, as long as this message pull the start date in automatically and is not something the content admin has to manually change.

[sadlerw]

@MelissaBraxton @tram @lauraGgit So if I add the message to the alert that is already there...

The forest that is open will look like:

Alternative could be two info alerts. Mt Hood/open would look same as above, but a closed would look like:

I kind of like the two alerts really even though it means extra template code.

[sadlerw]

waiting for design approval then we can get this completed - it's already coded up either way

[tram]

Is it possible to say something like "Dates not yet available" instead of loading incorrect dates?

[JaneZC]

@tram I was a bit confused so wanted to double-check. Does that mean when the box of information is added to the page, the cutting date section should automatically change to the text you suggested?

[tram]

@JaneZC I think there are two separate things happening. The first is the info alert that says the season is closed and permits aren't available. LGTM! A different issue is if the dates aren't available. Was just recommending to put text where the dates would go that says the dates aren't yet available instead of displaying dates that are incorrect and dropping an info box that says they're incorrect. Just chatted w/ @sadlerw and I think we have it figured out. Let me know if I'm still using my Monday-morning-pre-coffee words and being confusing. :-)

[JaneZC]

@tram I think I got it now! :) @sadlerw Thanks. :)

[sadlerw]

[tram]

I think if we say "Dates not yet available" we don't need the second info alert.

[sadlerw]

We do, because the fact that they aren't available is still being mocked. They really are there in the database, we are just mocking that they might not be.