[10:42:12 CST(-0600)] <dmccallum54> JasonElwood you're not actually working on SSP-172, right?
[10:42:36 CST(-0600)] <dmccallum54> looks like shawn had marked it in progress.
[10:42:40 CST(-0600)] <dmccallum54> then it was assigned to you
[10:42:48 CST(-0600)] <dmccallum54> i just stopped progress and assigned it to myself
[10:43:31 CST(-0600)] <JasonElwood> that's correct. I moved all issues assigned to parties no longer involved to me
[13:55:01 CST(-0600)] <dmccallum54> anyone care to argue that SSP-655 is a bug, not a feature-add?
[13:56:27 CST(-0600)] <dmccallum54> (i went ahead and changed it to a feature add)
[13:57:05 CST(-0600)] <JasonElwood> feature add is fine.
[13:57:38 CST(-0600)] <JasonElwood> there is a relate issue for the department value on the EA submission.
[13:59:33 CST(-0600)] <JasonElwood> SSP-309 calls for the office, phone and department to be populated when creating an EA
[14:02:20 CST(-0600)] <dmccallum54> looks like the backend model supports those fields
[14:02:40 CST(-0600)] <JasonElwood> Those are both carry over problems from the CF version. The CF version has all that data in the user security tables.
[14:02:55 CST(-0600)] <dmccallum54> ah
[14:03:11 CST(-0600)] <dmccallum54> hence the idea that we'd get that stuff from uPortal
[14:03:14 CST(-0600)] <JasonElwood> problems weren't in the CF version but the port wasn't 1 to 1. Since we switched to uPortal
[14:03:47 CST(-0600)] <dmccallum54> so i'm thinking it'd just be some rote work to surface those values from the backend model into the view
[14:03:57 CST(-0600)] <dmccallum54> or am i missing a subtlety?
[14:04:17 CST(-0600)] <JasonElwood> from the external data tables?
[14:05:03 CST(-0600)] <dmccallum54> the ExternalPerson model has…. departmentName, officeLocation and at least two phone fields
[14:05:50 CST(-0600)] <dmccallum54> all of those are copied into the local Person model in one form or another
[14:06:16 CST(-0600)] <dmccallum54> so basically yeah… this information comes from external data tables
[14:06:21 CST(-0600)] <dmccallum54> or a local override thereof
[14:06:38 CST(-0600)] <dmccallum54> that not how you need it to work?
[14:07:06 CST(-0600)] <JasonElwood> that would work fine
[14:07:09 CST(-0600)] <dmccallum54> ok
[14:07:18 CST(-0600)] <dmccallum54> is this a must-have for 1.2?
[14:07:36 CST(-0600)] <dmccallum54> if so i'll estimate and add to next iteration. else just estimate
[14:07:58 CST(-0600)] <JasonElwood> are you asking about 309 or 655 or both?
[14:08:04 CST(-0600)] <dmccallum54> 309 right now
[14:08:16 CST(-0600)] <JasonElwood> its not a blocker
[14:09:00 CST(-0600)] <dmccallum54> original estimate… 6m. nice.
[14:10:46 CST(-0600)] <JasonElwood> that may have been to remove the fields from display
[14:10:57 CST(-0600)] <dmccallum54> for 655… that thing talks about needing new models or changes to models to represent departments...
[14:11:19 CST(-0600)] <dmccallum54> which i guess makes sense if the core idea here is that people have mulitple depts but we want to report on a "home" dept
[14:11:33 CST(-0600)] <dmccallum54> but we do have a departmentName field on ExternalPerson
[14:11:59 CST(-0600)] <JasonElwood> right
[14:12:19 CST(-0600)] <JasonElwood> the last option in the description should work for us
[14:12:39 CST(-0600)] <JasonElwood> and solve the backend problem for both
[14:13:29 CST(-0600)] <dmccallum54> js70 do we really need a new service for SSP-655? if a departmentName field is already present on a Person-associated entity? (person.staffDetails.departmentName)
[14:14:00 CST(-0600)] <dmccallum54> or is it just Yet Even More Joins and/or Projections?
[14:14:32 CST(-0600)] <dmccallum54> …of course where i'm really headed is… is 3d still the right estimate? sounds like it could be a lot less
[14:24:49 CST(-0600)] <dmccallum54> JasonElwood SSP-564 … any reason why a EA Routing should not always be associated with a Person
[14:25:30 CST(-0600)] <js70> The problem is not the search is getting a list of Home Departments
[14:25:53 CST(-0600)] <dmccallum54> populating the filter?
[14:26:24 CST(-0600)] <js70> Exactly. Did not know if we were going to populate from the column or if there was to be a seperate table with more info.
[14:26:29 CST(-0600)] <dmccallum54> gotcha
[14:26:50 CST(-0600)] <dmccallum54> JasonElwood is the idea that Department will become a 1st class reference data type?
[14:27:16 CST(-0600)] <JasonElwood> not to date
[14:27:54 CST(-0600)] <JasonElwood> The external data was expanded to cover the hole from not porting the CF user tables
[14:28:22 CST(-0600)] <dmccallum54> so it would be valid to populate the filter with the equivalent of 'select distinct department_name from person_staff_details'?
[14:29:03 CST(-0600)] <JasonElwood> Regarding SSP-564, there is an option in the CF version in advanced routing to not declare a person. It would go to a generic account. The application currently requires a person, and it would be best to stick with it for now.
[14:29:20 CST(-0600)] <dmccallum54> stick with requiring a person?
[14:29:52 CST(-0600)] <JasonElwood> the select distinct you mention is the best we have now. If the result isn't distinct or accurate enough, the external data can be changed
[14:30:02 CST(-0600)] <JasonElwood> yes, stick with requiring a person. Do you agree?
[14:30:22 CST(-0600)] <dmccallum54> js70 whenever you have time then can you re-eval the estimate on SSP-655 based on this discussion?
[14:30:45 CST(-0600)] <dmccallum54> JasonElwood i'm inclined to make SSP-564 a blocker… the UX makes it appear as if data is being lost
[14:32:14 CST(-0600)] <js70> Sure. I will do that.
[14:33:14 CST(-0600)] <dmccallum54> thx
[14:37:27 CST(-0600)] <js70> changed it to 2d which may seem like a bunch but I could not put in 1.5. The task is pretty easy but I need to go through all the controllers and make sure they are properly implemented, add some data for testing. Its conservative but not that far off.
[14:38:51 CST(-0600)] <dmccallum54> js70 no objection to 2d. fwiw, if you want 1.5d use '1d 4h'
[14:39:03 CST(-0600)] <js70> perfect.
[14:41:55 CST(-0600)] <JasonElwood> 564 could be a blocker
[14:43:13 CST(-0600)] <dmccallum54> k. marked it as such
[14:46:51 CST(-0600)] <JasonElwood> Dan- worst case for 564, an entry can be added to the external_person table, correct?