jasig-ssp IRC Logs-2013-07-23

[12:40:36 CDT(-0500)] <JasonElwood> Did we ever have a conversation about making Notes available to the faculty role?

[12:41:02 CDT(-0500)] <dmccallum54> I dont recall that discussion specifically. but it's easy enough to make such a change

[13:05:25 CDT(-0500)] <JasonElwood> Sorry- took advantage of the "it's easy to do" comment

[13:13:27 CDT(-0500)] <dmccallum54> so i see

[13:13:53 CDT(-0500)] <JasonElwood> just inconsistencies to fix, sorry

[13:14:19 CDT(-0500)] <JasonElwood> You may be due another gift card

[13:14:55 CDT(-0500)] <dmccallum54> i am short on shoelaces...

[13:31:08 CDT(-0500)] <JasonElwood> Paul- You were developing a permissions spreadsheet. Where in the wiki is that?

[13:32:28 CDT(-0500)] <pspaude1> https://wiki.jasig.org/display/SSP/SSP+v2.0.X+Permission+Descriptions

[13:33:15 CDT(-0500)] <pspaude1> Tried to keep on top of changes, but the additions I didn't see in the SSP-Platform as of I think 2-3 days ago, but I could have missed them.

[13:33:46 CDT(-0500)] <JasonElwood> any reason to not make that public?

[13:35:03 CDT(-0500)] <pspaude1> That's above my paygrade. you'll have to ask Patty. But, I don't see why not IMHO.

[13:47:09 CDT(-0500)] <pspaude1> Tony, Thanks for your offer of help earlier! I figured out a solution. Just thought I'd let you know so you aren't budgeting some time for helping me.

[13:56:29 CDT(-0500)] <TonyUnicon> cool, thanks

[14:00:30 CDT(-0500)] <TonyUnicon> so the issue with the paging/sorting

[14:00:36 CDT(-0500)] <TonyUnicon> is with the request url that is being build

[14:00:59 CDT(-0500)] <TonyUnicon> i/1/reference/challenge?_dc=1374604958591&page=1&start=0&limit=20&sort=%5B%7B%22property%22%3A%22name%22%2C%22direction%22%3A%22ASC%22%7D%5D

[14:01:28 CDT(-0500)] <TonyUnicon> on the serverside

[14:01:32 CDT(-0500)] <JasonElwood> good catch

[14:01:53 CDT(-0500)]

<TonyUnicon> the sort request param gets unmarshalled as

Unknown macro: {"property"}

[14:02:06 CDT(-0500)] <TonyUnicon> which is not what the API intended

[14:02:29 CDT(-0500)] <TonyUnicon> so my question is for Dan, ive spent some time on this now, but I don't know how this urls get build from the paging info

[14:02:33 CDT(-0500)] <TonyUnicon> and whether or not that has changed

[14:02:38 CDT(-0500)] <TonyUnicon> recently, or this never worked

[14:03:25 CDT(-0500)] <JasonElwood> maybe never worked because sort was just implemented

[14:03:37 CDT(-0500)] <TonyUnicon> was it?

[14:04:01 CDT(-0500)] <JasonElwood> yep. Archna completed a bunch of tickets to add sort across the board

[14:04:07 CDT(-0500)] <TonyUnicon> ahh

[14:04:13 CDT(-0500)] <TonyUnicon> do you have the ticket for that

[14:04:59 CDT(-0500)] <JasonElwood> one sec

[14:05:16 CDT(-0500)] <TonyUnicon> ill see what she did

[14:05:34 CDT(-0500)] <dmccallum54> tyler's fix is here: https://github.com/Jasig/SSP/commit/057e1c0105b401ec648694cada21d2a1d662a543

[14:05:49 CDT(-0500)] <JasonElwood> SSP-1179

[14:06:07 CDT(-0500)] <TonyUnicon> i dont see how this addresses this particular issue

[14:06:09 CDT(-0500)] <dmccallum54> in which he checks in the client-side sort state and transforms that into server-side params for the next store.load()

[14:06:53 CDT(-0500)] <dmccallum54> i'm not sure if it's possible to hook into the pagination nav event to do something similar. or if there's just something simpler that can be done in the store config itself

[14:06:56 CDT(-0500)] <dmccallum54> still checking

[14:07:43 CDT(-0500)] <TonyUnicon> the problem here is that the url is not built correctly

[14:07:50 CDT(-0500)] <TonyUnicon> not any sort of client/server field translation

[14:07:50 CDT(-0500)] <dmccallum54> i know

[14:08:31 CDT(-0500)] <dmccallum54> it was exactly the same url building symptom in 1164

