boisebrigade / courtbot Goto Github PK

"Delete" does not work as expected.

Create an admin panel for configuring Courtbot.

At the minimum it should support the following:

• Setting Twilio Credentials
• Setting Rollbar Credentials
• Setting up and configuring importer
  • Field Mapping
  • Data Sources
  • Data type
  • Import timing (Distillery only)
• Setting Notification options
  • Locales
  • Notification timing (Distillery only)

All of the configuration should be behind auth protected endpoints.

In an effort to cleanup configuration, make HOST, PORT, and POOL_SIZE non-compile time needed configuration (default them to sane values per env.)

Allow the mix config in courtbot.exs to act as a single source of configuration with no dependency on any other environment variables being set for ExCourtbot to run (not including COOKIE). This will include changing init callbacks to check for config values before raising.

User inputs "Start" without ever inputting "Stop", CourtBot replies with :resubscribe ("You are not currently subscribed to any cases") even though user is currently subscribed to a case. This is working as expected, but we need to review this logic and either come up with a revised message or a second flow for this use case.

User 1 subscribed to three cases:
2018CR00001, Ada, Hearing at 4/19/19 at 1:30 PM (Subscribed 4/16 @ 2:24 PM)
2019CR00001, Boundary, Hearing at 4/19/19 at 1:30 PM (Subscribed 4/16 @ 2:24 PM)
CR141800005, Elmore, Hearing at 4/19/19 11:00 AM (Subscribed 4/16 @ 3:03 PM)

User 1 did not unsubscribe and received only one alert on 4/18 @ 12:00 PM. Reminder was for 2018CR0001. Unable to tell if this was for Ada or Boundary case.

User 2 subscribed to one case:
CV011700011, Kootenai, Hearing at 4/19/2019 at 9:00 AM (Subscribed 4/16 at 10:05 AM)

User 2 did not receive any alerts on 4/18. User message "delete" on 4/18 at 1:34pm to view current subscriptions and this case appeared in current subscriptions.

At this point we had not modified the hearing data at all, so all of these hearings should have existed. Please let me know what other information I can provide to help.

Images below are from User 2. I've also included a PDF of the data we uploaded on 4/16 at the beginning of testing.

TestIdaho01.pdf

• Alter Deployment documentation to include single 'click` deployment
• Add Contributing documentation
  • Coding Standards
    • editorconfig
    • refmt
    • mix format
• Add Project brief documentation to overview
• Add Frontend configuration details
  • Revamp existing documentation to refer to the frontend way to configure ExCourtbot
  • Provide a new set of documentation to succinctly describe a non-frontend way to configure ExCourtbot and include details for disabling frontend

When a subscriber subscribes to a case that exists in the cases table but not in the hearings table, once a hearing is scheduled the user receives :no_hearings_queue daily until the hearing occurs.

The users should receive :no_hearings_queue upon hearing scheduled then no notifications until :remind

When users have subscribed to multiple cases and two or more of those cases have a hearing on the same day, no reminder messages are received by the user on the day before the hearing.

High level, this should most be documenting how a scraper written in JavaScript or Python would interact with ExCourtbot

ExCourtbot should be deployable with the least amount of work possible. Everything that can have a sane default should and everything that doesn't require someone to figure out should be set automatically if possible.

Heroku

Should configure Postgres and schedule import and notifications. Upon clicking deploy, should only have to retrieve user credentials and follow the frontend configuration steps to get ExCourtbot working.

• Deploy to Heroku: app.json
  • https://devcenter.heroku.com/articles/app-json-schema

Docker

Given a modest docker-compose.yml such as:

version: "3.3"

volumes:
  postgres-data:
    driver: local

services:
  postgres:
    image: postgres:10
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=excourtbot
    volumes:
      - postgres-data:/var/lib/postgresql/data

  excourtbot:
    image: codeforboise/excourtbot:latest
    environment:
      - PORT=4000
      - HOST=localhost
      - DATABASE_URL=postgres://postgres:postgres@postgres:5432/excourtbot
    ports:
      - "4001:4000"
    links:
      - postgres

ExCourtbot should be able to serve the frontend where the end user should only have to retrieve user credentials and follow the frontend configuration steps to get ExCourtbot working.

Additional Considerations

• Postgres SSL should be configurable.
• HTTPS should be documented and an example provided

We attempted to import a CSV with 35 rows. Import was successful for the first 3 rows but stopped at the fourth row where CaseNumber was missing and did not import any subsequent rows. The console does not report an error, simply says that the import was "stopped". Looking at the hearing table confirms three hearings were imported. We added the missing case number back into row 4 and all 35 rows imported successfully, looking at hearing table confirms all 35 hearings were imported.

We expect that upon encountering a blank field, the broken row will be skipped and the import will continue to the subsequent rows. I believe this was working as expected previously.

Please let me know what other information you need from me.

The setup the process for configuring ExCourtbot to support county duplication is not extremely clear and additionally does not force additional configuration. Some additional high level considerations need to be evaluated and implemented.

For this particular feature to work with the rest the following requirements need to be met:

