jasig-ssp IRC Logs-2013-07-19

Owned by Apereo Infrastructure
Last updated: Jul 19, 2013
5 min read

[12:17:05 CDT(-0500)] <dmccallum54> TonyUnicon I pushed a fix for file upload errors

[12:17:22 CDT(-0500)] <dmccallum54> lots of detail in 500.jsp about what what going on

[12:17:28 CDT(-0500)] <TonyUnicon> wow

[12:17:37 CDT(-0500)] <TonyUnicon> I want to be you when I grow up

[12:17:43 CDT(-0500)] <TonyUnicon> thanks

[12:17:58 CDT(-0500)] <dmccallum54> np. also happened to fix SSP-846. which was nice

[12:18:24 CDT(-0500)] <dmccallum54> i'll leave it to you to implement the actual error handler

[12:18:38 CDT(-0500)] <dmccallum54> Dev Tools is telling me Ext.js is definitely parsing the response as valid json now, tho

[12:18:52 CDT(-0500)] <TonyUnicon> awesome

[16:56:03 CDT(-0500)] <dmccallum54> pspaude i saw your email to ssp-dev re SSP-1284. trying to duplicate the problem locally and failing

[16:56:11 CDT(-0500)] <dmccallum54> i am signed in as admin

[16:56:22 CDT(-0500)] <dmccallum54> who has no students, so my caseload is empty

[16:56:36 CDT(-0500)] <dmccallum54> i created a new student via caseload assignment

[16:57:14 CDT(-0500)] <dmccallum54> and i'm redirected back to the default view, with the caseload/student search on the left, the tool nav down the middle, and an empty tool pane on the right

[16:57:45 CDT(-0500)] <dmccallum54> am i misunderstanding the bug?

[17:09:19 CDT(-0500)] <JasonElwood> I submitted the ticket. what happened was the save/cancel action did "complete" and return to the list of students. We've seen this before when the appt api failed but the person succeeded.

[17:10:46 CDT(-0500)] <pspaude> Hmm that is different than mine. This is weird. I can replicate it on any role as long as you don't select a student first.

[17:11:23 CDT(-0500)] <pspaude> But, yes dan you are correct that is the right way to test.

[17:12:04 CDT(-0500)] <dmccallum54> pspaude is there a user in linux CI that exhibits the problem you emailed dev about

[17:13:15 CDT(-0500)] <pspaude> Yes, failing the issue that I'm seeing, just use a faculty role it happens reliably there.

[17:13:31 CDT(-0500)] <dmccallum54> k. will try. just a sec

[17:13:37 CDT(-0500)] <pspaude> Just tried on linux CI and replicated with jmartinez110. I use him alot.

[17:13:59 CDT(-0500)] <JasonElwood> it happened with the admin account

[17:14:35 CDT(-0500)] <pspaude> Yeah Jason I believe you, I have reproduced it with all the roles on my local.

[17:14:58 CDT(-0500)] <JasonElwood> cool

[17:15:15 CDT(-0500)] <JasonElwood> possibly stale code or missing perms?

[17:15:30 CDT(-0500)] <pspaude> It's not consistent, but I'm pretty sure it has to do with that profile tool and if it gets loaded "dynamically" or not just based on the bug tracing on the client side I was doing.

[17:15:40 CDT(-0500)] <dmccallum54> ok. i see it in linux dev with that user

[17:15:44 CDT(-0500)] <dmccallum54> linux ci, rather

[17:17:31 CDT(-0500)] <dmccallum54> ok. and i get it locally with that user too

[17:17:32 CDT(-0500)] <dmccallum54> ok

[17:17:47 CDT(-0500)] <dmccallum54> so the big thing that jumps out at me is that when i use that user, the search panel is expanded by default

[17:17:58 CDT(-0500)] <dmccallum54> anyone know off the top of their head what the rule is for that?

[17:18:15 CDT(-0500)] <dmccallum54> cuz it doesn't happen for admin locally, but he doesn't have anyone in his caseload either

[17:18:49 CDT(-0500)] <JasonElwood> I think it used to default to my caseload list but recently I noticed the search. I thought it was a browser issue

[17:18:53 CDT(-0500)] <pspaude> Hmm good point I forgot about that. Try other faculty roles and you will get that too.

[17:20:17 CDT(-0500)] <pspaude> My local admin, developer, and staff all do that. Got so used to it cause I thought it was just IE8 back yesterday when I was in IE8.

[17:21:04 CDT(-0500)] <pspaude> Yes Jason admin at least and I believe the others used to default to caseload.

[17:24:50 CDT(-0500)] <dmccallum54> looks like it's permissions driven somehow

[17:25:05 CDT(-0500)] <dmccallum54> coach-ish users get caseload search by default, faculty are getting student search by default

[17:25:45 CDT(-0500)] <pspaude> Makes sense, it is what I thought at first as well.

[17:25:48 CDT(-0500)] <pspaude> Changing permissions doesn't seem to help though. What permission would affect that?

[17:27:35 CDT(-0500)] <dmccallum54> looks like it's ROLE_PERSON_CASELOAD_READ

[17:28:07 CDT(-0500)] <dmccallum54> SearchViewController#initSearchGrid()

[17:28:07 CDT(-0500)] <JasonElwood> maybe I was testing with a faculty role, not admin. can't remember exactly but that does ring a bell

[17:28:56 CDT(-0500)] <dmccallum54> but anyway… if there's weird ordering assumptions re how tools get registered that just barely make it so that the main tool kinda happens to work, i could see permissions breaking that, since permissions drive tool visibility

[17:29:01 CDT(-0500)] <dmccallum54> anyway. i'll keep digging

[17:31:33 CDT(-0500)] <JasonElwood> Paul- ok to rebuild Linux CI?

[17:32:35 CDT(-0500)] <pspaude> Yes, go for it. I don't need it, I'll probably reset mine and clear my browsers cache as well to figure out when thsi is exactly happening.

[17:35:14 CDT(-0500)] <pspaude> That does make sense Dan, I didn't really think about it because I didn't think caseload mattered for faculty role. It also looks like by default facutly is not in the table for PERSON_CASELOAD_READ. I'll try adding it and see.

[17:41:51 CDT(-0500)] <dmccallum54> could be a red herring. just something that jumped out.

[17:42:35 CDT(-0500)] <dmccallum54> debugging further… it does seem that for faculty users that the event that should cause the ui to flip back to the student record view fires, but nothing receives it

[17:46:53 CDT(-0500)] <pspaude> yep that is correct. It fires everytime I think its part of CaseloadAssignementViewController, but if you look at MainViewController the listeners weren't added. Which is line 60 or so.

[17:49:02 CDT(-0500)] <dmccallum54> yeah. and now i'm getting it for all users...

[17:52:49 CDT(-0500)] <pspaude> Yep, that may be caching issues, but its where I'm at. (smile)

[17:59:05 CDT(-0500)] <pspaude> Ok, tried clearing all browser cache and temp files and issue still reappears with all users. I'm going to try the DB permissions edit and see, otherwise I'll reset Tcat and see if that helps.

[18:02:00 CDT(-0500)] <dmccallum54> oh i think it's a code issue

[18:02:59 CDT(-0500)] <pspaude> Yeah, but its weird the Linux CI doesn't do it so trying track down inconsistency. Plus I need to rebuild anyways, once this report gets edited.

[18:08:11 CDT(-0500)] <dmccallum54> weird. added logging to where that listener gets registered…. let's say maybe 1 time out of 10 the register happens for a user with no caseload

[18:08:45 CDT(-0500)] <pspaude> Alright, I gave faculty caseload read permission and the search is not expanded upon login and behavior is normal (you get returned to start screen after adding a student)

[18:09:14 CDT(-0500)] <pspaude> Hmm dan, that makes sense, I never hit it repeatedly more than 2 or 3 times with a non-caseload user

[18:09:41 CDT(-0500)] <dmccallum54> this is a good time, right here. a good time, i say.

[18:10:14 CDT(-0500)] <pspaude> Yes it is, expecially when you have tons of test## users in your database.

[18:10:38 CDT(-0500)] <pspaude> So, that your only resolve after this is to wipe the database (smile)

[18:14:26 CDT(-0500)] <pspaude> Dan, another tidbit I forgot, it also seems to work say if you have a conflicct between names. Also, I hit it repeadetly and now even with the added permissions, faculty still fails to return everynow and then. So, definately a code issue.

[18:32:35 CDT(-0500)] <JasonElwood> Calling is quits. didn't finish all the QA but did finish the doco. I'll get to the remaining items on Monday.