uPortal IRC Logs-2012-02-21
[08:39:50 CST(-0600)] <rlewis> When I put dojo or esri on the native umobile app I get tthe android build error says files starting with underscore are invalid. Anybody run into that and is there a workaround?
[09:42:58 CST(-0600)] <athena> rlewis: i haven't tried dojo or esri in titanium
[09:43:25 CST(-0600)] <athena> we generally use jquery / jquery mobile, and we generally expect that most people will develop new modules on the web side rather than native
[09:43:34 CST(-0600)] <athena> that said, you can certainly pick whatever toolkit you like
[09:43:45 CST(-0600)] <athena> i think i do remember hearing about some problem with underscores in titanium, though
[09:43:52 CST(-0600)] <athena> maybe send a note to the umobile-user list?
[09:48:04 CST(-0600)] <rlewis> Okay, Thanks!
[11:05:20 CST(-0600)] <b-sure> hello uPortal devs: has anyone had a chance to look at this issue with 4.0.3 categories and groups UP-3345 ?
[11:05:44 CST(-0600)] <EricDalquist> not yet b-sure, sorry
[11:05:47 CST(-0600)] <b-sure> I'd have some time to try to track down the source of the issue but it is spring-security and I'm not sure if maybe it is configuration related
[11:05:51 CST(-0600)] <b-sure> np
[11:06:08 CST(-0600)] <EricDalquist> my off the cuff guess is that a ThreadLocal isn't getting set for some reason
[11:06:12 CST(-0600)] <b-sure> do you have a hunch that maybe its in the code
[11:06:13 CST(-0600)] <b-sure> ?
[11:06:18 CST(-0600)] <b-sure> ok
[11:06:40 CST(-0600)] <EricDalquist> that or MVCDispatcherServlet isn't correctly under the spring-security web.xml filter umbrella
[11:07:32 CST(-0600)] <b-sure> ok yeah. and I';m not well versed at all in the modern spring configs and think I may be spinning my wheels for something that would take you or athena maybe a short time to fix
[11:09:06 CST(-0600)] <b-sure> I do have time to try importing data into the 4.0.3 patch that awills comitted the other day. I'll give that a go and see if it comes into 4.0.3 cleanly.
[11:09:34 CST(-0600)] <b-sure> do you have a time for cutting the <folder> elements out of the .layout files like w/ a bash or some other script?
[11:10:22 CST(-0600)] <athena> b-sure: i actually wasn't able to duplicate it with my install
[11:10:24 CST(-0600)] <b-sure> rather do you have a tip for cutting up a large amount of .layout files so that they be imported as an upgrade to 4.0.3
[11:10:25 CST(-0600)] <athena> are you seeing it in the quickstart?
[11:10:55 CST(-0600)] <b-sure> hi athena. I didn't try with the quick start, but It does affect the group manager as well.
[11:11:11 CST(-0600)] <b-sure> I'm doing an overlay on the maven artifact for 4.0.3
[11:11:38 CST(-0600)] <athena> if you could reproduce it with the quick start that would help, though i'll try again just in case i missed something
[11:11:43 CST(-0600)] <athena> seemed to be working ok though
[11:11:47 CST(-0600)] <b-sure> I think we just have pags tester customizations and configurations
[11:12:27 CST(-0600)] <b-sure> ok. I'll try to reproduce with the quick start. Should I try that against the embedded db or should I point it to our real dev environment?
[11:13:01 CST(-0600)] <athena> embedded
[11:13:17 CST(-0600)] <athena> if we can't reproduce it in the quickstart we'll know it's something data-specific
[11:13:40 CST(-0600)] <b-sure> ok
[11:51:40 CST(-0600)] <athena> EricDalquist: i've narrowed down the guest layout issue i'm having
[11:52:09 CST(-0600)] <athena> something changed between 4.0.2 and 4.0.3 such that when the mobile profile is created, it's pointed to the "0" layout instead of "1", like it should be
[11:52:19 CST(-0600)] <athena> not sure yet what change caused it
[11:53:03 CST(-0600)] <EricDalquist> hrm
[11:54:04 CST(-0600)] <EricDalquist> I'd have to take a look at the profile import code and see how it works?
[11:54:31 CST(-0600)] <athena> yeah, i'm going to take a look at the diff between versions first
[11:54:59 CST(-0600)] <EricDalquist> my only thought would be that I changed the sequence gen code a little bit
[11:55:05 CST(-0600)] <EricDalquist> and it may start at 0 now instead of 1
[11:55:10 CST(-0600)] <EricDalquist> but that is more of a random guess
[11:55:21 CST(-0600)] <EricDalquist> I'd still look at the import code first
[11:55:25 CST(-0600)] <athena> yeah
[11:55:28 CST(-0600)] <athena> i think that's more likely
[11:55:29 CST(-0600)] <EricDalquist> and see how that layoutid gets resolved
[11:56:10 CST(-0600)] <athena> probably more specifically the DLM code
[11:56:20 CST(-0600)] <athena> happening the first time the user logs in, rather than during import
[12:15:02 CST(-0600)] <athena> so i found a line that seems like a problem
[12:15:10 CST(-0600)] <athena> though honestly it mostly makes me wonder how this ever actually worked
[12:15:20 CST(-0600)] <EricDalquist> lol
[12:15:37 CST(-0600)] <athena> there's a section that goes and copies the template user profile into a new profile
[12:15:42 CST(-0600)] <athena> and sets the layout id to zero
[12:16:33 CST(-0600)] <athena> actually
[12:16:43 CST(-0600)] <athena> should we even be creating profiles/layouts for users when they log in?
[12:16:58 CST(-0600)] <EricDalquist> uhg, I'm not sure
[12:17:01 CST(-0600)] <athena> shoudln't they just get the default until they actually make changes?
[12:17:01 CST(-0600)] <EricDalquist> in theory I don't think so
[12:17:04 CST(-0600)] <EricDalquist> right
[12:17:06 CST(-0600)] <athena> yeah :/
[12:17:16 CST(-0600)] <athena> so guess really part of the problem is that
[12:17:17 CST(-0600)] <athena> ugh.
[12:20:04 CST(-0600)] <EricDalquist> yeah
[12:23:22 CST(-0600)] <athena> starting to wonder if this is related to the locale changes arvids made
[12:23:31 CST(-0600)] <athena> not suggesting he actually broke anything
[12:23:42 CST(-0600)] <EricDalquist> hey then it wouldn't be my fault!
[12:23:44 CST(-0600)] <athena> but maybe the call stack changed slightly such that we're callign broken code that we werent' before
[12:23:45 CST(-0600)] <athena> lol
[12:24:05 CST(-0600)] <athena> i don't think it's anyone's fault think it's the fault of a horrible, half-broken, confusing section of code
[12:24:11 CST(-0600)] <EricDalquist>
[12:26:04 CST(-0600)] <athena> so i think we have two problems:
[12:26:16 CST(-0600)] <athena> 1. probably shouldn't be creating these profiles in the first place, though i'm not sure
[12:26:34 CST(-0600)] <athena> 2. need to be linking it to the right layout when it is created
[12:29:21 CST(-0600)] <athena> mystified by what changed to cause the second issue
[12:59:56 CST(-0600)] <athena> hmm, well, EricDalquist, i think i foudn a fix
[13:00:03 CST(-0600)] <athena> i have absolutely no idea why this issue cropped up still
[13:00:24 CST(-0600)] <athena> but there's a SQL query in RDBMUserLayoutStore.getLayoutID that's clearly just wrong
[13:00:34 CST(-0600)] <EricDalquist> heh
[13:00:53 CST(-0600)] <athena> doing a join on the default layout id instead of hte default user id
[13:01:09 CST(-0600)] <athena> so it never finds the default layout and defaults to zero
[13:01:11 CST(-0600)] <EricDalquist> :/
[13:01:28 CST(-0600)] <athena> not sure why we're only seeing this recently
[13:01:35 CST(-0600)] <athena> but guess somehow the call stack must have changed
[13:01:48 CST(-0600)] <EricDalquist> maybe the right layoutId used be 0?
[13:01:51 CST(-0600)] <athena> nope
[13:02:09 CST(-0600)] <athena> confirmed that it was being correclty set to 1 as of 4.0.2
[13:02:18 CST(-0600)] <EricDalquist> weird ...
[13:02:25 CST(-0600)] <athena> updated this SQL query and the portlet is accessible again
[13:02:25 CST(-0600)] <athena> yeah
[13:02:37 CST(-0600)] <athena> guess i'll check this in and we can watch for any side effects?
[13:02:43 CST(-0600)] <EricDalquist> yeah
[13:02:46 CST(-0600)] <athena> k