[12:08:19 CDT(-0500)] <JasonElwood> JS- are there any other conditions for the MAP plan status except a row in external_person_planning_status?
[12:40:03 CDT(-0500)] <js70> not at this time
[14:29:43 CDT(-0500)] <JasonElwood> JS- so I've tested this back and forth. I'm having problems with both the plan status and dev course indicator. A rows is returned with this query for the student I'm using. select * from external_person_planning_status where school_id = 'jgarcia35'
[14:31:18 CDT(-0500)] <JasonElwood> And the is_dev indicator doesn't appear to be saved on the plan. This query returns the course with is_dev = . select * from external_course where is_dev = 'Y' Is the value in external_course supposed to be some other value? It does show as false in map_plan_course when saved to a plan.
[14:32:48 CDT(-0500)] <js70> I'll check but I'm pretty sure is_dev = "Y" is correct.
[14:33:16 CDT(-0500)] <js70> hold on let me look.
[14:34:28 CDT(-0500)] <js70> is_dev is boolean on the PlanCourse
[14:34:43 CDT(-0500)] <js70> there may be a translaction issue.
[14:36:10 CDT(-0500)] <js70> I just tested that the indicator worked if planCourse is_dev was true
[14:37:30 CDT(-0500)] <JasonElwood> it's definitely is_dev = Y in external_course. when that course is dragged to a plan, is_dev = f in map_plan_course
[14:38:39 CDT(-0500)] <js70> is_dev = ? in map_plan_course?
[14:38:51 CDT(-0500)] <JasonElwood> false
[14:39:17 CDT(-0500)] <JasonElwood> when I manually update it to true, the indicator shows up. looks like the value isn't being carried over from external_course
[14:39:31 CDT(-0500)] <js70> yep, thats whats happening
[14:39:49 CDT(-0500)] <js70> didn't think to test that part.
[14:39:52 CDT(-0500)] <js70> like a dope.
[14:40:04 CDT(-0500)] <JasonElwood> but I know that has worked because I've seen the Dev Cr Hrs total show more than zero
[14:40:33 CDT(-0500)] <js70> yeah, if the plan_course_dev was set by hand perhaps?
[14:41:21 CDT(-0500)] <JasonElwood> if is_dev in external_course should be Y or N, then we have a problem. And, I'll open a ticket
[14:43:52 CDT(-0500)] <js70> we have a problem external bools are standardized on Y,N operational appears to be boolean.
[14:45:04 CDT(-0500)] <dmccallum54> we have hql querying that external field directly with true/false?
[14:46:39 CDT(-0500)] <JasonElwood> the calculation of Dev Hrs on the plan used to work
[14:47:29 CDT(-0500)] <js70> No, pretty sure this is all client side concerns.
[14:47:43 CDT(-0500)] <JasonElwood> I created 1454
[14:48:48 CDT(-0500)] <JasonElwood> the were another question about the planning_status. similar situation where the row exists in the database, but the status on the MAP shows "Student is Currently: No Status"
[14:49:13 CDT(-0500)] <JasonElwood> I can create a ticket if you don't think it is a data issue
[14:50:19 CDT(-0500)] <JasonElwood> external_person_planning_status.status = OFF or ON
[14:50:39 CDT(-0500)] <js70> better create a ticket
[14:50:47 CDT(-0500)] <JasonElwood> np
[14:54:23 CDT(-0500)] <JasonElwood> re-opened 968
[14:54:34 CDT(-0500)] <js70> k
[15:09:36 CDT(-0500)] <JasonElwood> JS- is there any scenario where a course in a start term of the Move Plan feature would not move?
[15:09:58 CDT(-0500)] <js70> yeah, when its in the past
[15:10:09 CDT(-0500)] <js70> or its a transcript
[15:10:42 CDT(-0500)] <js70> everything in spring 2013 and earlier should not move
[15:11:03 CDT(-0500)] <js70> any transcripted course thats in the CORRECT term will not move.
[15:11:21 CDT(-0500)] <JasonElwood> even if the course is a planned course?
[15:11:31 CDT(-0500)] <js70> but right now, even if its not in the transcript, if its in the past it won't be moved.
[15:11:37 CDT(-0500)] <js70> yep
[15:11:39 CDT(-0500)] <JasonElwood> past I'm good with
[15:11:45 CDT(-0500)] <JasonElwood> that should never move
[15:11:57 CDT(-0500)] <js70> kool. your idea :^)
[15:12:23 CDT(-0500)] <dmccallum54> i know that's what the spec says, but does that make sense for templates?
[15:12:41 CDT(-0500)] <js70> good question, wondered that myself
[15:12:49 CDT(-0500)] <dmccallum54> "oops, i forgot to bump the template i made last semester before the semester elapsed!"
[15:13:20 CDT(-0500)] <JasonElwood> I can't remember what I documented, but we discussed allowing anything for templates
[15:14:03 CDT(-0500)] <JasonElwood> I'm thinking about the is_transcripted not moving. that means a course is on the plan AND in the transcript right???
[15:14:11 CDT(-0500)] <js70> could be, detailed reading of documentation is not a forte of mine
[15:14:26 CDT(-0500)] <js70> no
[15:14:29 CDT(-0500)] <JasonElwood> I'll check it
[15:14:53 CDT(-0500)] <js70> wait a sec,
[15:15:00 CDT(-0500)] <dmccallum54> i'm fairly certain at the last discussion we agreed no moving of planned stuff in the past for plans or templates
[15:15:05 CDT(-0500)] <js70> yes that is correct but only the plan course will be on the page
[15:15:15 CDT(-0500)] <js70> or in the plan.
[15:15:26 CDT(-0500)] <js70> the course just knows it has a transcripted course.
[15:16:07 CDT(-0500)] <JasonElwood> it makes sense. I think my sample data is just throwing it off.
[15:16:49 CDT(-0500)] <JasonElwood> for moving past terms in templates, the documentation is only for current and future terms
[15:16:51 CDT(-0500)] <js70> there is a possible hickup since transcripted courses use formattedCourse while the plan_course use the code.
[15:18:01 CDT(-0500)] <js70> plan_course use formattedCourse to match with formattedCourse in transcript but its my understanding code guarantees uniqueness.
[15:18:22 CDT(-0500)] <JasonElwood> I think it works fine, just didn't expect it
[15:18:40 CDT(-0500)] <js70> k
[15:19:20 CDT(-0500)] <JasonElwood> I'll test this, but for moving templates … aren't we allowing for manual moving of courses in past terms?
[15:20:05 CDT(-0500)] <js70> short answer - yes
[15:20:55 CDT(-0500)] <JasonElwood> as a user, I would expect the move plan to move courses in past terms because I can manually move them. Make sense to everybody else?
[15:23:36 CDT(-0500)] <js70> you mean courses that are not in transcript?
[15:23:56 CDT(-0500)] <JasonElwood> no, for templates. allow the start term to be a past term.
[15:24:06 CDT(-0500)] <js70> sure, that makes sense.
[15:24:19 CDT(-0500)] <JasonElwood> good catch guys
[16:53:40 CDT(-0500)] <pspaude1> Anyone else having issues with i000038.xml not running due to failure in precondition? I'm on postgres and my db is clear of previous references.
[16:58:02 CDT(-0500)] <dmccallum54> what is the actual error
[17:19:44 CDT(-0500)] <pspaude1> I can't get back to the log statement again. I'm stuck now without it loading at all, it's saying db_username_liquibase can't be found.
[17:20:17 CDT(-0500)] <pspaude1> Anyways, before it said it wasn't executing due to the sql check in the precondition of something of that nature.
[17:23:51 CDT(-0500)] <dmccallum54> i see the problem for db_username_liquibase. one sec
[17:37:20 CDT(-0500)] <dmccallum54> pspaude1 try again?
[17:39:39 CDT(-0500)] <pspaude1> Alright, trying it now.
[17:50:30 CDT(-0500)] <pspaude1> Ok looks like your fix worked. No db_username issues.
[17:50:39 CDT(-0500)] <dmccallum54> preconditions still failing?
[17:51:58 CDT(-0500)] <pspaude1> Yes, its skipping it based on the precondition. No errors. It just isn't doing a good job of checking if the table exists. Because the table and v_table doesn't exist nor is the xml in my changelog.
[17:53:18 CDT(-0500)] <dmccallum54> i000038.xml still?
[17:54:03 CDT(-0500)] <pspaude1> Yes, am looking at it now.
[17:54:14 CDT(-0500)] <dmccallum54> k. in middle of build. can check in a bit
[17:56:33 CDT(-0500)] <pspaude1> Hmm it's not the check I thought it was, its the standard manage integration database precondition.
[17:57:04 CDT(-0500)] <tbain1> I just did a simple write-up of the solution I have for SSP-1411 as a comment on the parent ticket; https://issues.jasig.org/browse/SSP-1402 - let me know if you think there is anything I need to clarify - and I apologize if it's a little weird, I typed it up during a Dev forum so it was difficult to concentrate. 
[17:59:28 CDT(-0500)] <dmccallum54> tbain1 thx
[17:59:37 CDT(-0500)] <dmccallum54> can you re-write it in scala now, pls
[18:01:06 CDT(-0500)] <tbain1> sure
[18:01:09 CDT(-0500)] <pspaude1> I don't think he can, he needs to learn what a Functor is first
[18:01:24 CDT(-0500)] <pspaude1> Then Monads
[18:02:13 CDT(-0500)] <dmccallum54> he'll be a better person for it
[18:02:34 CDT(-0500)] <pspaude1> He just learned what they are. So did I.
[18:02:57 CDT(-0500)] <pspaude1> Ok, I took one of the headers from another changeset I know works and transposed in on the changeset and see if that works.
[18:03:01 CDT(-0500)] <tbain1> Functors and Monads
[18:03:02 CDT(-0500)] <dmccallum54> pspaude1 i'm not getting any sort of error or failure from i000038.xml
[18:03:07 CDT(-0500)] <tbain1> A programmer named these things.
[18:03:26 CDT(-0500)] <dmccallum54> a high priest programmer named those things
[18:03:44 CDT(-0500)] <tbain1> with a great white beard
[18:04:15 CDT(-0500)] <pspaude1> Yeah, it doesn't error or failure, just says its skipping it. The failure comes in SSP when you try to use it!
[18:04:36 CDT(-0500)] <dmccallum54> js70 look at that student search scream
[18:04:56 CDT(-0500)] <dmccallum54> pspaude1 yeah mine ran just fine. and even created the table and view
[18:05:08 CDT(-0500)] <dmccallum54> you in the big show or listening in at your desk?
[18:05:20 CDT(-0500)] <js70> :^)
[18:05:27 CDT(-0500)] <pspaude1> Awesome! I'll have to try that out. I hope my earlyalert fixes doesn't slow it, but it seemed faster on my local.
[18:05:35 CDT(-0500)] <pspaude1> I'm at the big show
[18:05:38 CDT(-0500)] <dmccallum54> k
[18:09:55 CDT(-0500)] <pspaude1> Alright, still skipped due to precondition. I deleted the precondition and am trying again. This must be an inconsistency on my machine somehow.
[18:34:35 CDT(-0500)] <pspaude1> Well it ran successfully once the precondition was gone. Weird, the other new changesets ran fine.
[18:34:59 CDT(-0500)] <pspaude1> But, the search feature is nearly instantaneous on local now!!!
[18:35:15 CDT(-0500)] <dmccallum54> we'll see if the CI envs have the same LB issue