russtuck
commented
7 years ago I'm excited you're working on this. It's obviously critical to make the system work reliably, so it can be used. But it's also great experience to see your system getting real use, see what happens, and do the work necessary at this stage to make it work and succeed.
On Sat, Aug 19, 2017 at 9:36 PM, Eze Anyanwu notifications@github.com wrote:
These are some of the issues I encountered during the first checkin:
Documenting them here to keep track: New Rcis for the fall semester were not showing up
What the problem was:
We look for new RCIs to be generated by looking through the RoomAssign table for records that match the current session...except the official session was still "Summer Term". The Fall semester officially starts on the 30th of August, but RAs need to access the system and pre-fill stuff beforehand.
What I did:
TEMPORARY FIX - Edit the stored procedure to ignore that passed in parameter and look for room assign records for the Fall Semester.
Long-term fix:
Not sure yet 💡 Still thinking it over. New RAs can't log in!
What the problem was:.
The CurrentRA table is not up to date. I talked with Jay and that view is based on user roles within Active Directory, not Jenzibar. This means that something was off there. We have contacted NSG. Waiting till Monday morning for their reply.
How I fixed it:
Hopefully there will be nothing to fix once the Active Directory records are correct.
Long-Term Fix
Consider using our own CurrentRA and CurrentRD tables that are not based on Gordon systems? Then have the Housing Director update that. Polly can't log in!
What the problem was:
They renamed her Job_Title_Hall from "Chase Hall" to "Chase" in the CurrentRD table 🙅♂️ so the system wasn't finding a matching Building code in BuildingAssign.
What I did:
Renamed the BuildingAssign entry from "Chase Hall" to "Chase". 🎉
Long-Term fix:
This would be solved if we control what gets put into the CurrentRD table. (See earlier suggested solution) This Lewis Guy shows up multiple times for his room!
What the problem was:
The dude had 10 + Rcis with a CreationDate of August 18th. Turns out his RoomAssign record also had an AssignDate of August the 18th but with more accuracy (hours, minutes and seconds). So each time he/his RAs logged in on the 18th the system was comparing the two dates and finding that his RoomAssign record was more recent than his last RCI.
How I fixed it:
I didn't really. After the 18th had passed, new RCIs stopped being generated. So I just deleted all his old ones.
Long-Term Fix:
Make the CreationDate field more accurate?/precise? by adding hours, minutes and seconds. A certain RA can see all her residents' RCIs, but can't see her own!
What the problem was:
Remember how we fake-generated checkout RCIs at the end of the year last semester? Well we generated her RCI AFTER her new RoomAssign record had been created/updated. So this semester, the system was correctly seeing that rci.CreationDate > roomAssign.AssignDate and not generating anything.
How I fixed it:
I altered her RCI's creation date
Long-Term Fix:
Nothing. As long as we don't fake-generate RCIs like we did in the beginning, everything should be Gucci. ⚙️
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gordon-cs/Project-Phoenix/issues/172, or mute the thread https://github.com/notifications/unsubscribe-auth/AMCLmTB78TMYJzPNDl8NZVBr7Z2NmrHuks5sZ42KgaJpZM4O8fVk .
eanyanwu
These are some of the issues I encountered during the first checkin:
Documenting them here to keep track:
New Rcis for the fall semester were not showing up
What the problem was:
We look for new RCIs to be generated by looking through the RoomAssign table for records that match the current session...except the official session was still "Summer Term". The Fall semester officially starts on the 30th of August, but RAs need to access the system and pre-fill stuff beforehand.
What I did:
TEMPORARY FIX - Edit the stored procedure to ignore that passed in parameter and look for room assign records for the Fall Semester.
Long-term fix:
Not sure yet 💡 Still thinking it over.
New RAs can't log in!
What the problem was:.
The CurrentRA table is not up to date. I talked with Jay and that view is based on user roles within Active Directory, not Jenzibar. This means that something was off there. We have contacted NSG. Waiting till Monday morning for their reply.
How I fixed it:
Hopefully there will be nothing to fix once the Active Directory records are correct.
UPDATE: It was not an NSG issue. There is table in Active Directory that needs to be kept up to date with RA listings. Michael has permissions to edit that table but he has never done it. After check-in is over, I will need to set up a meeting between Jay/Chris and Michael so they can show him how to go about doing that.
For now, Jay has manually entered in this year's RAs
Long-Term Fix
~Consider using our own CurrentRA and CurrentRD tables that are not based on Gordon systems? Then have the Housing Director update that.~ The CurrentRA view can be edited by Michael using the AD table. The CurrentRD view is kept up to date by HR. Nothing needs to change here.
Polly can't log in!
What the problem was:
~They renamed her Job_Title_Hall from "Chase Hall" to "Chase" in the CurrentRD table 🙅♂️ so the system wasn't finding a matching Building code in BuildingAssign.~ This was probably our fault. After talking with Jay, I don't think the name ever changed, we probably had it wrong in Building Assign this whole time 🥇
What I did:
Renamed the BuildingAssign entry from "Chase Hall" to "Chase". 🎉
Long-Term fix:
~This would be solved if we control what gets put into the CurrentRD table. (See earlier suggested solution)~ 🐉 This would be solved if I don't make any more typos.
This Lewis Guy shows up multiple times for his room!
What the problem was:
The dude had 10 + Rcis with a CreationDate of August 18th. Turns out his RoomAssign record also had an AssignDate of August the 18th but with more accuracy (hours, minutes and seconds). So each time he/his RAs logged in on the 18th the system was comparing the two dates and finding that his RoomAssign record was more recent than his last RCI.
How I fixed it:
I didn't really. After the 18th had passed, new RCIs stopped being generated. So I just deleted all his old ones.
Long-Term Fix:
Make the CreationDate field more accurate?/precise? by adding hours, minutes and seconds. UPDATE: This is more easily done than said 💯 All I had to do was update the data type of the CreationDate table from
datetodatetime. The system was already supplying fullDatetimevalues, the database was just ignoring the rest.A certain RA can see all her residents' RCIs, but can't see her own!
What the problem was:
Remember how we fake-generated checkout RCIs at the end of the year last semester? Well we generated her RCI AFTER her new RoomAssign record had been created/updated. So this semester, the system was correctly seeing that rci.CreationDate > roomAssign.AssignDate and not generating anything.
How I fixed it:
I altered her RCI's creation date
Long-Term Fix:
~Nothing. As long as we don't fake-generate RCIs like we did in the beginning, everything should be Gucci. ⚙️ ~ This actually happened to a lot of people. So to fix it once and for all, I just changed the creation date of all the RCIs we fake-generated. I pushed them back o April 1st 🍶
An RA in Drew could not log in!
What the problem was:
This was a typo in BuildingAssign once more. The building code for Drew is DRW not DRE.
How I fixed it:
Change the building code in BuildingAssign from DRE to DRW. I also changed the building code in the xml file that contains room components. #173
Long-Term Fix:
I don't think any further action needs to be taken.
Ferrin Common Areas are not showing up!
What the problem was:
To figure out if an individual should have a common area rci: we look up the room number on their room assign record and trim off any letters from the end (BRO 207B becomes BRO 207). We then check to see if the resulting room number matches up with any apartment common areas in that building (rooms with max_capacity = 0, room_gender = null).
The ferrin room records are not consistent with the rest of the apartment-style records and have MAX_CAPACITY set to > 0 and ROOM_GENDER as non-null. Consequently, no common area RCIs are generated.
How I fixed it:
The way I see it, there are three options:
I went for the last option. Pull request coming in soon.
175
Long-Term fix:
The code change should fix the issue for Ferrin while still maintaining current functionality for the other apartment-style buildings.
People in different buildings don't seem to be able to log in!
What the problem was:
I am still figuring it out. The residents in question are getting the "Error" page when they try to log in. Nothing seems to be off with their records in the database. To start narrowing down the problem, I pushed the exception log branch to production so I can start seeing the logs of all the exceptions #168 . I have also added error checking to the dashboard controller #178 which is where the error was occurring.
UPDATE: This seems to be happening for multiple reasons, depends on the person.
1- Passwords with "<", ">" or other HTML-like characters in them. ASP.NET automatically does input validation, so on submitting a password with such characters e.g. ("
"), an exception is thrown and the error page is displayed. (Found this thanks to the logs). The fix for this was simple. All I needed to do was to add a[AllowHtml]attribute to the Login view model. #179The application "crashes" for random people and they loose the progress they have made!
What the problem was:
This a classic case when it is important to understand what the user means. When they say "crashes", they meant, they got the error page. Probing further with one person in particular, I figured out that he got a popup error saying "A Problem Occurred with this Webpage so it was Reloaded" right before. Once that popup appears, the page is reloaded and all their input seems to be lost.
Still working on figuring out the issue. The post here was very helpful. I have copied some of the relevant parts: