[11:15:24 CDT(-0500)] <pspaude1> Jason do we have to fix how student_type sync behaves in light of SSP-1443?
[11:16:31 CDT(-0500)] <pspaude1> Basically if student_type is null or empty search doesn't work and caseload assignment has a visual fit.
[11:16:51 CDT(-0500)] <pspaude1> However, student_type_code sync was designed to set student_type to null if StudentTypeUnsetFromExternalData is true based on discussion during that issue.
[11:18:56 CDT(-0500)] <JasonElwood> setting to null should work fine
[11:19:10 CDT(-0500)] <JasonElwood> so you are saying that a null in the results blow things up
[11:20:09 CDT(-0500)] <pspaude1> Blows the caseload assignement appointment screen up yes, but that should be a bug I can fix.
[11:20:58 CDT(-0500)] <JasonElwood> cool. and search the same?
[11:21:09 CDT(-0500)] <pspaude1> However, student search doesn't work with student_type to null or empty per SSP-1443.
[11:21:49 CDT(-0500)] <pspaude1> So, we have a config option and potential for users to set the type to null from external data, and then when they do, they won't be able to find that student in search.
[11:22:05 CDT(-0500)] <JasonElwood> so this would only occur if a student were succesfully added with a student type (or coach for that matter) then unset = true and the student type were null in external data?
[11:22:36 CDT(-0500)] <pspaude1> Yes, or syncd over from external data and it was null in the first place.
[11:22:37 CDT(-0500)] <JasonElwood> and the sync over-wrote the selected value when the student was added
[11:22:47 CDT(-0500)] <pspaude1> yes
[11:22:49 CDT(-0500)] <JasonElwood> it can't be null in the first place
[11:22:56 CDT(-0500)] <JasonElwood> the UI requires a coach and type to add
[11:23:43 CDT(-0500)] <pspaude1> Right, I forgot it shows a blank value but you have to select one.
[11:24:11 CDT(-0500)] <dmccallum54> pspaude1 different topic… what was the API access denied error you got in Linux CI?
[11:24:25 CDT(-0500)] <JasonElwood> so we just need to handle that sync over-write scenario to make sure caseload and search results don't blow up
[11:24:29 CDT(-0500)] <pspaude1> Ended up being my fault I'm sorry, was timed out.
[11:25:04 CDT(-0500)] <pspaude1> Found out the cause is student type when null or blank is not searchable per SSP-1443 but when unset from external data it can become null.
[11:25:54 CDT(-0500)] <pspaude1> Jason, yes, but what should student type be if its null in external data?
[11:27:52 CDT(-0500)] <JasonElwood> I don't remember exactly where we left this (Dan needs to refresh my memory as usual), but I thought we established that the sync won't over-write an existing value with a null.
[11:29:50 CDT(-0500)] <pspaude1> I thought it ended up with the discussion saying it was to be like Coach Sync and could be unset (null) from external data.
[11:30:10 CDT(-0500)] <pspaude1> Looking at the code now and that is how it works.
[11:31:31 CDT(-0500)] <dmccallum54> sync will overwrite student type will null only if that particular "unset" feature is enabled
[11:31:46 CDT(-0500)] <dmccallum54> if it makes no sense to do so, we should back out that option
[11:31:47 CDT(-0500)] <JasonElwood> so if null is in the external from either, it should just be null. coach or type. we just need to ignore the nulls so the code doesn't blow up
[11:31:58 CDT(-0500)] <dmccallum54> it was added for symmetry with handling of coach linkage
[11:32:16 CDT(-0500)] <pspaude1> Dan is correct see comments on SSP-867
[11:32:36 CDT(-0500)] <dmccallum54> but we use student_type to discriminate between students and non-students. we don't do that for the coach field. so a null in student_type is more… consequential.
[11:32:40 CDT(-0500)] <JasonElwood> symmetry is fine and predictable. we can't predict what the client will do but we can set the expectation
[11:33:00 CDT(-0500)] <dmccallum54> is there any reason a client would need to say "this student is no longer actually a student"?
[11:33:25 CDT(-0500)] <JasonElwood> I wouldn't expect that to be determined by student type but very well could be
[11:33:33 CDT(-0500)] <JasonElwood> I would expect it to be done with program status now
[11:33:42 CDT(-0500)] <dmccallum54> we use student_type in reports
[11:33:50 CDT(-0500)] <dmccallum54> and i think we now use it in student search as well
[11:34:36 CDT(-0500)] <JasonElwood> so no student type = not in results
[11:35:40 CDT(-0500)] <dmccallum54> https://issues.jasig.org/browse/SSP-1443
[11:38:02 CDT(-0500)] <JasonElwood> regroup here… what's the remaining issue? Paul is going to look at the caseload assignment blowing up on null student type. Is there an issue still with caseload search results?
[11:38:39 CDT(-0500)] <dmccallum54> i'm not aware of an issue with caseload search results, but i might have missed that
[11:39:04 CDT(-0500)] <pspaude1> No issue with caseload search.
[11:39:18 CDT(-0500)] <dmccallum54> if i understand correctly, there are two issues… 1) caseload assignment cant cope with a person with a null student type and 2) we're not sure it should be possible for external data to delete a person's student_type
[11:39:19 CDT(-0500)] <JasonElwood> so we are ok with a fix for the caseload assignment, and all is good?
[11:39:58 CDT(-0500)] <JasonElwood> 2) seems ok to me. They have options to not unset and control over the data.
[11:41:39 CDT(-0500)] <JasonElwood> Gotta bail for a while.
[14:23:45 CDT(-0500)] <TonyUnicon> org.hibernate.exception.SQLGrammarException: ERROR: column this_.race does not exist
[14:23:46 CDT(-0500)] <TonyUnicon> Position: 879
[14:23:46 CDT(-0500)] <TonyUnicon> at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:122) ~[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
[14:23:46 CDT(-0500)] <TonyUnicon> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) ~[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
[14:23:46 CDT(-0500)] <TonyUnicon> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) ~[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
[14:23:46 CDT(-0500)] <TonyUnicon> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) ~[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
[14:23:51 CDT(-0500)] <TonyUnicon> after update
[14:25:17 CDT(-0500)] <pspaude1> Does the log say where in the changeset there are two things going on in that one.
[14:25:36 CDT(-0500)] <TonyUnicon> you have to change the pojo to coincide with the column name change
[14:25:36 CDT(-0500)] <dmccallum54> that's hibernate
[14:25:54 CDT(-0500)] <TonyUnicon> the member race should be renamed to raceCode
[14:26:15 CDT(-0500)] <pspaude1> Ah, dang I forgot. I changed that but didnt commit because was modifying PersonSearch to return null for the other issue. Sorry, one sec.
[14:26:21 CDT(-0500)] <TonyUnicon> no worries
[14:27:06 CDT(-0500)] <dmccallum54> http://stackoverflow.com/questions/1085162/how-can-i-commit-only-part-of-a-file-in-git
[14:27:45 CDT(-0500)] <pspaude1> It's not the same file, just my mind ignored .java since I knew i had changes that shouldn't go.
[14:27:56 CDT(-0500)] <pspaude1> Unless git can fix my mind filtering 
[14:28:29 CDT(-0500)] <TonyUnicon> slated for the next release i hear
[14:32:48 CDT(-0500)] <TonyUnicon> ahh the old columnDataType mssql trap
[14:33:01 CDT(-0500)] <TonyUnicon> probably had to do that 3 or 4 times myself
[14:33:23 CDT(-0500)] <TonyUnicon> and yet i forget everytime
[14:33:27 CDT(-0500)] <dmccallum54> obnoxious
[14:33:37 CDT(-0500)] <dmccallum54> of course, so was my behavior, i guess, since i clearly hadn't tested it