[14:11:26 CDT(-0500)] <TonyUnicon> its not the same, that issue was that he needed to translate 'active' to objectStatus

[14:12:40 CDT(-0500)] <TonyUnicon> but you're saying that's extjs's paging toolbar that is appending the request params?

[14:12:59 CDT(-0500)] <dmccallum54> look further down in that same commit. in AbstractReferenceAdmin.js

[14:13:19 CDT(-0500)] <dmccallum54> where he's manipulating the sort and sortDirection params

[14:14:45 CDT(-0500)] <dmccallum54> um. end of the day i think it's probably the Ext.data.proxy.Ajax and its sortParam

[14:15:15 CDT(-0500)] <dmccallum54> i'm not sure at which point, exactly, though the url is being built

[14:18:42 CDT(-0500)] <dmccallum54> looks like the behavior we're seeing is coming from Ext.data.proxy.Server#encodeSorters()…

[14:18:53 CDT(-0500)] <dmccallum54> which encodes the sorters as JSON

[14:19:23 CDT(-0500)] <dmccallum54> looks like there's a simpleSortMode config that can be set which might send the sort column and direction as separate, non-JSON query params

[14:21:16 CDT(-0500)] <dmccallum54> only other option i'm seeing would be to do all the sorting and paging client side.

[14:21:53 CDT(-0500)] <dmccallum54> not sure which would be more invasive, though, switching everything to client side sort/page or configing store proxies with simpleSortMode (if that even works)

[14:22:21 CDT(-0500)] <dmccallum54> for the latter, i wonder if there's a way to do that globally at app launch

[14:22:33 CDT(-0500)] <dmccallum54> but anyway

[14:22:48 CDT(-0500)] <dmccallum54> i'm stopping on this now. let me know if it still makes no sense

[14:24:14 CDT(-0500)] <TonyUnicon> it does

[14:48:38 CDT(-0500)] <TonyUnicon> annnnnnnd

[14:48:43 CDT(-0500)] <TonyUnicon> that seems to have fixed it

[14:48:58 CDT(-0500)] <TonyUnicon> the config that is

[14:49:17 CDT(-0500)] <dmccallum54> sweet

[14:49:17 CDT(-0500)] <TonyUnicon> again, i want to be Dan when I grow up (smile)

[14:49:25 CDT(-0500)] <dmccallum54> no you dont

[14:49:33 CDT(-0500)] <js70> never grow up

[14:49:38 CDT(-0500)] <TonyUnicon> id probably be able to fix a few bugs on me own

[14:50:03 CDT(-0500)] <dmccallum54> paspaude1, TonyUnicon can you please fight over SSP-1527

[14:50:21 CDT(-0500)] <dmccallum54> would have just given it to tony but not sure how much more you've already got to deal with

[14:50:41 CDT(-0500)] <TonyUnicon> i'll take it

[14:50:44 CDT(-0500)] <dmccallum54> thx

[14:50:46 CDT(-0500)] <TonyUnicon> you just bought me a few hours

[15:18:03 CDT(-0500)] <pspaude1> Any ideas as to the cause of SSP-717 appointment required even for non-required student types on edit? It seems this issue came back. Except its different.

[15:18:35 CDT(-0500)] <pspaude1> It only does it on the first edit student after login on a clean browser. After that it works normally.

[15:18:37 CDT(-0500)] <JasonElwood> That's pretty funny. I noticed it earlier but couldn't re-produce it

[15:18:40 CDT(-0500)] <dmccallum54> an excess of awesome, probably

[15:19:31 CDT(-0500)] <pspaude1> I wish it was an excess of awesome! Thought it was my code fix for SSP1492, but the CI's do it too.

[15:20:06 CDT(-0500)] <pspaude1> What has changed in 13 days (smile)

[15:46:18 CDT(-0500)] <pspaude1> Created new issue SSP-1528 since it was a bit different. It's also flagging coaches all the time irregardless, but it doesn't prohibit you from saving like appiontment required does.

[18:19:28 CDT(-0500)] <pspaude1> Dan, is it reasonable to fire a studentTypeCombo change event when the studentTypesStore finishes loading in one controller to eliminate using a null store in another?

[18:19:31 CDT(-0500)] <pspaude1> Trying to avoid loading store in two different controllers and the two server requests that result, when 99% of the time there is no need.

[18:22:30 CDT(-0500)] <dmccallum54> um

[18:22:53 CDT(-0500)] <dmccallum54> it doesnt sound unreasonable on the face of it. as long as the receiving controller actually exists and has registered its listener when that event fires

