Skip to content
This repository has been archived by the owner on Aug 3, 2022. It is now read-only.

2.0 Work #98

Open
agentphoenix opened this issue Jun 9, 2015 · 0 comments
Open

2.0 Work #98

agentphoenix opened this issue Jun 9, 2015 · 0 comments
Milestone

Comments

@agentphoenix
Copy link
Owner

Users & Students

As it stands today, if a user is a parent and has multiple children taking lessons, the lessons either need to be combined or they have to be booked under the same name multiple times or the user needs to have a second account. Like the company can have multiple staff members, users should be able to have multiple student records.

The user record will continue to be the focal point, but every user record will be able to have student records attached to it. This will allow parents or spouses to create individual student records for each person. When booking an appointment, if the user has more than 1 student record, they'll be able to book for a specific student. Additionally, any history and such will be able to be broken down by the student and not just the user.

Student Avatars

Users should be able to add an image of themselves to the scheduler.

Needed Work

  • New students table
  • Wherever there's a user_id field, we need to add a student_id field as well
  • Development plans will need to be significantly tweaked to allow for development plans on a per-student basis instead of a per-user basis.
    • This might not actually be a huge issue since it'll be a 1-to-1 relationship of users-to-students at the initial upgrade, so it might just be a matter of changing development plans to pull based on student record instead of user record.
  • During the upgrade process, every user account will have the necessary information split out into a student record and then the student record will be attached to the user record.
  • Moving forward, when a new user registers, it'll create a user record and a student record.

Access Control

Right now we use a numeric index for determining what people can and can't do throughout the system. Instead, we should be using a role-based system where users can have multiple roles and that will determine what they can and can't do.

Moving to roles will also allow for changing terminology throughout the system from staff to instructors since I'm the only non-instructing staff member.

Needed Work

  • New roles table
  • New permissions table
  • New roles_permissions table
  • New users_roles table

Staff

Booking

Instead of having two different booking pages, this should be combined into a Book Now page that lets you answer some questions to figure out if you're trying to book a lesson or enroll in a program. From there, it would combine with the Find a Lesson Time page to give people a lot more flexibility when finding a time for a lesson.

Reporting

Currently reports are only company-wide, but with more instructors coming on, those reports need to be able to work for the entire company as well as individual instructors.

Appointment Management

@agentphoenix agentphoenix added this to the BookNow 2.0 milestone Jun 9, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant