gurusami / iragu Goto Github PK

Each booking needs to be uniquely identified. So they need an entry in the ir_booking table.

This would be a useful metric for a business. There can be a web page that gives this information live. Or there can be automated batch jobs to get this information off line via e-mail.

When a new customer is registered, there might be a valid registration offer applicable. In that case, the cashback should make an entry in the passbook.

Not all admins are allowed to make registration offers. Only certain authorized admins should be able to make registration offers. I think each PHP script is meant to do one type of transaction (or a use case) on the database. So such authorizations could be made for PHP script. What this means is that the question would be "Can this admin/user execute this PHP script?". If yes, then the user has authorization. If not, no authorization. This is some sort of an access control list (ACL).

We can use a table like this to handle/solve this issue:

CREATE TABLE ir_acl_make_registration_offer (
nick varchar(8) primary key,
constraint foreign key(nick) references ir_people(nick));

Better to handle the situation where a single campus can have multiple badminton courts.

Come up with a database table definition to hold information about a person. This person can be a badminton player, user, club member, admin or anyone who will interact with the system.

All booking needs to be done by user themselves. So admin interface can be removed.

Customers or end users should be able to register themselves by providing some basic information. I think e-mail address and/or mobile number should be compulsory for registering.

When a customer/player registers with the system, offer an incentive (in terms of money added to their balance). This needs to be done via the ir_register_offers. Make a PHP page for the same.

Open registration doesn't seem useful for a local and small business. Better to have user registration only on invitation basis.

The campus is only used for grouping purposes. Each campus can have one or more badminton courts of different types. Bookings are to be done for courts and not campuses. The reason is that each court can be priced differently based on their type of flooring.

An admin needs the ability to book a badminton court on behalf of a player on a particular date and time for certain duration. Each booking slot is 15 minutes. So a player can book for any number of contiguous slots. Since it is a prepaid system, booking is allowed only when there is sufficient balance.

Booking a court is limited to a few days in the future. Need to think and decide if booking should be opened globally (common for all courts) or booking should be opened for particular courts. Once booking is opened, then players can do the actual booking.

Check the availability of a badminton court for booking on a particular date and time.

A user needs to be able to check out the latest entries in their passbook.

Since a prepaid system is being followed, court booking is allowed only if there is sufficient balance in the account.

This is part of the admin interface. Register a new customer and check if there are any offers for registration. There can be only one offer applied to one registration.

I think it is a good idea to have an admin interface to register new user. Suppose the iragu web-app is only used internally and not exposed to the end user, then such an interface becomes necessary.

All users can register themselves (self service). So there is no need for an admin interface to register a user. I think it can be removed. No need to duplicate the functionality.

Having separate pages for admin and user menu is not very convenient. Combine them into a single page.

Display a login form. After the user enters the details and submits the form, do the validation process. Report success or failure. In the case of failed login attempt, re-display the login form again with an error message. If the login attempt was successful, start a session and display a welcome message.

Anyone who needs to make use of the iragu application need to have the user name and password stored in this table. I think ir_login would be a suitable name for this table. The user name should be the same as the nick name stored in the ir_people table.

Integrate with Razorpay. I have found the Razorpay to be very developer friendly. Enable registered users to recharge their account using Razorpay online payment gateway.

A campus can be considered as a sports complex where one or more badminton courts are available for play. The main purpose of the campus abstraction is to provide an abstraction to store the postal address. Campus data should be suitable for provide driving directions to other people.

Each player needs to register in the application and create an account. The account will be maintained in terms of playtime - number of minutes the player has purchased. This playtime will be used for booking the courts. Yes, this is a prepaid system. With this in mind, define a database table to hold playtime balance information for each player. This table will contain one row per player.

There will be a list of recharge offers or plans available for any particular day. List them out and choose the correct value. Verify payment should be a part of this workflow. At the end of this operation, the balance needs to be incremented accordingly.

Recharging with random amount of money need not be supported. Similar to mobile prepaid recharge, only certain denominations needs to be supported. Each such recharge plan can be considered as a recharge offer. Discount may or may not be there.

Each court booking involves reduction in the balance of the prepaid account of the player/user. So this requires an entry in the passbook (a debit operation).

An admin must be able to add money to the prepaid account of the user.