sirseim / spfy Goto Github PK

use branch authorization

Users are assigned to a particular role as defined in the database. A particular role is given access to a particular set of pages and api calls. These need to be enforced by the validate function that hapi-auth-jwt2 uses to authorize users.

• /api/users GET
  • without query, get all users
  • with query, get users based on that
• /api/users POST
  • must contain at least a username and password
  • optionally have First & Last name, permissions role
• /api/users/{userId} GET
  • Get a specific user, based on their id
• /api/users/self GET
  • Get a specific user, based on their token
• /api/users/{userId} PUT
  • Update an existing user (excluding password), based on their id
  • Can update info and their permissions role
• /api/users/self PUT
  • Update an existing user (excluding password), based on their token
  • Can update info and their permissions role
• /api/users/{userId}/password PUT
  • Update an existing user's password, based on their id
  • Must contain current password (password), and new password (newPassword)
• /api/users/self/password PUT
  • Update an existing user's password, based on their token
  • Must contain current password (password), and new password (newPassword)
• /api/users/{userId} DELETE
  • Delete an existing user, based on their id
• /api/users/self DELETE
  • Delete an existing user, based on their token

• creating and editing statuses and their colors
• creating and editing flags that can be used for client profiles
• display-configuration options for certain flags and statuses that allow them to change how the client profiles themselves appear on tables such as checkin table or client profile table (this helps staff identify, for example, whether a youth still needs intake when she/he checks in that day) - simple highlighting or patterns on the profile row
• notifications settings
• admin user creating new users
• permissions for different users / access levels
• shower schedule and sign-up configurations (time slots, capacity, prioritizing)
• resetting passwords
• saving past colors such as spfy-blue to avoid finding manually
• Username should replace "Login" button after logging in to show which user is logged in
• setting for automatic timestamp option or not for Drop-In, Outreach enrollment?
• * saving user settings
• time limit options for auto log-off

Travis CI
Codecov

unit-testing
jslint

The ability to view past drop-in sessions: the check-in, the activities, enrollment, perhaps general summary data . . .

Yes, this can all be accomplished in data browser, but it might actually be more work for staff to have to build the queries each time just for seeing drop-in history for a single day, not to mention a range of days . . . having a page or display area where they can pull up some summary data for a specific drop-in would be useful, especially for their reports and statistics gathering . . .

For Front Desk

Clean up display for the view client for case managers.

• View Client

  • Shrink headers, use containers and spacing (rows, columns) to indicate separation instead of font size
  • Utilize Others Tab for more detailed information
  • Set flags from viewclient
  • give users ability to customize notifications when setting a flag basically creating the notification after deciding they want to set one -- option for who will receive the notification -- default will be to set the notification for the current user -- but will also have option to set for other users or everyone -- that said, perhaps there should be a panel listing the alerts that are already associated with that particular flag

• CM

• Documents

• checkboxes for forms to indicate whether they have been filled out or not and whether the doc is in their paper file (SS card, ID, etc.), then won't have to do as much HIPAA

• Others

SPY staff need the ability to add/edit/delete the input fields themselves, not just client information, so that they can change the database table columns when their intake process or their organization in general eventually changes . . .

Example:
SPY staff: "We added this new question to our pre-screen add client page that asks whether the youth are signed up for this new government program or not. So we need to have an extra checkbox there that we can check off for their profile"

Currently, we have the ability to add/edit/delete information, but we have not yet implemented how staff can expand what information can be collected.

We need to talk to Bari about how to get a custom domain for this project. We could possibly hook it up to their current DNS for safeplaceforyouth.org. I would think something like manage.safeplaceforyouth.org would work the best. Depending on their DNS provider, this should come at no additional cost.

Convert calls in /api/query.js into PostgreSQL calls.
Keep in mind it might be useful to employ queries.js

We really need to start testing to verify that these routes work the way they are supposed to.

High priority:

SPY staff need a process to create new activities entirely. (This is different from adding an activity to a drop-in.)

Use Case: An LMU student group comes in and wants to teach programming to the youth. Staff say, "Great, we'll create a new activity on the database so youth can sign up for it."
• name of activity
• location
• times it will be available (won't need to designate day because that is what staff determines when they create drop-in)
• what "program" will it belong to? (Digital Arts Lab, Employment, Medical, . . . etc.)

Whoever works on this will have to decide whether creating a new activity should be a whole new page or not or just another modal on an existing page or any other design choice . . . but it would be good to review SPY feedback to see where exactly they wanted this . . .

We currently only have a route for this issue. The interface needs to be started.

For every action that SPY staff can utilize on the app, there needs to be another action that reverses it . . .

(This does not mean that every button needs an undo button right next to it.)
It means doing things such as the following . . .

• checking clients => checking clients out
• enrolling clients => unenrolling clients
• adding activity to dropin => removing activity from dropin
• uploading documents => taking documents down
• . . .
• . . .
• . . .

We need to be able to upload and download files from the site. Details are sparse because we know so little about what it takes to do files. Post comments and/or pictures as we understand more about the process.

We really, REALLY, need to figure out what hosting we're going to use.

Hosting is essential to releasing BETA

Important things to consider:

• Ease of deployment both for development purposes and production
• SSL certificate management and deployment
• Node.js & PostgreSQL support
• Agreeable pricing

working on authorization, we need to work out an authentication method, presumably using the PostgreSQL database for storing user account information

Transition to using Docker to build and deploy.

Attached is a mock up for what the client info page could look like.
Squares with plus signs indicate a collapsible flap.
The initial structure has been started on the viewclient branch on the Clients page.

Files used for Clients page:
static/js/components/viewclient.js
static/js/components/clientinfo.js
templates/components/_viewclient.html
templates/casemanagerhomepage.html (scripts for page are at bottom of this file)

Client Info Page.docx

Each of the bars at the bottom of the client profile is expandable . . .

• tracking any and all changes to the database (which user, when, what change, . . . etc.)
• this will be especially needed in Client Profiles to track what changes the case managers make

The client profile needs a tab for a case plan . . .

There only needs to be one case plan per client, but the option for multiple notes per case plan
It will be used for setting goals and discussing ways the youth can reach them and helping CM’s track their progress

It doesn’t have to be fancy yet, just a way for them to have goals in writing and have a concrete idea for what youth want to work on

Making functions/tools (such as plugins) as well as data globally available to aid development and reduce the number of ajax calls throughout the app . . .

• profiles with basic info (non-HIPAA info) globally accessible
• statuses globally accessible
• flags globally accessible

Reports can be generated in the data browser.

Currently planned features:

• Select a date range for the generated report
• select what columns to output in the report
• Pretty Graphs
• Print/Save option

• searchable instruction manual
• how-to videos?

One idea: a dialog modal menu that follows the user to different pages as long as it is open

Case Managers also want functionality for "Making the day" but rather more like "setting up my notifications and reminders" in relation to clients . . .

Use Case:
Case managers will have set up reminders and flags in the morning for certain clients
They have a list of who they want to see that day . . .
When SPY staff build the drop-in and make a table for a specific casemanager, the app will automatically populate that case manager's table with the youth that they wanted to see that day

This is also tied to flags. For example, when a youth checks in, an alert/notification is immediately sent to the case manager

setup node.js server for basic file hosting.

• UI Improvements
• Enable search of more tables
• Fix search of dates
• More detailed search

• Automatically logout users after inactivity for a specified amount of time

Do we know the typical HIPAA auto-logout time limit?

See Settings Issue #25 for user options to designate time limit

There are two key features that SPY staff will need come June which have not been implemented yet . . .

Advanced QueryBuilding

• the ability to chain more WHERE conditions with AND's and OR's

Use Case:
Search the RESOURCE client [WHERE first_name is exactly "John" ] AND [WHERE last_name is exactly "Doe"]

Views

• the ability to save and restore the result of a past query

Use Case:
Save the above built query into a View called "John Doe's profile" that can be retrieved later with a single click

The are several other features in other parts of the app that Databrowser will have to pick up slack for. For example, the Frontdesk page needs to have displays for past DropIn Sessions and all of the enrollment and checkin data associated with each DropIn (#43). However, due to time constraints, we will have to settle for letting Databrowser handling that kind of querying since Databrowser is a "query-everything" page.

Files:
static/js/search.js
templates/search.html

It will have it's own link on the navbar.

For an initial implementation, they mainly want this page to track the case managers' follow-up appointments with the youth, and it can be as basic as possible (perhaps merely listing the youth they have appointments with and the dates and times)

• display all follow-ups across all case managers' appointments
• ability to filter follow-ups by any table field (client name, case manager, date, time, . . . etc.)
  (DataTables plugin should take care of this nicely)
• settings that are local to the follow-up table so that staff can save past filters (won't have to select which columns to display or use the search bar each time they navigate to the page)

Start looking at MySql databases. Go through the database spec document provided and create the preliminary design of the database.

• /api/users/{userId}/notifications GET
  • Get all notifications for a user, based on id
  • Only get those notifications not completed
• /api/users/self/notifications GET
  • Get all notifications for a user, based on token
  • Only get those notifications not completed
• /api/users/{userId}/notifications POST
  • Create a new notification for a user, based on id
• /api/users/self/notifications POST
  • Create a new notification for a user, based on token
• /api/users/{userId}/notifications/{noteId} PUT
  • Update an existing notification based on user's id and notification id
  • Mark it as completed, update tag, comment, link
• /api/users/self/notifications/{noteId} PUT
  • Update an existing notification based on user's token and notification id

After standardizing client profiles . . .

Basically work on the top half of the front desk page . . .

• Checkin client in the most user-friendly way possible
• Dynamically populate checkin table and link to modals/popups/other features
• Work on modals, populate with data and editable information (such as allowing flags to be set)
• Checkin table settings button on the table itself (useful for storing default configs while allowing users to change them)
• "When someone checks in, automatically set status that they are enrolled in Drop-In (the program, not just the session) permanently until manually changed . . . "
• option to remove youth from check-in if they were accidentally added
• alert pop-ups on checkin

Case managers want to be able to forward sign-up requests to front desk for youth to participate in certain activities

The staff member at the front desk (like physically at the front desk) then approves it or puts the youth on the waiting list. There should also be an urgency option as well -- “urgent” “suggested” “normal”

Why can't the case managers just navigate to the front desk page and sign them up themselves?
The staff member at the front desk has immediate contact with the youth who are waiting for activities or are in the process of signing up, while the case managers are in their offices meeting with youth . . . so the front desk has priority for basically managing the youth's schedules for the activities because there will be many situations where they have to make on-the-fly decisions for certain youth, and there might also be a lot of information and decisions that won't end up making it onto the app because things will be moving so fast

Come up with some designs if you are inspired.

Front end team, we should decide on a framework, if any.

Besides the data browser, SPY staff would like the ability to determine which columns are displayed on any given table across the app . . .

This shouldn't be too difficult, just an option to add a column and a dropdown to select the information that is available for that new column to display
(of course also having a "hide column" option)

• parametrize checkin table
• parametrize case notes table

Almost everything for editing a client profile is hard-coded for the time being, but this will be problematic with other features (#36) as we approach production.

There may be some plugins that facilitate editing an arbitrary amount of input fields of varying types.

Some considerations specified by the staff:
• Some fields can only be edited in an "editing mode" rather than an "edit-in-place" to make it more difficult to accidentally edit that information.
• Other fields, such as the information in the collapsable tabs (#62), can remain edit-in-place.

(If we are crunched for time, using an edit-in-place plugin for all fields would be fine.)

Implementation for this feature is in
static/js/components/viewclient.js

Scheduling system for showers with pre-defined time slots

There should be different levels of priority for youth (this will be a flag #25) based on how many times they have showered that week . . .

Use Case:
When staff try to sign up a youth for showers and their priority is low, an alert will pop up saying for example "has already taken 2 showers this week" and will give the staff the option to override the alert and sign them up anyway or to cancel the sign up.

Overview:
• will be its own activity table alongside other activities on the bottom of the Frontdesk page; still needs to be "added" to the DropIn manually (because there is the possibility that showers aren't available for a DropIn session)
• ability designate the size of the time slots (given the size of one time slot, system will then automatically divide the DropIn Session into available time slots)

• 3 Tiered system for sign-ups
  • Tier 1: client has not showered at SPY that week
  • Tier 2: client has not showered at SPY that week, but showers are full. Client gets priority on next available time slot
  • Tier 3: client showered at SPY that week at least once, only gets a time slot if there are no Tier 1 or Tier 2 clients

• Case notes still need a way to preview a case note below the case notes table
• Fancy text editing capabilities for writing the notes
• modal for editing case notes

Designing a loading icon to use across the entire app . . .

Some ideas:
• SPY staff said they liked their SPY hearts found on their website and documents, maybe doing a little animation with that

We are not sure how to implement this yet, but off the top of our head this might get slightly complicated in the SQL code since it involves determining which fields that correspond to the intake process are still NULL . . .

Still trying to decide whether intake needed should be another activity table or its own separate table (but smaller than checkin table) . . .

• for the rows on this table just need to display (name, date_of_first_visit)

"Intake Needed" can also be set as a flag that can configure how it displays/is highlighted on other tables such as checkin or client profiles . . .

Needs to display which fields exactly still need to be completed
Example: "[checkbox] - has not completed legal form"

For Beta testing, SPY will be using exclusively fake data. (Whether that data is provided by us or by them is yet to be determined.) Nevertheless, they still need to be able to test import functionality as soon as possible.

We have a little bit of .jpg importing already, and we have a parser for importing pre-defined excel spreadsheets. But we do not have any implementation or an interface for importing any data formats such as .csv and .xlsx files . . .

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 :)