HFI Calculator: Convert fuel type cells to a select field / dropdown

[tessmgood]

As a Z/RWCO I want to be able to change the representative fuel type for a weather station So That I can consider all relevant fuel types throughout the fire season for a given weather station

Additional Context

• RISK everyone should see the same prep level... what happens when a ZWCO changes a fuel, while an RWCO also has the tool open?
  • for feedback once dropdown is introduced? different FCs have slightly different workflows on prep day.
  • Ops CoP should input

Acceptance Criteria

• Refactor: station selection
• Remove fuel type info from fire centre response - should only need fuel type id.
• get_fire_centre_stations being called multiple times
• Refactor: split build and calculation functions in hfi_calc.py
• *_t with *_time_of_ignition ?
• remove broad exception
• Given I am using the HFI Calculator, When I am viewing the weekly table / Prep Period, Then all FBP Fuel Type cells are select fields, with a dropdown of all fuel types
• Given I am using the HFI Calculator, When I am viewing a single day, Then all FBP Fuel Type cells are select fields, with a dropdown of all fuel types
• Given I am using the HFI Calculator, When I change a fuel type for a weather station, Then that change is reflected across all days and views (daily/weekly) for that prep period - I can only change it in the prep period view, not daily views
• Given I change a fuel type for a weather station, that change persists for the user that made the change within browser sessions, pending HFI Calc: All users see same information vs. local changes  #1634 decision
• Given I change a fuel type for a weather station, that change and all resulting calculations are captured in the copy-to-clipboard PDF generation workflow
• Given I change a fuel type for a weather station, a shimmer effect indicates a row is recalculating (per Fire Behaviour Calculator) - the planning area row (note: mean fire intensity and prep level may recalculate)
• The fuel type always defaults to the representative fuel type

Definition of Done

• Ready to Demo in Sprint Review
• Does what I have made have appropriate test coverage?
• Documentation and/or scientific documentation exists and can be found
• Peer Reviewed by 2 people on the team
• Manual testing of all PRs in Dev and Prod
• Merged

[conbrad]

Permission for this as well?

[Sybrand]

@conbrad re. permissions - are you seeing fine grained permissions? Right now I'm seeing "view" and "edit" roles. I'd assume anyone with an idir can view - so maybe that's not even a hard permission, but edit is then required to see it on the front end, and to post/put to the back-end.

[conbrad]

@Sybrand yeah I think all we're concerned about are those 2 permissions at the moment, which makes things easier to get started.

[conbrad]

• Given I change a fuel type for a weather station, that change persists for the user that made the change within browser sessions, pending HFI Calc: All users see same information vs. local changes  #1634 decision

We should have requests persisted to database by the time we tackle this ticket, I think this AC can be updated to be persisted across all users instead of per user browser session.

[conbrad]

A lot of this work has been made more manageable with the current work we're doing migrating the logic from frontend to backend. It may be a good opportunity to refactor the request/response models for HFI in this ticket to be more explicit, since this is post MVP and we'll have the clearest picture of field structure when tackling this ticket.

Thoughts, @Sybrand ?

[andrea-williams]

re: RISK in Additional Context. I'm thinking we'll need to implement a lockfile mechanism for writing changes to the DB so that we don't encounter race conditions when 2 people try to save changes simultaneously. Not sure how to handle situation where the page is stale for a viewer because someone else has recently submitted changes...
Or maybe I'm over-complicating this.

[Sybrand]

@andrea-williams re. overwriting. It's more complicated than that (meaning - let's leave it for now) ; You'd need to push changes to all other open browsers to avoid overwrites. So we'd need a push mechanism - something we haven't thought about at all.