Summary

When going to precios/alumnos we get a false positive in the Alumnos nav. This is due to how it is currently checking for current page.

TODO

• Improve nav check to be more exact

TODO

• Next auth (probably just email/username password)

Although I wanted to go with this approach. It seems like there is no prisma adapter to do credentials login:
https://next-auth.js.org/providers/credentials

Instead of having two views for classes and payments, rather show a history with cards.

Initial approach:

When a class session is about to be created, students may or may not have the required amount of hours to make up for what the class requires.

So if they turn to be negative, they should somehow pay for those hours, but simply subtracting their hours gives no context whatsoever as to how they're consuming the hours (and how much they should pay for their debt later on).

So it would be useful if we can detect which students are the ones that don't have enough hours and allow the user to set either the rate that they should pay those hours for or simply registering how much should they pay for that debt.

Proposed approach

• Class creation form should either async validate or handle in backend when there are students that don't have enough hours.
• if all okay, simply create the class and subtract the hours from each.
• if there are students that don't have enough hours to cover for the class, they should be pointed out, but this BEFORE class creation, so we make sure that the class is created only after the debts have been set.
• Once the debt have been set, class should create successfully. And the students that did not have enough hours for the class will be left as debtors

Tech considerations

• Create StudentDebt table with studentId hours rate (which could also be custom)
  thought about using Hour here but since I want to be able to set a custom rate it might not be enough
• In student detail view, debt should show with hours and the total amount that they owe
• The debt should be set in the same transaction as the class session creation to avoid creating debts if the class session fails to create

Prisma already uses decimal.js underneath. So we can remove the library from our main dependencies, and let us use Prisma's internal decimal.js.

There are situations where a single payment could cover multiple debts.

So the question here has to do whether we want to remove the uniqueness constraint of paymentId in StudentDebt

Currently:

model StudentDebt {
    id             String  @id @default(cuid())
    hours          Decimal
    studentId      String
    paymentId      String? @unique
    classSessionId String
    rate           Decimal
    restored       Boolean @default(false)

    classSession ClassSession @relation(fields: [classSessionId], references: [id], onDelete: Cascade)
    payment      Payment?     @relation(fields: [paymentId], references: [id])
    student      Student      @relation(fields: [studentId], references: [id])
}

Summary

Alumnos view overflow has been broken for some time. We should look into it and improve its layout to allow it to properly overflow if it goes off-screen

Summary

I believe this is specific to removing students while creating a class session.
Removing a student from a list of already-complying students, should not flash the warning message.

Repro steps

1. Go to /clases
2. Click on create class
3. Fill out the form and add some students
4. Fix their debts
5. Remove a student
6. Debt warning flashes the screen and disappears

Summary

Some modals are not properly styled and don't have a backdroop

• Teacher delete confirmation modal
• Student hour prices create/edit modal, delete confirmation modal

It would also be nice to include in here a better padding approach for modals which looks really odd as well as their responsiveness

Instead of requiring typing everytime a student gets registered, we could add tables for universities, faculties and course of studies so that those can be loaded from a react-select rather

This table is doing nothing but increasing the app's data complexity by obscuring a simple number.

Maybe I regret this later, but this is my call right now.
I don't need hour entities if all they're going to hold is simply an int value

Flow on creation

Class sessions can be either created on the go within a student or created separately

Creating on the go

When we’re in the Student view we can assign that student a class.

The opening form should allow the user to create a class on the go. We can do this with a checkbox to determine whether we want to create it there OR choose an existing class (if any, if there are no future classes we should not allow the user to assign a class, thus they will have to create one there)

If successful the class session will be created only for the given student
( or also allow to add more students here?) => maybe not. TBD

Creating on separate view

Class session view will allow to create a class session with multiple students at the same time. Should be able to be created without students as well, maybe as a placeholder.

Pay debts partially

I think this would be cool since there may be students that may not want to pay all the debt upfront but instead pay a part and then pay another part later.

If we don't provide this we would be leaving this use case out of the app

Complication

One major thing I am a bit concerned about when thinking about implementing this is the fact that a single student can have multiple debts.

So partial payment would involve having to take into account the fact that students that have multiple debts, should cover them from oldest to newest.

Initial approach

• We need to check up to which debt the student would be paying. And thus break that one into two separated debts, one paid and another unpaid if they don't cover for it completely.
• Must also take into account that we will have to create multiple payments, one for each StudentDebt that is fulfilled. This in favor of keeping the uniqueness of paymentId across StudentDebt entities. (Not sure whether this is the right call Spinoff somewhere else: #13 ).
• Break student debts into two debts, one of them is paid and the other is to be paid. Old debt can definitely be deleted since the new debts are the representation of the previous debt

Mock

[WIP]

Instead of having two views for teacher payments and teacher classes, merge both into one

Maybe we need not a table but instead make this cards

Initial approach: