PRDT: Map admin portal/field system for backcountry

[Dianadec]

Description:

We need to determine the minimum admin functionality for a backcountry MVP. Considerations include the ability for customers to be able to cancel, public safety concerns like being able to close a park, and financial reporting for reservable inventory.

what are the things we are going to allow the public to change? Need to familiarize with admin side of things.

~Sub ticket for what roles/permissions we need in backcountry admin - similar to DUP or more complex?~

Acceptance Criteria:

Development Checklist:

• [ ] Front-end route for handling cancelling (include key to passId)
• [ ] That calls the back-end to request a DELETE that sends a cancellation email to the user's inbox
• [ ] After clicking that box, the JWT that was created in previous step can be sent to the back end
• [ ] api end point for handling the http DELETE request (passing JWT)
• [ ] back-end validate JWT and issue the delete confirming the user's identity via email (change if using OAuth SSO)
• [ ] admin endpoints bypass requirements by validating admin user oauth token (similar to DUP), individual passes can be cancelled
• [ ] park closures cascade automatic cancellation of passes /w sending emails to all users automatically.
• [ ] Dashboard in OpenSearch can be used to create a live report of reservable/reserved inventory. Export of results may be possible in OpenSearch natively.

Dependencies

• Blocked by
• Blocking

Relevant documentation as reference

Definition of Ready

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

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

Notes:

[Dianadec]

Ideas:

• share this ticket during refinement, then have team attend current admin system ("field system") demo to better understand current state pain points to help with "admin side considerations" as part of this ticket.

cc @meyerdarcie

[Dianadec]

Refinement notes:

• Also look at api endpoints and see all the possible things we can do at a park
• -- create read update delete -- in proper mature rest api
• this will avoid manual entry tickets in the future (as we are seeing with A&R)
• 'take into account the developer needs too'

[Dianadec]

@marklise @danieltruong @cameronpettit to add your brain thoughts here to help refine thx!

[cameronpettit]

I think it might be helpful to look at the list of the types of data we want to be managing, and then implement our CRUD endpoints, datatype by datatype. An easy first step here would be to look our first 3 parks:

Create: add a new park to the system. What properties define a park? Which of these properties can we pull from other sources? Which properties must be provided by the user when calling the Create endpoint?

Read: Look at one or many parks in the system. What properties of a park do we want to return? What properties must be provided by the user when looking for one or many parks?

Update: make changes to an existing park in the system. What properties is the user allowed to change? Which properties should be updated automatically? Will updating a park cause data issues downstream?

Delete: remove a park from the system. Will deleting a park cause data issues downstream?

Along with these above points, we could also consider things like adding bulk Create/Delete capabilities, and permissions for who is allowed to make these calls.

Then we would repeat the above questions for a new data type, like permits, or policies, or inventory... etc... until we have API endpoints that allow us to fully run the system via the API.

Once an endpoint is created, then we can put a nice coat of paint over it in the form of a front end/UI.