[18:23:33 CDT(-0500)] <dmccallum54> it's actually a "combo" change event that fires? that's kinda weird to indicate that a store has loaded hasnt it?

[18:23:37 CDT(-0500)] <dmccallum54> isn't it, rather

[18:24:42 CDT(-0500)] <pspaude1> Yes, just trying to work with what I have. AppointmnetViewController is listening for that from CoachViewController to know when to set asterisks and the highlighting to indicate an appointment is required.

[18:25:15 CDT(-0500)] <pspaude1> What is happening is AppointmentViewController relies on StudentTypesStore but doesn't load it. CoachViewController does. 99% of the time this works ok.

[18:26:00 CDT(-0500)] <pspaude1> However, as indicated in issue SSP-1528, it fails and its kind of bad if you have the student type box as set from external data and its greyed out.

[18:28:16 CDT(-0500)] <pspaude1> Of course it works if you load the store in AppointmentViewController as well and tell the logic to wait much like my fix for SSP-1492, however it results in two server calls.

[18:28:43 CDT(-0500)] <pspaude1> Another way is, I'm unsure if its appropriate to load StudentTypesStore in CaseloadAssignViewController?

[18:29:52 CDT(-0500)] <dmccallum54> jjust a sec. looking at the code

[18:30:08 CDT(-0500)] <pspaude1> No problem, sorry to blindside you!

[18:30:14 CDT(-0500)] <dmccallum54> np

[18:33:50 CDT(-0500)] <dmccallum54> the thing that worries me about the event is that while it makes sense it still might not solve the timing problem b/c i dont know that we really know that the appt controller will init before the coach view controller

[18:36:46 CDT(-0500)] <pspaude1> Right and that was my worry after you posted that.

[18:39:04 CDT(-0500)] <dmccallum54> i think we'd either need to load the store in the top-level controller (which does happen it at least one other case, i think) or have the top-level controller listen for the load event on the store, write down when those occur, give the child controllers references to the top-level controller so they can ask it if the event has already fired.

[18:39:13 CDT(-0500)] <dmccallum54> that second one sounds like a disaster

[18:40:30 CDT(-0500)] <dmccallum54> CampusAdminViewController is the other case i was thinking of where reference data is loaded up in the top level controller, even if you wont need it

[18:40:42 CDT(-0500)] <dmccallum54> but in this case i think the sin isn't quite as dire since we do know we'll need it

[18:41:25 CDT(-0500)] <pspaude1> The second one + me = disaster. But its pretty cool, you could write a patterns book and call that hot potato (smile)

[18:41:26 CDT(-0500)] <dmccallum54> so i guess i'm voting to try loading the store in the top-level controller

[18:42:57 CDT(-0500)] <pspaude1> Yes it makes sense and that is what I was thinking (loading in top controller). Thanks for the example that will help. And yes it will always be used and it blocks major functionality (save) that is in the top-level controller.

[18:43:11 CDT(-0500)] <dmccallum54> sounds good. thx.

[18:43:15 CDT(-0500)] <pspaude1> *thinking = voting for

[19:03:47 CDT(-0500)] <pspaude1> Cool looks like it works! One more quick question. If its in the higher-level controller's init method I don't have to worry about the timing correct? CampusAdminController doesn't either, but just making sure their aren't any weird time issues where the store isn't loaded yet.

[19:03:58 CDT(-0500)] <dmccallum54> well

[19:04:27 CDT(-0500)] <pspaude1> It seems from logging that it is ok, much more so than the other ways. But, I don't like the well (smile)

[19:04:30 CDT(-0500)] <dmccallum54> i dont think you do b/c the top level controller is actually building the specs for the child views and adding them to the top level view

[19:05:14 CDT(-0500)] <dmccallum54> if load() itself is async, though, and you need to be asbolutely sure it's completed, i think you can register a callback (as you've done earlier today?)

[19:05:33 CDT(-0500)] <dmccallum54> although, you've probably gathered that there's a whole bunch of sweeping-under-the-rug of timing issues in this app

[19:05:56 CDT(-0500)] <pspaude1> Yes that is what I thought from looking at the code that it will be ok, but its late and my mind is tired.

[19:06:13 CDT(-0500)] <pspaude1> Yes I 've also seen alot of sweeping under the rug!

[19:07:08 CDT(-0500)] <pspaude1> No it doesn't need 100%, if it fails chances are some of the other stores failed as well and they'll back out and come back or call up IT due to server issues (smile)

[19:07:49 CDT(-0500)] <pspaude1> Or pick another student and try or try again, and in all those cases (except for server issues) the app will perform correctly. So, I think we are ok.

[19:09:05 CDT(-0500)] <pspaude1> Thanks for your help!