fac-11/the-ticket-bank

Ticket Bank: ticket donation charity platform prototype

the-ticket-bank

This is a prototype for a platform to be used for the distribution of donated event tickets via charities to those who may benefit form them most.

Tech Stack

• Express
• Handlebars
• PostgreSQL

Instructions for Running Locally

• Setup a local postgreSQL database.
• Clone the repo.
• Obtain a copy of the config.env from any of @AbdullahChaudhry, @y-zaky, @BartBucknill or @rinoma. Save the config.env in the root. Replace the database url with your own.
• Navigate to the root directory of the project in your terminal, and run npm i.
• In your terminal run npm run testbuild. This builds the database schema and inserts test data. Alternatively you can run npm run build to merely build the schema without inserting test data.
• In your terminal run npm run devStart to start the development server.
• Navigate to localhost:4000 in your browser to see the site.

Tests

• To run the tests when in the root directory of the project run npm test in your terminal.
• For manual testing you will want to set up dummy email accounts.

Features

This prototype includes three main flows/user journeys:

• A charity can apply for an account. The process includes automated verification of their email address and manual verification by the Ticket Bank organisation that the account application is legitimate.
• The Ticket Bank organisation can create new events, and a new event notification email will be sent out to all registered charities.
• A registered charity that has been approved by the Ticket Bank organisation can request event tickets, and submit details of attendees. An email notifying success/failure will be sent out upon the application and the Ticket Bank organisation receives email notification that they need to send out the tickets. Note: this flow is not complete (see below).

A rough diagram of these flows can be seen here. Note that improvements were made to this original plan, so it is not accurate in every detail, but it is a good guide.

To Do

Due to time constraints there is still some work to do on this prototype.

• Many of the open issues may actually be ready for closing but await discussion with the product owner.
• The final flow of those listed above is not complete. When a charity requests tickets various actions should occur (see linked flowchart), but currently only emails are sent.
• There are several code quality issues to resolve including: test coverage is currently low, the file structure needs refactoring, and some errors are not handled properly.

the-ticket-bank's Issues

Add favicon

Create and add favicon icon

Validate charity signup bug

Enter in an overly long phone number is not caught by the validator, but is rejected by the database.

• Validator should catch this

• .catch in newCharitySubmit.js for serving up custom errors should be placed after the validation check, otherwise it renders up error messages directly from the database. There should be another .catch to catch any other errors rendering up a generic message.

.

.

Write test for Postmark API

Write a test to check if Postmark API is sending outbound emails

Security Warning - Vulnerable dependency (hoek module)

Found in package-lock.json

Github has advised to update the module.

Styling

Currently we have some pages on master which are not fully styled.

Create Single Event Pages

These pages will be linked to from homepage event list, and will provide more complete information on a single event, as well as a link for requesting tickets.

Upload Boilerplate

Update .gitignore file

Include exceptions for ds store and env files

Name of charity and event title in applyfortickets form

User Story: As an admin can approve or reject a charity account application

Acceptance Criteria
In order to approve/reject a charity account application:

• As admin I receive an email when a charity account application occurs

• Email includes all the details from the charity application

• I can click on a link to accept or reject the application

• Acceptance or rejection is noted in the database

• The charity is notified via email of when their application is processed

Add event styling

Calendar should be next to the date inputs

User Story: As a user I can see a homepage

Acceptance criteria
The homepage includes:

• List of available tickets/events

• Link to sign in page

• Link to charity account application form

• Mobile first (should look good), functional on desktop

See mockup

Create Readme

Create code cov badge

Date in database is not rendered correctly

For example if date is 13/10/2017, in the database it will create and error.
If 03/10/2017 it will be saved in db as 2017-03-10.
Needs fix

User Story: As a user I can log out

Acceptance criteria

• Log out button
• Once logged out, divert user to the homepage

Install Tape

User Story: As a charity I can apply for an account

Acceptance criteria

Form will include:

• Enter charity number
• Charity name
• Area of work (field of support)
• Main contact name
• Contact number of main contact
• Email address of main contact
• Address of charity

Database:

• Charity data is stored in charities table in database

• Email verified is false

• Account verified is pending

Add Dependencies

Tests: Should we encrypt our config.env file?

I had some trouble getting the tests to work on travis mainly because travis was complaining that it can't find the config.env file (as we have added it to .gitignore file)

