...
[14:54:16 CDT(-0500)] <JasonElwood> hopefully not dmacdonalds
[15:00:10 CDT(-0500)] <TonyUnicon> ^^
[15:25:38 CDT(-0500)] <JasonElwood> do the APIs still allow for create, save and delete for reference items?
[15:38:39 CDT(-0500)] <dmccallum54> JasonElwood they should yes
[15:40:43 CDT(-0500)] <dmccallum54> not working?
[15:40:55 CDT(-0500)] <JasonElwood> testing now
[15:41:20 CDT(-0500)] <JasonElwood> for some reasonI thought we eliminated some methods. maybe that was for person
[15:42:02 CDT(-0500)] <dmccallum54> i had floated the idea of removing getAll for persons
[15:42:27 CDT(-0500)] <dmccallum54> since if someone actually does that it's a disaster
[15:42:55 CDT(-0500)] <dmccallum54> and way back when we had eliminated write ops for EA Responses
[15:43:03 CDT(-0500)] <dmccallum54> but dont recall eliminating methods for reference types
[15:43:24 CDT(-0500)] <JasonElwood> cool. thanks
[15:52:45 CDT(-0500)] <pspaude> dmac, we may have to think up a solution for Win for buildnumber
[15:54:44 CDT(-0500)] <dmccallum54> what happened
[15:56:54 CDT(-0500)] Wiki Markup <pspaude> Severe BeanWiring ... JsonRenderingPipelineContext \[${buildNumber}\] can't be resolved
[15:58:01 CDT(-0500)] <dmccallum54> so
[15:58:05 CDT(-0500)] <pspaude> It is literally passing $buildNumber into the portal.properties in WEB-INF, I'm stubbed it out with a fake scm revision for now. I'm going to try git as an environment variable again like on my old laptop and see if it works.
[15:58:20 CDT(-0500)] <pspaude> But I don't remember if it did.
[15:58:24 CDT(-0500)] <dmccallum54> that worked just fine on wins ci fairly recently
[15:59:19 CDT(-0500)] <dmccallum54> or, i should say, buildNumber resolved just fine
[16:01:14 CDT(-0500)] <pspaude> ok that gives me hope. Looks like I might have had just git home and no bin on the path.
[16:02:59 CDT(-0500)] <dmccallum54> TonyUnicon, fwiw, for SSP-1649, the answer in the SO thread does look like it fixes the reported issue, but actually just trades it for another
[16:03:11 CDT(-0500)] <dmccallum54> the addCls error goes away
[16:03:20 CDT(-0500)] <TonyUnicon> and what happens?
[16:03:21 CDT(-0500)] <dmccallum54> but the 'update' button in the inline editor does't work anymore
[16:03:36 CDT(-0500)] <TonyUnicon> nice
[16:03:50 CDT(-0500)] <dmccallum54> wondering if it's because i can't do the rowEditingPlugin.initFieldAccessors(columns); step in the SO answer
[16:04:28 CDT(-0500)] <dmccallum54> b/c it looks like maybe we're manually firing the reconfigure event when it's not actually "reconfiguring" and we fire it without the columns arg
[16:04:37 CDT(-0500)] <dmccallum54> but still poking around
[16:05:49 CDT(-0500)] <dmccallum54> here's my debugging patch in all its console.log glory
[16:05:49 CDT(-0500)] <dmccallum54> https://gist.github.com/dmccallum/6371285
[16:09:44 CDT(-0500)] <dmccallum54> yeah, it's definitely a fake reconfigure event being fired by FormRendererUtils#reconfigureGridPanel()
[16:09:58 CDT(-0500)] <dmccallum54> seeing what happens if i just add all the expected args to the event
[16:11:28 CDT(-0500)] <dmccallum54> actually… that might not matter...
[16:12:30 CDT(-0500)] <TonyUnicon> ?
[16:12:31 CDT(-0500)] <dmccallum54> the SO is getting the columns from the actual grid, not the event
[17:26:52 CDT(-0500)] <dmccallum54> alright
[17:27:25 CDT(-0500)] <dmccallum54> if i leave out all the crap around trying to reset the roweditor and just go and remove the color picker from AdminTreeMenus.js the whole problem goes away
[17:28:21 CDT(-0500)] <dmccallum54> so presumably that's where the problem lies
[17:28:42 CDT(-0500)] <dmccallum54> aaaaall the other reference data UIs that i try work just fine
[17:30:37 CDT(-0500)] <dmccallum54> wonder if it's b/c it's got a TriggerField instance configured up as the "editor", rather than a specification (xtype) for a TriggerField
[17:45:15 CDT(-0500)] <dmccallum54> yep. looks like that did it
[17:45:22 CDT(-0500)] <dmccallum54> sheesh
[17:45:33 CDT(-0500)] <dmccallum54> looks like there might still be some other problem with electives tho