debtcollective / disputes Goto Github PK

We need to port the Credit Report Dispute tool definition to JSON Schema.

Acceptance Criteria

• Credit Report Dispute tool should work using JSON Schema

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

https://zeit.co/docs/v2/domains-and-aliases/aliasing-a-deployment

The idea is to have a production alias that is in sync with the master branch.

Acceptance Criteria

• Now is configured correctly to have disputes.debtcollective.org aliased with the master branch

We need to port the Private Student Loan Dispute tool definition to JSON Schema.

Acceptance Criteria

• Private Student Loan Dispute tool should work using JSON Schema

We need to port the Tax Offset Dispute tool definition to JSON Schema.

Acceptance Criteria

• Tax Offset Dispute tool should work using JSON Schema

https://docs.travis-ci.com/user/languages/javascript-with-nodejs/

Acceptance

• Travis CI runs on feature branches and master

We want to create a service that handles the document generation process. Currently, we have two ways of creating documents:

• pug (html)
• pdf (filling pdfs forms with data)

We want to have this same functionality but deployed separately from the Disputes application.

We came with a stack that can do the job:

• SQS
• Serverless Framework using SQS triggers
• Puppeteer for html to pdf

As part of the research, we expect to define:

• How we will integrate SQS with Serverless to generate documents.
• How we will handle errors when generating documents.
• How we will notify other applications about the status of the generated documents.
• How we will handle uploads to S3 once the documents are generated.
• How we will achieve the same functionality we have in our current documentation generation pipeline.

Implementation will be done in #36

Acceptance Criteria

• Research and write a spec to discuss the implementation strategy for this service.

We are using https://vincit.github.io/objection.js/ as our ORM, we want to create a model to store the Dispute information.

We need to define the data schema Dispute will have and standardize the way we store data across different tools.

The data from the different tools will be validated using JSON schema, so as part of the saving/updating process we need to take this into account. Also, we want to let the user save their work before submitting (functionality for a "Save Progress" button). In this case, we don't have to validate the data.

Acceptance Criteria

• Create Dispute model using Objection.js
• Dispute should validate the data when submitting a form

Once we have the research done from #16. We will need to implement this according to the spec.

Acceptance Criteria

• Document generation is implemented according to the spec.

What: Add Dispute Model data field validation against tool schema

Why: To maintain data integrity.

How:

• Using tool schema to validate the data attribute against it. Feel free to use any approach to achieve this.

What: Setup database using RDS and connect to it

Why: For our database we want to use RDS. We need to set up this database (can be done with Terraform) and pass credentials to the application, so it can connect correctly

How:

• Research how to connect to RDS from Now. If this is not possible to do securely or there are issues with using Now, deploy the application in AWS.

We need to add Attachments to a Dispute from other applications, in this case the document service. This work is related to #13.

The idea is to expose a GraphQL method that allows an Admin to add an attachment to any dispute. We will need to create a token-based authentication just for this case since normally will be using the session.

We need to integrate the Header component in this repo as an external package. No modifications can be done to the Header from this project.

Acceptance Criteria

• Header should be integrated as a npm package
• Header should work correctly.

@orlando commented on Mon May 06 2019

We want to have the same configuration for linting across all of our projects. We did this initial build in the header repository. We want to port that configuration to this repository too.

Acceptance Criteria

• Linting and git hooks should work as it works in the Header

@duranmla commented on Tue May 07 2019

This ticket may be in the wrong repo, we need this on Disputes project

What: Research SSO integration

Why: To be able to login with a debt collective account

How:

• Integrate Discourse SSO with this app. We will use the same approach as the fundraising app, getting the session from the JWT cookie provided by our discourse-debtcollective-sso plugin

The current version of the tools definition uses a custom implementation based on Checkit and other custom tools. This has multiple disadvantages like not being able to use standard tooling and having to implement any limitation the library has (at the moment we have code that extends it).

Form definitions as are currently called have everything a tool needs to have, including the text we display for the tools description and how we store the data, here's an example https://github.com/debtcollective/dispute-tools/blob/master/lib/data/form-definitions/credit-report-dispute.js.

To improve what we have and reduce the amount of code we maintain, we want to use JSON Schema to define our tools and use it as the source of truth for the tool.

As part of the research, we expect to define:

• How we will store the data in the database
• How we will handle validations
• How we will render forms and wizards from the tool definition

Acceptance Criteria

• Create a spec that includes a way for us to adopt JSON schema as our tool definition framework.

We want to manage everything related to the disputes app in one repo. We will be using Lerna to do this.

Since the flow for the CI will be different for monorepos, we need to research and change the .travis.yml to work correctly.

What: Guest should be able to create an account

Why: Visitors be able to use our application and save their data.

How:

• Redirect users to Discourse to create an account
• Implement the functionality expect by the discourse-debtcollective-sso plugin in order to create an account and be redirected back to the application

We want to have PWA features in this app, mostly:

• Be able to install the app in mobile devices
• Caching via service worker
• Support deep links
• Push notifications where available

Resources to keep in mind

• https://developers.google.com/web/tools/workbox/
• https://github.com/hanford/next-offline

Acceptance Criteria

• Research how to implement PWA features in this app.
• Implement PWA features described above. Extend with any other that is desirable and easy to implement.

What: Guest should be able to login in with a Debt Collective account

Why: Visitors be able to use their Debt Collective account and be logged in without user intervention.

How:

• Implement the functionality expect by the discourse-debtcollective-sso plugin in order to read the JWT cookie correctly.
• Read cookie exposed by discourse-debtcollective-sso plugin and set this as current user. If the user is not in the database, create it

All of our tools need to generate a set of legal documents when a User completes the Dispute process. As part of the documentation generation process, we also need to upload these documents to S3 and make them available only to users with permissions (admins and the owner of the dispute)

Acceptance Criteria

• Documents should be generated and linked to a Dispute
• Both Admins and the user that created the Dispute should be able to download documents.

We need to create an admin-only section where admins can see all disputes created by users. In this section, admins should be able to:

• View Disputes created by Users
• Search for Disputes by any value
• Modify the status of a Dispute
• Communicate with users through embedded Discourse topics
• Communicate with other admins
• View User and Dispute information
• Modify attachments
• Regenerate Dispute documents

This issue is missing design mockups

Acceptance Criteria

• Research and put together a spec on how to implement these features. Work can be split into multiple tickets if required

This project will be based on:

• Next.js
• React
• Jest with react-testing-library
• styled-components
• Apollo Client
• semantic-release

Acceptance

• disputes should include the above libraries and should be configured correctly

In some cases, we need users to provide proofs of their debt to be added to their Dispute. Dispute need to have the ability to store attachments.

We want to upload files using direct uploads to S3 to not keep our backend busy just uploading files (https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingHTTPPOST.html).

Acceptance Criteria

• User should be able to upload attachments as part of a Dispute
• Uploads should be implemented using the Direct uploads to S3 strategy

We need to have the initial mockups to start developing the application once we have the base completed. We will build the initial user flow using the Material Design UI Kit. These designs will be later revisited to have the debt collective brand and to improve the user flow.

Acceptance Criteria

• Create a set of mocks for the user flow to create a Dispute, based on the Material Design UI Kit

This project will be based on:

• Apollo Server
• Flow
• Objection.js
• PostgreSQL

Acceptance

• disputes should include the above libraries and should be configured correctly

We need to port the General Debt Dispute tool definition to JSON Schema.

Acceptance Criteria

• General Debt Dispute tool should work using JSON Schema

We want to have integration testing from day one. The first version of the tools didn't have this and it lead to deploying broken workflows.

Cypress looks like the best solution for our use case, given it is easy to use and debug.

Here's some documentation on how to integrate Cypress with Travis https://docs.cypress.io/guides/guides/continuous-integration.html

Acceptance Criteria

• Cypress should be installed and configured
• Cypress should run in CI

There are some forms in the previous application that have yes/no questions behaving in a different way. For instance, a question of:

"Would you like to authorize the Debt Collective to speak to the Department of Education and its agents about your case?"

If the user selects "NO". Then the form will say:

"Are you sure you don't want to authorize the Debt Collective to advocate directly on your behalf?"

With that in mind. Make sure to evaluate after designs if we need that feature or not.

Commons Clause License prevents others from selling our software without modifications.

Link

• Hacker News topic

Acceptance Criteria

• Use Commons Clause License along with BSD 3-Clause

https://zeit.co/examples/nodejs.

Looks like now supports deployments to AWS instead of their own cloud using the same CLI. Let's research while working on this.

Acceptance

• Deployments are done using zeit now

We need to migrate the data from the dispute-tools app to the new disputes app. We need to create a script that transforms and inserts the data in the new database.

We need to port the Wage Garnishment Dispute tool definition to JSON Schema.

Acceptance Criteria

• Wage Garnishment Dispute should work using JSON Schema

We want to start sending a monthly newsletter to our users and we want to use MailChimp for this. We need to migrate our users to this platform and create a base template to fill information.

Acceptance criteria

• Create a list per collective in MailChimp
• Create a list for DTR members in MailChimp
• Create a base template with our style guide. Use for reference our community email template.

What: Setup staging environment and integrate deployment with CI

Why: We want to have a staging environment that reflects what we will be using in production. We want to use Zeit Now but since we will have a lot of integrations with AWS (SQS, VPC and RDS to name a few) if it's too much trouble to set up using Now we will have to deploy inside AWS.

How:

• Research how to connect to AWS services using Zeit Now
• Research how to deploy Next.js apps in AWS.
• Define a way to deploy and create a staging environment that is continuously deployed from CircleCI