Changelog

MonteCinema v0.0.1.4.3

• Adding model tests
• Adding concepts usecase tests

  MonteCinema v0.0.1.4.1

• split main methods to sub methods
• better names for methods

  MonteCinema v0.0.1.4

• Adding faker to rspec tests
• Installing gems: bundle-audit,brakeman, simplecov
• Adding payment history model
• Adding job to delete not paid ticket from tickets, add its record to payment history.
• Adding wait to scheduled job for some minutes
• Adding mailer to job. Once job is called, mail is being sent to the user.

MonteCinema v0.0.1.3.5

• Register + Login with devise and doorkeeper
• Employee recognization => boolean type “admin” column in user model.
• Post requests to create [ cinema hall, ticketdesk, movie, genre ] if user is admin

  MonteCinema v0.0.1.3

• Clearing code
• Adding Validates_presence_of
• Deployment to Heroku
• Mailer is working
• Mail validation

  MonteCinema v0.0.1.2.6

• Default value for each repository, constructor runs without args, accordindly to module/class.

  MonteCinema v0.0.1.2.5

• Uniqness validator for ticket
• Validator for buy usecase, new private methods

  MonteCinema v0.0.1.2.3

• Adding Monteway to API
• Adding Base Class for Usecase, Repository and Representer
• Sets(usecase, repository, representer) of each models inherits from Base
• Adding usecase for returning seats that were taken and matrix representation of cinema_hall.
• Adding usecase for buying tickets
• Documentation add url

  MonteCinema v0.0.1.2.1

• Adding => password .attribute] to: ticket .model
• Re-working =>ticket controller
• Hiding few columns while rendering json
• Adding password to set_ticket_params
• Available 🎟tickets [boolean test change]

  MonteCinema v0.0.1.2

• Adding => [genre model & controller]
• Ticket buying to choosen movie [fixup!]
• Deleting => [user model & controller]

  MonteCinema v 0.0.1.7

• Adding validators
• Creating models and its controllers => movie, client, genre
• Re-working model => ticket

  MonteCinema v0.0.1.3

• Adding Gems => [Rspec, sentry]
• Controller re-working

  MonteCinema v0.0.1.1

• Fixing Availability of cinema_hall, can’t buy if there is no tickets left. fixup
• Fixing methods => [buy, booked]

MonteCinema v0.0.1

• Creating models and its controllers => ticket_desk, cinema_hall, ticket
• Creating methods to handle listing rows of data based on url params.
• Models => [ticket_desk , cinema_hall] has features such as has_and_belongs_to_many.
• Creating methods to handle booking and buy.
• Availability of cinema_hall, can’t buy if there is no tickets left.

Website Functionalities

What user can do during using the site?

Each user can
  -Log in
  -Log out
  -Create account
  -Get list of ticket desks
  -Get list of Cinema Halls.
  -Get list of movies that are playing
  -Get list of empty seats for the movie
  -Get list of tickets that is linked to their email
  -Buy a ticket
    -You get confirmation on email.
  -Make Reservation
    -Your ticket is gonna be deleted if you dont pay 30 minutes before movies start.

Know How

Wrap your mind around the API, How It all works.

The project has multiple components. Lets start the reading.

Relationship between models. Database schema.

# There is Ticket that belongs to:
  -user, based on email. User email is unique!
  -movie

Each movie is as well seance. It has its starts’ date and ends’ date. It has referece to cinema hall, where ticket gets number of total tickets for choosen movie.

How ticket recognization works?

- You can take only take ticket thats' seat is declared in empty seats list.
- Each cinema hall has its volume.
- the API creates empty seats list accordingly to volume of cinema hall, each row has max. 10 seats

How the Authentication works?

# What does happpen in controller once You create an account?

## Creation of account
-User_controller checks 
  -if your params[:email] is email,
  -if params[:password] has desired length.
-It searches if params[:client_id] is equal any of Doorkeeper::Application.uid, either 
  -It returns error message.
# Creation of Token
-It creates Doorkeeper::AccessToken using your client_id,Doorkeeper::Application.uid and reftoken
-Two the same refresh tokens cannot exist
  -it checks in database and returns the one that not exist". 
    -Each token has some expiration date.
-After creation, it renders the nessesary information for user to log in:
  -auth token type, expiration date, access_token
## Log in
-Every time we want to log in to authorized page,
-It checks if our token exists in Doorkeeeper::AccessToken and is assigned to our account.
-If we want to refresh our access_token expired.
-We log in, we use client_id, client_secret, email and password, new token is assigned.