Checkout Subsystem

[gordon-cs]

Checkout Subsystem

[superpowers11]

Still feels a little weird to me, like there should be a more intuitive way to store this information.

---

But I suppose we could have a button or check box for Improper Checkout and one for Lost Key...

• When you select it during checkout, the system generates both a new RciComponent named "Improper Checkout" or "Lost Key" for that Rci, as well as an entry in the Fine table for that RciComponent.
• Then we wouldn't have to worry about the Improper Checkout weirdly showing up as a component on the RCI, since it wouldn't have been generated until checkout is being completed.
• We could also add a condition on the RciComponent's that get displayed, so that Improper Checkouts and Lost Keys are filtered out.

[eanyanwu]

I think this is safe to close....closing...

[superpowers11]

@eanyanwu this is looking really good so far!
As far as associating a GordonID with a fine though, for now I am thinking it would be good for the system to automatically assign the GordonID of the user (in which case it would just be null for Common Area), so that at least that col of the Fine table is being filled. This will help for the demonstration of the Export Fines functionality.
Later, after we talk to MC, we can add the ability to assign a specific, non-null GordonID for common areas.

[eanyanwu]

Sweet i'll be pusing that change to #41 within the hour
EDIT: Done.

[superpowers11]

Add ability to demarcate an improper checkout. In the database, I believe an improper checkout is indicated in the db as a null value for the RCIComponent.

[eanyanwu]

I'm toying with the idea of an easier way to do improper checkout:

• Make an RciComponent called Improper Checkout. Doing it this way will keep the association between fine and rcicomponent, and by the transitive property, rci.
• Representing an improper checkout as a fine without rcicomponent, just leaves us with the ID number to tie to the student. But what if the student has had multiple improper checkouts? How to differentiate?

[superpowers11]

Good point that there could be a better way to do improper checkout.
But regarding your two points:

• I am not sure if using RciComponent for Improper Checkouts is going to exploit that column too much. RciComponent is not technically a foreign key at this point I don't think, but might as well be. So it will be kind of weird if in the Fines table, you have a bunch of these RciComponent's that don't correspond to actual components in the RCI. So would you automatically give each Rci an Improper Checkout RciComponent, when you create the Rci? And this component may or may not be used for anything, depending on whether or not the resident has an improper checkout? That seems kind of counter-intuitive, if generally an RciComponent refers to a concrete room component, except for the case where it refers to the abstract concept of an improper checkout.
• What if in the Fine table we add boolean column for improper checkout, and add a column for the RciID?

[superpowers11]

Also, I made a comment on your most recent pull request #65 @eanyanwu , which I probably should have made here - we should be consistent with how fine dollar amounts are displayed after they get added. I am thinking it should always display $5.00, regardless of whether the user input 5, 5.00, or $5.00.

[eanyanwu]

Hmm about the issue of improper checkouts:
You are right that it seems inconsistent. It would also introduce edge cases where a resident will see an rci component called "Improper Checkout" on their rci.

What if in the Fine table we add boolean column for improper checkout, and add a column for the RciID?

That would be a bit redundant for other fines, no?
🙅 🙅‍♂️ I like how we currently have fines and damages linked to specific components and the components linked to rcis. It's clean.

Hmm... I'll brainstorm some more about improper checkout.

[eanyanwu]

Hmm...I decided to check how paper rcis list improper checkouts. Improper checkouts and lost keys are listed as normal component items.

[eanyanwu]

I like that!
The reason I was reticent about adding an RciID to the fines table is as follows:
Supposing you get a fine. It is attached to both your rci and rcicomponent.
Then, there is the possibility that that rcicomponent gets reassigned to another rci. When this happens, it would be a pain to also go through the fines associated with the component to change their rciids as well.

I must note that the above scenario might never even happen since no RA will be reassigning components for RCIs they have already checked out....However, the POSSIBILITY of inconsistency is still there.