So I used travis cli to encrypt the environment variables and add them to our .travis.yml file so travis can access them when running the tests ( see: https://docs.travis-ci.com/user/environment-variables/#Encrypting-environment-variables ) however the problem with this is that tests done locally do not work (using npm run test) because it needs to read the environment variables from the config.env using env2.

I added a workaround to this by adding the following code (check email.js)

if (process.env.TRAVIS !== true) {
  require('env2')('./config.env')
}

This code checks if the current environment is not travis, and if true will load the environment variables from the config.env file.

This is a working solution, as both tests now work locally and on travis however this is going to be quite cumbersome to keep on adding this code whenever we want to load in the environment variables - for example, when working with our database.

I'm just thinking if we have multiple files which will need to access environment variables this will not be an elegant solution, as we will keep on having to paste in that code.

However, we could instead encrypt our config.env file using travis, host it on github and then add a line of code which will decrypt the file and load our environment variables when we build our project.

This way we don't need to worry which environment we are on when loading our environment variables:

See here for more info how to encrypt a file using travis cli: https://github.com/travis-ci/travis.rb#encrypt-file

User Story: As a charity I can verify my email address

Acceptance criteria

On submission of account application form:

• User sees a page directing them to check their email

• User receives an email with a link to click to verify their email

• On click of verification link, user email is marked as verified in the database

Addevent route should be restricted to admin

User story in the Readme

• Documentation of userstory in the readme
• Link to our app/webpage

User Story: As a registered charity I receive email notification of new tickets

Acceptance Criteria

• When new tickets become available.

• It includes: basic details of the newly available tickets (e.g short description, date), a link to the newly available tickets, and a link to the homepage.

User Story: As an admin I can approve/reject ticket requests

Acceptance Criteria

• When a charity applies for a ticket admin receives an email with all details from the request.

• Admin can click on a link in the email to accept the request

• If accepted, the entry in the database is updated to decrement the number of available tickets by the given amount

• Admin can alternatively click on a link to respond that the event is no longer available

User Story: As a charity I can apply for tickets

As a charity I can apply for tickets
Acceptance Criteria

• Number of Tickets
• Names of participants
• Age of participants
• Name of the Charity
• Email of the participants
• Alternative Contact Phone number or
• Contact Phone Number of Participants (optional - nice to have)
• Postcode or General Location o the participants
• Ethnicity (dropdown or field)
• Additional Information box

Salt the passoword hash

Set up email system with postmark API

Create a footer

Create a footer with contact details

• About us
• Contact
• Donate tickets

The create event form should have styling

Styling of the form to create the event on the admin side

User Story: As a user I can log in to the platform

Acceptance criteria
The form includes:

• Username field
• Password field
• Login button

Validate ticket form

The form for applying for tickets should require validation before being passed to the db query

Error handling

In multiple places (for example in verifyLogin.js) there seems to be a challenge regarding how to handle custom generated errors that we want to serve up to the client, and how to handle non-custom errors that we want to handle by serving only a generic message to the client.

Multiple .catches can cause problems as subsequent .thens get called with wrong or undefined return values (as in verifyLogin.js - bug), and later .catches may attempt to render to the client a second time, causing multiple header write errors.

In createevent.js we have addressed this problem by differentiating between custom errors and default errors based on a property present on those default errors and not on the custom errors. A more robust and readable way might be to create a custom error class, see MDN.

Top logo should send back to home

Link to Heroku

• Link in Readme

Refactoring / file structure

We have ended up with two problems:

1. In the database directory we have two ways of making queries: one uses sql files which are read and executed by a generic dbQuery.js module, and another in which individual queries are in separate .js files. We should stick to one convention as much as it makes sense to do. Possibly an index of sequel queries exported as an object from a js file would be nice?
2. Our file structure is problematic - currently the division between router, handler, model directories is not clear. In routes/ we have functionality which are arguably handlers. Perhaps we could simplify by having just having the index of handlers as the route, and then having only a handlers and a model directory, in which handlers deal with req and res, and model is is used by handlers where appropriate?

User story: As a charity I receive a confirmation of my request for tickets

As I charity I receive a confirmation that my application has been accepted or rejected.
I will receive an email with:

• Welcome message and Thank you
• Event name
• Location
• Time
• Name of people attending
• Contact(s) (for now email of the ticketbank)
• Link to Terms and Conditions (possibly)

Ask user message like:

• "Please bring your ID"

Create Database

Create

• db_build.js
• db_connection.js
• db_build.sql

Heroku

• Set up DB on heroku

Tests

• Set up database in Travis

Re-organise server side file structure

Re-organise server side file structure into src folder

Create Tests

Add postmark module to package.json

Test Coverage

Test coverage on master is low, we should aim for close to 100%.

User Story: As an admin I can create events

Acceptance Criteria

Restricted route:

• should only be accessible if logged in user has admin rights

When an admin is logged in the admin can input:

• Title
• Short description
• Venue
• Full description
• Start date/time: calendar dropdown
• End date/time: calendar dropdown
• Min age
• Number of tickets
• Ticket name
• Number of tickets
• Additional info
• Maximum allocation per charity

Database:

• All of the above should be stored in the database in the events table on submission of above form

Redirect:

• On form submission redirects to success message including link back to create event page.

User Story: I need to click an event and see an events page

The events page will have:

• A full description of the event
• An additional info section

Set up Travis

On server start should display the port server is listening on

Currently when the server starts it's not intuitive which port it's listening on