Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

[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
 &lt;js70&gt; 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