• the field :county must be mapped
• :county must be non-empty on all imported records.
  • The importer should refuse to import if it sees that there is already cases imported, the county column is empty, and the field is mapped. The rationale being that this could indicate the importers configuration has changed to add the :county mapping but the previously imported records have no default value leaving the specific case/county number duplication resolvable for those records.
  • Perhaps an interim implementation detail is warn the admin when attempting to change this in the frontend and upon change to dump all hearing and subscriber data to backup tables.
• The end user messaging must include a county prompt every time a case number is queried; regardless if there is a potential for duplication. This maybe something that is later limited to only specific case types.

As it currently stands we have the model for queuing but the TwilioController logic to insert the user and the pre-notification logic to check and dequeue logic has not been completed. Add documentation surrounding queuing.

Only support queuing to a case number if ExCourtbot is configure with case types. The rational for this requirement is simply to reduce the questioning round trips with the end user.

Only enable queuing if a queued_ttl_days is set. A infinite queued_ttl_days should not be supported.

The implementation must

General messaging flow:

• User texts service with an unknown case number (but the format matches a known case type)
• User receives response saying case number is invalid and we prompt them to see if they'd like to subscribe
• User responds yes
• Respond to user telling them they are subscribed and in queued_ttl_days the subscription will expire if we do not receive anything

Add tests to ensure the following cases:

• If a user subscribes, make sure a queue record is created
• If a user responds "UNSUBSCRIBE", make sure the queued record is removed
• If a user is subscribed and we import a hearing with that case number the user will receive a notification
  • If county duplication is enabled, we prompt the user to ask if it's the correct county
• If the queued_ttl_days elapses the queued record is removed

Add documentation surrounding gettext and how to configure ExCourtbot on both Heroku and Docker to use new translations.

The importer config should support a middleware option where a it accepts a capture Middleware.import/0.

A high level middleware should look like so:

defmodule Middleware do
  use Tesla

  plug Tesla.Middleware.BaseUrl, "https://api.excourtbot.com"
  plug Tesla.Middleware.Headers, [{"authorization", "token xyz"}]
  plug Tesla.Middleware.JSON

  def import() do
    get("/todays-data")
  end
end

Create the following Wiki articles:

• Overview
• Code Overview
• Controllers
• Models
• External Dependencies
• Twilio
• Rollbar
• Configuration
• Importer
• Locales
• SchedEx import & notify
• Misc
• Deployment
• Heroku
• Docker

Wiki can be found here.

Update README.md to be much simpler. The README.md should only include the following:

• Project Name
• Testing status/links
• Short description of project
• Short setup instructions
• Links for configuration and additional setup
• How to contribute
• License

User had conversation with CourtBot on 3/18, almost a month later tried to start a new conversation and CourtBot continued old conversation.
Example:
3/18/19: User input case number, received :county prompt, responded with county, received :subscribe prompt, did not reply.
4/16/19: User input different case number, received :yes_or_no prompt (see screenshots)

We expect that CourtBot will forget current conversation after a short period of time.

Phoenix 1.4.0 has almost released and it brings with it a few quality of life enhancements surrounding using SSL for locals.

Require SSL on dev, test, and production environments.

:county message was not delivered to my handset. Following this, I tried to restart the conversation and received :no_case as if I was responding to :county prompt.

Not sure what went wrong with the handset, but I think that's a google voice issue.

Handset Error 1.pdf
Handset Error 2.pdf

Allow for configuration of rollbar, twilio, and importer to come from the database.

For users who are already subscribed to a case, once their hearing has passed, the user should receive a notification upon the first time a new hearing is added to the hearings table.

Set up a notification re: potential abuse when a single user sends more than 500 messages in one day

All fields from CSV import as expected except Case Style, which does not appear after import.

Use jason to parse a endpoints payload. Parse the JSON using a mapping defined in the importer config. The importer config's syntax should support JSON pointer. Using this import source we should be able to import Tusla's data and should not be considered complete until a successful test with real Tusla data can be imported.

Setup Courtbot on AWS in the OpenBoise account. Use either ECS or EKS to run the codeforboise/courtbot:lastest docker image. Use the courtbot.pkg repo as an example of how to setup the docker image. Use RDS as the database and S3 for configuration. As part of this, set up ECS to redeploy once a new build is completed on Docker Hub.

See @tylersamples for Twilio credentials.

Once done we can setup the preview-courtbot.openboise.org DNS record.

For testing and for a meaningful health check it would be nice to have a debug case and hearing that could be enabled or disabled via mix config or database configuration.

This debug case could be subscribed to once and result in hearing notification everyday.

Some implementation thoughts, is this could be a simple case like %Case{case_number: "HEALTHCHECK", first_name: "HEALTH", last_name: "CHECK"} with a hearing, consisting of tomorrows date and time set to 10AM, inserted after we perform an import in ExCourtbot.import/1.

Add configuration entry subscribe_limit and upon subscribing query by the "From" phone number to check that the total does not exceed what is configured. subscribe_limit should default to 0 and by default should not limit the amount of subscriptions a single phone number can have.

Upon completion add the following to the features list under "Multiple Subscriptions"

ExCourtbot can be configured have an upper limit of subscriptions per phone number.