[09:53:06 CDT(-0500)] <EricDalquist> After what feels like try 300 I think I have the portlet caching logic flows fully diagramed: https://wiki.jasig.org/display/UPC/JSR-286+Caching+Use+Cases
[10:21:43 CDT(-0500)] <b-sure> hello uPortal devs: do you know if there is a way to turn down the number of threads during export for 3.2.5 like you can do in the 4.x builds? I"m running into a (Too many open files) issue exporting profiles. everything else exports without error.
[10:22:07 CDT(-0500)] <EricDalquist> export.properties
[10:22:18 CDT(-0500)] <b-sure> ahh. I was looking in portal.properties
[10:22:22 CDT(-0500)] <b-sure> thanks EricDalquist
[10:22:23 CDT(-0500)] <EricDalquist> also … unless you're dealing with mobile and desktop profiles in 3.2
[10:22:28 CDT(-0500)] <EricDalquist> just export layouts
[10:22:33 CDT(-0500)] <EricDalquist> don't bother with users or profiles
[10:22:39 CDT(-0500)] <b-sure> yeah. I only plan to import the users and layouts
[10:22:45 CDT(-0500)] <b-sure> oh ok. I'll skip users
[10:22:56 CDT(-0500)] <EricDalquist> and then in 4.0.5 (when it comes out in a day or so) you can set a flag so that during layout import users are just created
[10:23:16 CDT(-0500)] <EricDalquist> and users that had no layout or portlet preference data in your 3.2 install will just get created on first login
[10:23:22 CDT(-0500)] <b-sure> ok. thanks for the tip. I'm quite excited about the 4.0.5 build.
[10:23:35 CDT(-0500)] <b-sure> that sounds great.
[10:24:17 CDT(-0500)] <EricDalquist> me too
[10:24:24 CDT(-0500)] <EricDalquist> this portlet caching logic is driving me nuts
[10:53:01 CDT(-0500)] <EricDalquist> when uportal is replaying cached content, should properties the portlet set be replayed as well?
[10:53:07 CDT(-0500)] <EricDalquist> that isn't addressed at all in the spec
[11:25:54 CDT(-0500)] <athena> EricDalquist: when are you planning to cut 4.0.5? just noticed the fragment admin header thing seems to be missing
[11:31:29 CDT(-0500)] <EricDalquist> probably not until tomorrow morning
[11:31:38 CDT(-0500)] <EricDalquist> this portlet caching bug I'm tracking down is a royal pain
[11:31:41 CDT(-0500)] <athena> gotcha
[11:31:44 CDT(-0500)] <EricDalquist> so if you have other fixes please go ahead and get them in
[11:32:03 CDT(-0500)] <athena> will do my best
[11:32:17 CDT(-0500)] <athena> may not have dev time until tomorrow - i owe a conference a slide deck :/
[11:32:21 CDT(-0500)] <EricDalquist> :/
[11:32:24 CDT(-0500)] <athena> so not used to having to do those so far in advance
[11:32:31 CDT(-0500)] <EricDalquist> yeah
[11:32:33 CDT(-0500)] <athena> conference isn't until may
[11:32:37 CDT(-0500)] <EricDalquist> 
[11:32:49 CDT(-0500)] <athena> i hate doing that stuff - would rather develop 
[11:32:51 CDT(-0500)] <EricDalquist> yeah
[11:32:52 CDT(-0500)] <EricDalquist> me too
[11:33:19 CDT(-0500)] <athena> i am totally going to be writing slides in class tonight
[11:33:47 CDT(-0500)] <EricDalquist> lol
[11:34:01 CDT(-0500)] <athena> sitting still for 3 hours is so hard
[11:34:51 CDT(-0500)] <athena> oh i got the stats stuff mostly working
[11:34:55 CDT(-0500)] <EricDalquist> yay!
[11:35:10 CDT(-0500)] <athena> last bit is getting the ajax working
[11:35:15 CDT(-0500)] <EricDalquist> cool
[11:35:20 CDT(-0500)] <athena> jquery insists on submitting params with a []
[11:35:24 CDT(-0500)] <athena> and spring doesn't like that
[11:35:40 CDT(-0500)] <EricDalquist> oh yeah
[11:35:42 CDT(-0500)] <EricDalquist> I hate that BS
[11:35:48 CDT(-0500)] <EricDalquist> they added that specifically for PHP
[11:35:55 CDT(-0500)] <EricDalquist> I think there is a way to get jQuery to stop that
[11:36:11 CDT(-0500)] <athena> there is
[11:36:23 CDT(-0500)] <athena> but we'd have to go through and change other stuff since we already are using that elsewhere
[11:36:33 CDT(-0500)] <athena> so wasn't sure what we wanted to do
[11:38:03 CDT(-0500)] <EricDalquist> oh its global?
[11:38:51 CDT(-0500)] <athena> yeah
[11:38:59 CDT(-0500)] <EricDalquist>
[11:39:03 CDT(-0500)] <athena> i know
[11:39:20 CDT(-0500)] <athena> let me make sure they haven't added that as an option
[11:41:53 CDT(-0500)] <athena> ooh i think we can make it per-request now!
[11:41:54 CDT(-0500)] <athena> excellent
[11:41:58 CDT(-0500)] <athena> i'll try and get that in today
[11:44:48 CDT(-0500)] <EricDalquist> awesome
[13:24:53 CDT(-0500)] <b-sure> hello again EricDalquist. question. If I build and deploy the current master branch, will that be what is going to be released for 4.0.5 outside of whatever you and the other devs commit today?
[13:25:01 CDT(-0500)] <EricDalquist> yes
[13:25:22 CDT(-0500)] <EricDalquist> the only issues that are pending are some improvements to portlet caching
[13:25:24 CDT(-0500)] <EricDalquist> and stats reporting
[13:25:44 CDT(-0500)] <b-sure> great. I'm gonna run with whats in master then and then rebuild once you cut the release.
[13:26:32 CDT(-0500)] <EricDalquist> sounds good
[13:39:24 CDT(-0500)] <athena> b-sure: how's the shibb stuff going?
[13:39:48 CDT(-0500)] <b-sure> I'm not sure if these will apply to all exporters of 3.2.5, but I had to update the syntax in 2 spots of the RDBMDistributedLayoutStore.java file
[13:39:51 CDT(-0500)] <b-sure> hi athena.
[13:40:18 CDT(-0500)] <b-sure> I just got it working today although I need a working build of the uPortal to confim end to end.
[13:40:23 CDT(-0500)] <athena> awesome
[13:40:38 CDT(-0500)] <athena> are you still planning to switch to ECP integration for umobile?
[13:40:58 CDT(-0500)] <b-sure> yes. that is actually what we've been working on and believe to have working.
[13:41:29 CDT(-0500)] <b-sure> I'm gonna try deploying master this afternoon and verify login end to end in umobile
[13:42:16 CDT(-0500)] <athena> oh that's terrific!
[13:42:17 CDT(-0500)] <b-sure> it is pretty similar to what is there. and I adapted the example script from here http://www.cilogon.org/ecp
[13:42:31 CDT(-0500)] <athena> from what i understand it sounds like ECP is architecturally the right strategy
[13:42:47 CDT(-0500)] <athena> also wondered a bit if that'll be more performant than trying to step through the webflow
[13:42:49 CDT(-0500)] <b-sure> yeah. I was urged by our shibb admin to use ecp
[13:42:56 CDT(-0500)] <athena> yeah
[13:43:07 CDT(-0500)] <EricDalquist> does the ECP approach result in umobile remembering the user's password?
[13:43:09 CDT(-0500)] <athena> i know we talked about it during the educase development and just didn't have enough time to implement
[13:43:18 CDT(-0500)] <EricDalquist> we're trying to figure out how we're going to handle uMobile auth
[13:43:20 CDT(-0500)] <athena> i believe so - is that right b-sure?
[13:43:34 CDT(-0500)] <b-sure> I think the remembering of the password is outside of the shibb code. it happens in the native app
[13:43:35 CDT(-0500)] <athena> EricDalquist: are you guys just not ready to do oauth yet?
[13:43:44 CDT(-0500)] <EricDalquist> we don't know what we're doing
[13:43:47 CDT(-0500)] <athena> lol
[13:43:49 CDT(-0500)] <EricDalquist> oauth has come up
[13:44:02 CDT(-0500)] <athena> b-sure: i think wisc is looking for a way to keep the password off the phone
[13:44:05 CDT(-0500)] <EricDalquist> but it would just sign them into the portal
[13:44:08 CDT(-0500)] <EricDalquist> yeah
[13:44:14 CDT(-0500)] <athena> i dunno
[13:44:26 CDT(-0500)] <athena> i guess it seems comparable to a user letting their browser remember their password
[13:44:31 CDT(-0500)] <b-sure> yeah I know were are having issues with the stored password as well, not sure what is required yet
[13:44:47 CDT(-0500)] <athena> oauth does seem like a good strategy for that in the long term
[13:44:56 CDT(-0500)] <athena> but requires the university actually support oauth
[13:45:20 CDT(-0500)] <athena> b-sure: with ECP, does SSOing into other websites from the native app still work?
[13:45:31 CDT(-0500)] <athena> like if you include an external site that is shibb-protected?
[13:45:53 CDT(-0500)] <b-sure> athena: not sure yet since I haven't had a good working portal to test this.
[13:46:29 CDT(-0500)] <b-sure> I think it will work with SSO though because its just storing a shibb cookie in the end like the web browser
[13:48:25 CDT(-0500)] <b-sure> although the umobile app may need to use the same instance of the appcelerator httpclient to make use of the cookie.
[13:51:46 CDT(-0500)] <athena> if it automatically stores the cookie the app should handle it ok
[13:52:47 CDT(-0500)] <b-sure> hello EricDalquist. I have a local git branch copy of 3.2.5 checked out with some changes. I'd like to keep this branch going forward in case we need to export again. I did need to change 2 spots of the RDBMDistributedLayoutStore.java. Can I send a pull request for just that file after I commit all of my changes?
[13:53:11 CDT(-0500)] <EricDalquist> yes but you should create a "work branch" for that
[13:53:15 CDT(-0500)] <b-sure> I"m not sure how to do that
[13:53:33 CDT(-0500)] <EricDalquist> let me get a little more info here:
[13:53:43 CDT(-0500)] <b-sure> oh so just a branch with the one change in it?
[13:53:50 CDT(-0500)] <EricDalquist> what does "git status" show you?
[13:54:02 CDT(-0500)] <EricDalquist> the first line actually
[13:54:09 CDT(-0500)] <EricDalquist> like for my it says:
[13:54:09 CDT(-0500)] <EricDalquist> # On branch UP-3305
[13:54:30 CDT(-0500)] <b-sure> it shows all my mods for my custom 3.2.5 brach... "On branch uportal-3.2.5-uchicago"
[13:54:37 CDT(-0500)] <EricDalquist> ok
[13:54:48 CDT(-0500)] <EricDalquist> so you have a branch you created for your work
[13:54:55 CDT(-0500)] <b-sure> yes
[13:54:58 CDT(-0500)] <EricDalquist> have you already committed the changes you want to do a pull request for?
[13:55:14 CDT(-0500)] <b-sure> no all the files are still in modified state in the uchicago branch
[13:55:18 CDT(-0500)] <EricDalquist> ok
[13:55:23 CDT(-0500)] <EricDalquist> so what I would do is:
[13:55:49 CDT(-0500)] <EricDalquist> commit the files in the change set that I want to make a pull request for to the uportal-3.2.5-uchicago branch
[13:56:10 CDT(-0500)] <EricDalquist> copy down the "short hash" of the commit id (I think it is 8 characters)
[13:56:26 CDT(-0500)] <EricDalquist> checkout the rel-3-2-patches branch "git checkout rel-3-2-patches"
[13:56:37 CDT(-0500)] <EricDalquist> create/find a Jira issue for the changes you want to pull
[13:56:52 CDT(-0500)] <EricDalquist> create a branch for the pull "git checkout -b UP-XXXX"
[13:57:23 CDT(-0500)] <EricDalquist> cherry-pick the commit(s) you want to pull over to this branch "git cherry-pick shortHashFromEarlierCommit"
[13:57:38 CDT(-0500)] <EricDalquist> push the branch to your personal git repo: "git push origin UP-XXXX"
[13:57:43 CDT(-0500)] <EricDalquist> go on to github and make the pull request
[13:57:47 CDT(-0500)] <EricDalquist> its a little round about
[13:57:55 CDT(-0500)] <b-sure> I think I follow that.
[13:57:57 CDT(-0500)] <EricDalquist> but it ensures that you're doing a pull for just the commits you want to
[14:01:32 CDT(-0500)] <athena> ugh. i ran initportal and it ate all my stats data 
[14:01:35 CDT(-0500)] <athena> totally wasn't thinking
[14:01:39 CDT(-0500)] <EricDalquist>
[14:01:50 CDT(-0500)] <EricDalquist> I have 10GB worth here
[14:01:56 CDT(-0500)] <athena> lol
[14:01:57 CDT(-0500)] <athena> well
[14:01:59 CDT(-0500)] <EricDalquist> well from our 2 weeks of being live on 4.0
[14:02:04 CDT(-0500)] <athena> i'll check this stuff in today and you can test it?
[14:02:16 CDT(-0500)] <EricDalquist> I'll see if I can
[14:02:19 CDT(-0500)] <athena> ok
[14:02:22 CDT(-0500)] <EricDalquist> we don't have aggregation on yet
[14:02:26 CDT(-0500)] <athena> so, last stats question (i hope)
[14:02:27 CDT(-0500)] <athena> ah.
[14:02:28 CDT(-0500)] <EricDalquist> but I can do it in a non-prod env
[14:02:38 CDT(-0500)] <athena> even if you happen to have data in your local db
[14:03:10 CDT(-0500)] <athena> we have an API for retrieving all the group aggregations i assume?
[14:03:51 CDT(-0500)] <EricDalquist> AggregatedGroupLookupDao
[14:03:56 CDT(-0500)] <EricDalquist> looks like it is missing some utility APIs
[14:04:05 CDT(-0500)] <EricDalquist> like listing all of the aggregations
[14:04:07 CDT(-0500)] <athena> lol
[14:04:09 CDT(-0500)] <athena> ok
[14:04:16 CDT(-0500)] <athena> so that's the last piece we'd need, i think
[14:04:23 CDT(-0500)] <EricDalquist> thats what happens when I write it only thinking about putting data in 
[14:04:29 CDT(-0500)] <EricDalquist> should be a very easy fix though
[14:04:39 CDT(-0500)] <athena> cool
[14:14:46 CDT(-0500)] <athena> ok, what do the group mappings look like?
[14:14:53 CDT(-0500)] <athena> is groupName the string name or the id?
[14:15:59 CDT(-0500)] <EricDalquist> ID, GROU_SERVICE, GROUP_NAME
[14:16:15 CDT(-0500)] <EricDalquist> where ID is a synthetic identifier specific to the group mapping table
[14:16:45 CDT(-0500)] <EricDalquist> so like a login event lists all the groups a user is in via the group keys: pags.everyone
[14:17:25 CDT(-0500)] <EricDalquist> during aggregation "pags.everyone" is resolved by the groups API to its actual IEntityGroup
[14:18:12 CDT(-0500)] <EricDalquist> and then a row is found or created for the service "pags" and the name "Everyone"
[14:18:23 CDT(-0500)] <athena> ok
[14:18:28 CDT(-0500)] <EricDalquist> the goal is to de-couple the aggregation data from the actual portal data
[14:18:44 CDT(-0500)] <EricDalquist> so that if someone changes the name of, or deletes, a group
[14:18:51 CDT(-0500)] <EricDalquist> it doesn't break a bunch of already aggregated data
[14:18:53 CDT(-0500)] <athena> makes sense