New Drop-in

[cf7]

The ability to create a new Drop-In Session still needs to be implemented . . .

Here is one of the ideas that have been circulating: • The front desk's default interface isn't actually what we currently have right now (the check-in table, activity tables) . . . the default might actually be the "Create Drop-In" interface where SPY staff choose which activities to include, which case managers are available that day for appointments, the shower schedule . . . • When they click "create drop-in session" to confirm, that "Create Drop-In" interface becomes the front desk page for that session

Status: there is currently no interface design or functionality to support this, so we will be starting this from scratch . . . (or maybe there is functionality that can be creatively refactored :)

[mreid10]

• Activities @mreid10
• CMs Available @lkonchan

[SirSeim]

New branch for this issue: newdropin

[SirSeim]

From 7413ed3:

GET /api/dropins?latest=1 gets the latest dropin, returning id and date with ?latest=3 it will return the last 3, ordered from newest date to oldest date

• latest must be a number, anything else will be rejected as a bad request

[SirSeim]

An idea for what I think should be on the Front Desk. Between the navbar and the client profiles goes what current dropin is being viewed. Right next to it is where you can get to work on a new dropin along with looking at past dropins. When looking at these dropins, the date shows correctly. Clicking on Front Desk in the navbar always takes you to the latest dropin date.

I believe when you want to create a new dropin, there should be brought up a modal for setting its date and adding activities, returning to the full view with the new date shown at the top and all the activities listed correctly.

History should probably be a dropdown for picking from like the last 20 dropins, listing their dates. Selecting one of the dates should update the interface with the new date at the top, along with updating who was checked in and the activities of that dropin.

[SirSeim]

GET /api/dropins/{dropinID}/checkin Returns:

{
  "statusCode": 200,
  "message": "Success getting checkin!",
  "result": {
    "dropin": 1,
    "clients": [
      2,
      3,
      4
    ]
  }
}

POST /api/dropins/{dropinID}/checkin with payload:

{
  "clients": [
    2,
    3
  ]
}

Returns:

{
  "statusCode": 200,
  "message": "Success checking in!",
  "result": {
    "dropin": 1,
    "clients": [
      8,
      9
    ]
  }
}

[SirSeim]

Forgot to mention that when POST /api/dropins/{dropinID}/checkin returns, the client ids returned are the ones that were successfully added. The most likely reason for asking to check someone in and that id not coming back is because that client id is already associated with that dropin checkin. Win for no data duplication