Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues encountered during the second checkin #194

Open
eanyanwu opened this issue Aug 17, 2018 · 2 comments
Open

Issues encountered during the second checkin #194

eanyanwu opened this issue Aug 17, 2018 · 2 comments

Comments

@eanyanwu
Copy link
Member

This will hopefully be helpful for anyone maintaining this down the line.

An RD was not able to see the RCIs for her building
Steps

  • The CurrentRD table has the list RDs. Let's check that first and make sure said RD is listed.
  • Turns out she isn't. HR had assigned her to another position, and removed her position as RD from their database. She would still be working as an RD, so Jay asked someone from HR to restore her RD employment designation.

MC sent a list of this year's RAs/ACs ~ requests that they be put in the system so they can start using it
Steps:

  • Ideally, the CurrentRA view will be kept up to date, and update as new RAs get their assignments. However, this is not always the case, so it's always safe to check.
  • Take a look at the CurrentRA view and make sure the listed RAs/ACs match up with the list that MC sent. If they don't, flag the issue with someone at CTS. If they they match, there is nothing more to do. The system will identify the new RAs and allow them to see their Residents' RCIs.

A Fulton RD is seeing that some of her residents' RCIs are green. They should be Blue, because its checkin season 🍭
Steps:

  • This requires a bit of investigation. But first some background info to help:
    • A new RCI is always blue and stays that way until the RD signs it. This is considered "Checkin"
    • Once the RD has signed it, it turns Green, which indicates that it's ready for "Checkout"
    • So naturally, all new RCIs for a session should always be blue.
  • I checked the Rci table and looked at the RCIs for Fulton. RDs only see RCIs that have the IsCurrent column set to 1 (true).
  • Sure enough, among the Current RCIs are 4 RCIs that have an RD signature. (Which is why they are green).
  • However, these four RCIs are not for a past session, so they should be archived anyways.
  • The more interesting problem is that no new RCIs for these 4 students exist, which I assume is the main problem.
  • TIP: When a person is supposed to have an RCI for session A (i.e. they have a room assignment for that session), but doesn't, it is almost always because the creation date of their last RCI is later than the assignment date of their most recent room assignment.
  • That was the case here. For each of the 4 students, their most recent room assignment (that should have a matching RCI) is listed as being assigned early in 2018 (say, March). However, their last RCI for the past session was created in May. So when new RCIs are being generated, no new one for this session will be created. (See the section about Rci Generation in the project's readme to understand why this is so)
  • A quick solution is to set the creation date of these 4 old RCIs to a day before March.
  • This solves the issue for the user, but does not solve the bigger issue. The rci creation date should always match the assignment date of the corresponding room assignment. Except sometimes it doesn't. My hypotheses is that the RoomAssign table is not updated consistently, especially when documenting room assignment in the middle of the semester. I'd have to have a chat with whoever does that.
@eanyanwu
Copy link
Member Author

Two students who lived in Summer housing in Ferrin who don't have fall RCIs listed (only summer)
Steps

  • I was given the names of the two students.
  • I looked them up in the Accounts table to get their student ids. Then used the student ids to find the RCIs in question. Since the RCI generation process only cares about Current rcis, I further filtered the query to only include RCIs where IsCurrent is true.
  • I then also looked up the room assignments for one of them.
  • I noticed that both residents stayed in the same room from summer housing to the fall semester. This threw the FindMissingRcis stored procedure off.
  • Hmm looks like i haven't seen this case before.
  • This is a tricky one to solve for good. The main issue here for future maintenance is that I am the only one that understands the FindMissingRcis stored procedure...and I can't possible figure out all the edge cases. Its a odd select statement that I came up that takes care of ~90%-95% of the cases properly. But the other 5% (which are edge cases that are bound to happen) are tricky to figure out.
  • I might need to make an issue to revisit the rci generation process. We tried to strike a balance between ease for the user (they don't have to do anything) and ease for the developer (100% hard because that stored procedure is almost like a black box). I might need to rethink that 🤔
  • The quick solution for now is to delete the current summer rcis for these two students.

@eanyanwu
Copy link
Member Author

eanyanwu commented Sep 6, 2018

Yet another student cannot see her rci for the current semester
Steps

  • Examined the rcis she has as well as the room assign record for her.
  • This seems to be yet another case of ROOM_ASSIGN weirdness where the record changes after the rci has been created.
  • In this case, the fix to this was setting the creation date of her 201801 conrad rci back to sometime before the assignment date of her current conrad room assignment (confusing, i know. Hopefully this convoluted logic will soon go away)

I REALLY need to figure a simpler procedure for generating rcis that does not assume that much about the ROOM_ASSIGN table. I have a simpler idea that will work, but will need to wait after checkin to try it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant