...
[15:56:55 CDT(-0500)] <dmccallum54> think all the pointers to it would remain "course_code"
[15:57:26 CDT(-0500)] <JasonElwood> I would have to change the tattoo I just got
[15:57:49 CDT(-0500)] <dmccallum54> you're an addict i'm sure. probably welcome it.
[15:58:06 CDT(-0500)] <js70> addicted to blood
[16:01:51 CDT(-0500)] <TonyUnicon> it will be fine
[16:18:28 CDT(-0500)] <dmccallum54> JasonElwood the 'on/off plan' feature...
[16:18:39 CDT(-0500)] <dmccallum54> wireframe suggests that status comes from external data
[16:19:23 CDT(-0500)] <dmccallum54> feel like we talked about this a long time ago, but dont recall any details of how that's supposed to work
[16:21:29 CDT(-0500)] <JasonElwood> that's correct. on or off in the data. and a reason for off
[16:23:31 CDT(-0500)] <dmccallum54> so there is another external table that contains plan statuses per person? external currently knows nothing at all about plans
[16:23:54 CDT(-0500)] <dmccallum54> or on/off plan is purely operational and we need a dialog for advisors to set that data?
[16:24:22 CDT(-0500)] <JasonElwood> nobody can change it. Sinclair calcs it outside of SSP and populates the field in the external data
[16:24:40 CDT(-0500)] <dmccallum54> sorry… what field? how does external know about plans?
[16:24:50 CDT(-0500)] <dmccallum54> it's just person scoped and you hope it matches up with the current plan?
[16:25:10 CDT(-0500)] <dmccallum54> "it" being the person-scoped status
[16:25:50 CDT(-0500)] <dmccallum54> is it like....
[16:26:45 CDT(-0500)] <dmccallum54> backend system X calls the getPlan API for a person and checks that against actual enrollment/transcript, then sets a status in a external table using the plan ID it retrieved from the original getPlan call?
[16:27:06 CDT(-0500)] <dmccallum54> if that's the case i'm not so sure external data is what actually makes sense here
[16:27:13 CDT(-0500)] <dmccallum54> that sounds like setting operational state to me
[16:27:49 CDT(-0500)] <dmccallum54> since "plans" are not in any way "owned by" external systems
[16:29:19 CDT(-0500)] <JasonElwood> my understanding is analyze the plan (not sure how) and update the external field. the off plan field is related to person
[16:30:10 CDT(-0500)] <dmccallum54> ok. so a person either has or doesnt have some sort of planning problem. i can see that being external data. and we just throw a flag up on screen, regardless of what your current plan happens to be.
[16:30:21 CDT(-0500)] <dmccallum54> that more or less the idea?
[16:30:33 CDT(-0500)] <JasonElwood> yep
[16:30:45 CDT(-0500)] <dmccallum54> thx
[16:46:30 CDT(-0500)] <js70> I have a fix for https://issues.jasig.org/browse/SSP-924 and https://issues.jasig.org/browse/SSP-9243. Should I check into 2.0 or 1.2
[16:47:28 CDT(-0500)] <dmccallum54> js70 i think it affects 1.1, 1.2, and 2.0. so all three
[16:48:58 CDT(-0500)] <js70> I think its ok in 1.1, Jason was able to pull the report from that version.
[16:49:00 CDT(-0500)] <dmccallum54> if you changed the url for 923, gunna need to update API docs too
[16:49:08 CDT(-0500)] <js70> k
[16:49:35 CDT(-0500)] <JasonElwood> I wasn't able to as a coach
[16:49:52 CDT(-0500)] <dmccallum54> i'm lookng at the 1.1 code. it's exactly the same
[16:49:53 CDT(-0500)] Wiki Markup <js70> yeah, I changed it to the person/{personId}/history/print
[16:49:56 CDT(-0500)] <js70> k
[16:50:42 CDT(-0500)] <js70> so, check into 2.0 and cherry pick to 1.2 and 1.1?
[16:51:10 CDT(-0500)] <dmccallum54> (not saying changing the api was wrong (that's what the ticket called for) just that the docs need updating. historically we've done that with a separate ticket so the API change is super obvious in the automated release changelist from jira)
[16:51:23 CDT(-0500)] <dmccallum54> js70 that's right
[16:52:00 CDT(-0500)] <js70> perfect.
[16:52:00 CDT(-0500)] <dmccallum54> irsc is going to need the patch
[16:52:06 CDT(-0500)] <dmccallum54> so let me know when you're done pls
[16:52:13 CDT(-0500)] <js70> k
[16:52:57 CDT(-0500)] <JasonElwood> if IRSC is getting an update, the Counseling Reference Guide report could go in
[16:53:20 CDT(-0500)] <JasonElwood> Jim- was there a fix you added today for that OR a fix that have gone in since 1.1?
[16:53:38 CDT(-0500)] <js70> fix since 1.1 not sure of the history on that one.
[16:54:39 CDT(-0500)] <JasonElwood> Dan- the issue is that deleted referrals are showing in the report. I can delete the referrals from the db but any other deletions after would still show
[16:56:14 CDT(-0500)] <dmccallum54> JasonElwood which report pls?
[16:56:25 CDT(-0500)] <dmccallum54> Counseling Reference Guide?
[16:56:29 CDT(-0500)] <JasonElwood> yeah
[16:56:39 CDT(-0500)] <dmccallum54> is that already fixed upstream?
[16:56:43 CDT(-0500)] <dmccallum54> is this is a new issue?
[16:57:00 CDT(-0500)] <JasonElwood> Jim indicated that is has been fixed already but not sure when
[16:57:12 CDT(-0500)] <dmccallum54> oh ok. i follow now
[16:57:54 CDT(-0500)] <dmccallum54> js70 i think it makes the most sense for you to figure out what that patch looks like for the CRG report and extract it into something we can backport to 1.1
[17:00:40 CDT(-0500)] <js70> yummy
[17:00:51 CDT(-0500)] <dmccallum54> dont get too excited now
[17:04:41 CDT(-0500)] <js70> Going to suggest we just backport the fix for 924 as 923 involves changes to app.js, PersonController.js and PersonHistoryReportConroller.
[17:04:57 CDT(-0500)] <js70> the api will remain fixed until 2.0
[17:51:18 CDT(-0500)] <JasonElwood> So what was decided about the Counseling Report for IRSC?
[17:53:49 CDT(-0500)] <js70> So, I'm looking into the issue right now.
[18:00:08 CDT(-0500)] <js70> the patching is not going to work as significant changes were made that make a simple patch impossible. Looked at the code, we just need to change one line final PagingWrapper<Challenge> challengeWrapper = challengeService.getAll(null); to final PagingWrapper<Challenge> challengeWrapper = challengeService.getAll(new SortingAndPaging(ObjectStatus.Active));
[18:00:32 CDT(-0500)] <dmccallum54> js70 if that fixes the problem, that seems just fine to me
[18:00:43 CDT(-0500)] <js70> Dan, would it be possible to make this change in the 1.1.1 branch, create a patch and go from there.
[18:00:51 CDT(-0500)] <js70> that will fix it.
[18:01:21 CDT(-0500)] <js70> k
[18:01:23 CDT(-0500)] <dmccallum54> i think i'm probably not understanding what you're saying
[18:01:31 CDT(-0500)] <dmccallum54> here's what i think you're saying
[18:01:55 CDT(-0500)] <dmccallum54> a cherry pick from upstream into 1.1 isn't going to work b/c the upstream patches assume a whole bunch of other changes that aren't relevant
[18:02:07 CDT(-0500)] <js70> yes
[18:02:15 CDT(-0500)] <dmccallum54> but you can accomplish the same goal in a completely different way for 1.1 with a one line patch
[18:02:22 CDT(-0500)] <dmccallum54> if that's what you're saying, then great, go for it!
[18:02:39 CDT(-0500)] <js70> ok. kool.
[18:35:14 CDT(-0500)] <js70> SSP-924 and the CounselingReport are now up to date on 1.1 and 1.2
[18:35:38 CDT(-0500)] <JasonElwood> Thanks Jim
[18:35:46 CDT(-0500)] <js70> NP
[18:44:40 CDT(-0500)] <JasonElwood> dan- would you agree that MAP print/email could occur after feature set 1 and 2?
[18:45:16 CDT(-0500)] <dmccallum54> seems like one of the two should definitely be postponable
[18:45:37 CDT(-0500)] <dmccallum54> as to whether both can be postponed… i think it has to do with what's in the export exactly
[18:46:15 CDT(-0500)] <JasonElwood> and there are two options. one that's full description, the other like a grid of terms and courses
[18:46:30 CDT(-0500)] <dmccallum54> given the concern over the External Data Apocalypse i've been assuming that "exportability" of a minimally viable plan representation is a very high priority indeed
[18:47:16 CDT(-0500)] <dmccallum54> if that's a realistic take on things, then it seems like we absolutely need some sort of lightweight export feature in "phase 1"
[18:47:38 CDT(-0500)] <dmccallum54> i.e. an export that works even if you lose all the external data that a plan refers to
[18:48:14 CDT(-0500)] <dmccallum54> that's why the "Core Planning" feature set operational model specifies that certain fields be copied from the external course record into the operational model
[18:48:43 CDT(-0500)] <dmccallum54> w/r/t the actualy delivery format…. an email is actually going to be simplest for us, i think
[18:48:53 CDT(-0500)] <dmccallum54> given the painfulness of building jasper reports
[18:49:39 CDT(-0500)] <JasonElwood> both report examples have student and contact notes on the reports. the rest is pretty much basic information. do we want to build a report for feature set 1 then go back into the reports to add notes OR do it all at once?
[18:51:13 CDT(-0500)] <dmccallum54> imho notes are fluff and should be added later
[18:51:25 CDT(-0500)] <dmccallum54> and i mean fluff in the most respectful sense
[18:51:26 CDT(-0500)] <dmccallum54> of course
[18:51:32 CDT(-0500)] <JasonElwood> sure
[18:56:57 CDT(-0500)] <dmccallum54> js70 1-1 patch does not compile 4413140cfd42393301cf8cdf72d7c955bff5b5b1
[19:01:48 CDT(-0500)] <dmccallum54> js70 i need to run. will take another peek tonight and see about pushing to IRSC
[19:02:01 CDT(-0500)] <js70> k