uPortal IRC Logs-2009-05-06

[03:16:33 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:49:14 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[08:54:10 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[09:11:28 EDT(-0400)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:21:18 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[09:26:16 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[09:28:48 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:36:39 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[09:53:40 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:15:18 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[10:16:25 EDT(-0400)] <dstn> When using the "Use it Now" what windowState does that put the portlet in? It appears to be maximized but renderRequest.windowState does not equal maximized...
[10:16:41 EDT(-0400)] <EricDalquist> it should be maximized
[10:16:53 EDT(-0400)] <EricDalquist> but that event may not be getting sent to the portlet correctly
[10:17:48 EDT(-0400)] <dstn> ok, I'll file a jira so its not lost
[10:19:43 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[10:21:57 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[10:22:31 EDT(-0400)] <athena> do you think it's a problem w/ the URL generated by the AJAX?
[10:23:03 EDT(-0400)] <EricDalquist> it could be
[10:23:22 EDT(-0400)] <EricDalquist> it may not be setting the correct parameters to trigger the maximized event
[10:23:30 EDT(-0400)] <athena> yeah, that's kind of what i was thinking
[10:23:37 EDT(-0400)] <athena> i can take a quick look at if if you want
[10:24:14 EDT(-0400)] <athena> i can at least see if anything's different between the icon links and the one in the ajax dialog
[10:24:34 EDT(-0400)] <EricDalquist> oh, I actually have a start on the url work
[10:24:59 EDT(-0400)] <athena> oh cool!
[10:25:01 EDT(-0400)] <EricDalquist> I'll probably be looking for some insight later today to make sure I'm not forgetting things in the API design
[10:25:11 EDT(-0400)] <athena> that's great
[10:25:30 EDT(-0400)] <EricDalquist> like does the theme XSL ever need to be able to change the general window state
[10:25:41 EDT(-0400)] <EricDalquist> I'm thinking it needs to be able to request switching back to 'normal'
[10:26:06 EDT(-0400)] <EricDalquist> but any other state would require targeting a channel, and channel urls will have complete WindowState support
[10:26:52 EDT(-0400)] <athena> ah
[10:27:23 EDT(-0400)] <EricDalquist> so the idea right is different URL object types
[10:27:59 EDT(-0400)] <EricDalquist> like a PortalLayoutUrl would have portal parameters and the ability to reset the window state to normal
[10:28:22 EDT(-0400)] <athena> sounds good
[10:28:32 EDT(-0400)] <athena> i just looked at the thing dstn reported
[10:28:42 EDT(-0400)] <athena> looks like the ajax url actually contains more info, not less
[10:28:57 EDT(-0400)] <EricDalquist> you know
[10:28:58 EDT(-0400)] <athena> the icons link to render.userLayoutRootNode.uP?uP_root=u13l1n11 or the like
[10:29:04 EDT(-0400)] <EricDalquist> this could be a bug I recently fixed locally
[10:29:20 EDT(-0400)] <athena> the ajax "use it now" link includes the active tab
[10:29:35 EDT(-0400)] <EricDalquist> where the first time you target a portlet not all of the URL parameters actually get processed correctly
[10:29:58 EDT(-0400)] <athena> er, hm, maybe i'm looking at it wrong
[10:30:00 EDT(-0400)] <athena> oh, interesting
[10:30:05 EDT(-0400)] <athena> and that's definitely a first target
[10:30:39 EDT(-0400)] <athena> ok, here we go
[10:30:42 EDT(-0400)] <EricDalquist> I'll check into any local mods we may have
[10:30:46 EDT(-0400)] <athena> the link just goes to uP_fname=
[10:30:51 EDT(-0400)] <EricDalquist> also check in the 3.1 patches branch
[10:30:52 EDT(-0400)] <EricDalquist> ah
[10:30:53 EDT(-0400)] <EricDalquist> yeah
[10:30:56 EDT(-0400)] <EricDalquist> that was the bug
[10:31:09 EDT(-0400)] <athena> ok
[10:32:04 EDT(-0400)] <EricDalquist> it may be http://www.ja-sig.org/issues/browse/UP-2366
[10:32:30 EDT(-0400)] <dstn> yes, its the same
[10:32:40 EDT(-0400)] <dstn> since it just uses fname
[10:32:49 EDT(-0400)] <dstn> I'll mark it as dup
[10:34:16 EDT(-0400)] <athena> eric i may have a few extra min this week and sunday
[10:34:42 EDT(-0400)] <athena> i've got two JIRAs on the up 3.1.1 list
[10:34:58 EDT(-0400)] <athena> would you want me to look at those, or is it feeling late for fixes?
[10:35:19 EDT(-0400)] <EricDalquist> go ahead
[10:35:30 EDT(-0400)] <athena> ok
[10:36:01 EDT(-0400)] <athena> i assume you'll send something out when you want to freeze the branch? i just don't want to get in your way
[10:36:43 EDT(-0400)] <dstn> actually wait, UP-2366 says it was fixed in 3.1 – this is what we're using
[10:37:43 EDT(-0400)] <EricDalquist> let me verify the issue id
[10:39:29 EDT(-0400)] <dstn> k, let me see if someone here has a vanilla 3.1 with test portlet
[10:39:40 EDT(-0400)] <EricDalquist> it isn't fixed in 3.1
[10:39:50 EDT(-0400)] <EricDalquist> I just did the fix a few weeks ago
[10:41:08 EDT(-0400)] <athena> so it just needs it's jira info updated?
[10:41:50 EDT(-0400)] <EricDalquist> it may be a different jira issue
[10:42:36 EDT(-0400)] <athena> eric did we decide to do anything about the column issue yale reported in 3.1? i don't see a jira for it
[10:42:38 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/issues/browse/UP-2423
[10:42:44 EDT(-0400)] <EricDalquist> ?
[10:43:05 EDT(-0400)] <EricDalquist> I can't remember what they reported
[10:43:10 EDT(-0400)] <dstn> ok, that sounds right
[10:43:13 EDT(-0400)] <dstn> sry
[10:43:32 EDT(-0400)] <athena> basically schools that used the experimental ajax features in 2.6 wound up with data that marked columns as arbitrary widths
[10:43:40 EDT(-0400)] <EricDalquist> dstn: no problem
[10:43:47 EDT(-0400)] <EricDalquist> oh
[10:43:49 EDT(-0400)] <athena> so you might have one that's 25.6983% width
[10:43:54 EDT(-0400)] <athena> and the current theme doesn't handle it
[10:43:56 EDT(-0400)] <EricDalquist> a jira would be good
[10:44:05 EDT(-0400)] <athena> dstn: did you ever file one for that?
[10:44:11 EDT(-0400)] <EricDalquist> I think we talked about adding support for 100 different CSS classes
[10:44:14 EDT(-0400)] <athena> yeah
[10:44:19 EDT(-0400)] <dstn> I did not
[10:44:20 EDT(-0400)] <dstn> I can though
[10:44:40 EDT(-0400)] <athena> EricDalquist: i think that's right - doing that, then rounding down the width attribute?
[10:44:49 EDT(-0400)] <athena> dstn: that'd be awesome, if you don't mind
[10:44:59 EDT(-0400)] <athena> that was the other thing i was thinking of trying to get fixed for 3.1.1
[10:44:59 EDT(-0400)] <EricDalquist> athena: yeah
[10:45:12 EDT(-0400)] <athena> i think rounding down is probably safest
[10:45:24 EDT(-0400)] <dstn> there is also another issue with IE7 and > 100% pushes the last column down
[10:45:29 EDT(-0400)] <athena> probably better to have it add up to 99 instead of 101
[10:45:32 EDT(-0400)] <athena> yeah, i'm not surprised
[10:45:41 EDT(-0400)] <athena> i don't think the old theme handled it very well either
[10:45:51 EDT(-0400)] <EricDalquist> dstn: yes I think we just got a report of that
[10:45:54 EDT(-0400)] <athena> although i can ask Fluid if that's something they'd consider a bug
[10:46:10 EDT(-0400)] <EricDalquist> even though our column widths == 100%
[10:46:17 EDT(-0400)] <EricDalquist> I'm wondering if it is some padding somewhere
[10:46:27 EDT(-0400)] <EricDalquist> and other than that have no clue what to do to fix it
[10:46:44 EDT(-0400)] <dstn> our fix, although not the greatest was to make it add up to < 100%
[10:47:02 EDT(-0400)] <dstn> with 3 columns, the space on the right isn't bad
[10:47:11 EDT(-0400)] <EricDalquist> hrm
[10:47:13 EDT(-0400)] <dstn> but the more columns, the worse it gets
[10:47:23 EDT(-0400)] <athena> hm, that doesn't sound right
[10:47:35 EDT(-0400)] <athena> you're seeing that happen even with the columns adding up to 100%?
[10:47:58 EDT(-0400)] <dstn> no, i'm saying based on our fix of making them add up to < 100%
[10:48:24 EDT(-0400)] <dstn> for instance, defining the 25 as 24% means its 4% off
[10:48:32 EDT(-0400)] <EricDalquist> athena: yes, we have 2 columns, 60% 40%
[10:48:41 EDT(-0400)] <athena> hm
[10:48:45 EDT(-0400)] <EricDalquist> and some users on IE7 see the column wrap if the browser window is too narrow
[10:48:45 EDT(-0400)] <dstn> but with lesser columns, the percent off is not as great
[10:48:51 EDT(-0400)] <athena> i'm pretty sure it doesn't do that in the default skin
[10:49:05 EDT(-0400)] <dstn> really? I thought it did
[10:49:21 EDT(-0400)] <dstn> off to file the widths issue
[10:49:21 EDT(-0400)] <dstn> brb
[10:55:41 EDT(-0400)] <dstn> Ok - http://www.ja-sig.org/issues/browse/UP-2433
[10:58:34 EDT(-0400)] <athena> thanks!
[11:00:41 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:02:49 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:08:08 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:16:57 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:30:46 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:39:15 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:03:46 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[12:19:47 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:27:26 EDT(-0400)] * bszabo_ (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[12:45:29 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * brad_laptop (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[12:45:29 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:45:29 EDT(-0400)] * apetro- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * Tuomaz (n=fredrik@ip223.taftea.se) has joined ##uportal
[12:46:25 EDT(-0400)] * monteslu (n=monteslu@ip68-109-171-127.ph.ph.cox.net) has joined ##uportal
[12:46:46 EDT(-0400)] * ChanServ (ChanServ@services.) has joined ##uportal
[12:46:46 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[12:46:46 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[12:46:46 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:46:46 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:47:14 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:47:48 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:54:01 EDT(-0400)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:02:22 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[14:09:50 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:25:50 EDT(-0400)] <awills> hey folks...trying to wrap up UP-2174 (Support multiple user profiles in import/export tool), and I'd like to solicit some suggestions...
[14:25:57 EDT(-0400)]

[14:26:02 EDT(-0400)] <awills> should the output be 1 profile or all?
[14:33:07 EDT(-0400)] <athena> if it were one, how would we pick which profile to export?
[14:33:37 EDT(-0400)] <athena> does importing them actually work?
[14:34:23 EDT(-0400)] <awills> good question... what would be the result of always exporting profile 1 in that case?
[14:34:54 EDT(-0400)] <athena> it seems like in this case you really need two sysid identifiers
[14:35:16 EDT(-0400)] <awills> importing works, but it always imports to id=1 atm
[14:35:20 EDT(-0400)] <athena> one for the username, and one to be an identifier for the profile - either the name or whatever
[14:35:22 EDT(-0400)] <athena> ok
[14:35:30 EDT(-0400)] <athena> so it works for importing single profiles, but not multiple ones
[14:35:42 EDT(-0400)] <awills> that's right
[14:36:02 EDT(-0400)] <athena> gotcha
[14:36:05 EDT(-0400)] <awills> alternately, i could export all profiles for the specified user
[14:36:35 EDT(-0400)] <awills> i think it would work out, but would be slightly trickier for the portlet
[14:36:40 EDT(-0400)] <athena> that does seem like it's probably appropriate, without some sort of requested profile identifier
[14:36:51 EDT(-0400)] <athena> are they in different files?
[14:37:02 EDT(-0400)] <athena> maybe the portlet could output a batch file?
[14:37:11 EDT(-0400)] <awills> yeah, and I'd prefer not to introduce the complexity of another parameter
[14:37:16 EDT(-0400)] <athena> gotcha
[14:37:28 EDT(-0400)] <awills> yes, the portlet could do that... that's what i was thinking
[14:38:16 EDT(-0400)] <awills> for import, i'll have to change it to upsert on the profile name, which already exists and shouldn't be an issue
[14:38:59 EDT(-0400)] <athena> but if the relevant profiles don't exist (you're creating rather than updating), i suspect it wouldnt' work correctly
[14:39:08 EDT(-0400)] <athena> because the correct profile IDs wouldn't be assigned
[14:39:32 EDT(-0400)] <awills> ah... what works and doesn't when the user logs in is another matter
[14:39:41 EDT(-0400)] <athena> lol
[14:40:07 EDT(-0400)] <athena> well, perhaps it "works" if you define works to be "puts something in the database and claims success"
[14:40:09 EDT(-0400)] <awills> we know that code needs attention, if we're to support multiple profiles for real
[14:40:12 EDT(-0400)] <athena> yeah
[14:40:19 EDT(-0400)] <athena> someone really just needs to go in and make that not suck
[14:40:49 EDT(-0400)] <athena> probably just making the code do profile lookup by name rather than ID would be good enough to really actually fix this problem
[14:41:02 EDT(-0400)] <athena> it might not fix the issue with new users logging in who don't already have profiles
[14:41:14 EDT(-0400)] <athena> but i bet it would get the import really truly working (from the user's perspective)
[14:41:15 EDT(-0400)] <awills> yeah... but what it puts in the db needs to (1) work no worse than now w/ the code that's there, and (2) work appropriately with the needed fix once it's there
[14:41:24 EDT(-0400)] <athena> yeah
[14:41:26 EDT(-0400)] <athena> that's fair
[14:41:32 EDT(-0400)] <athena> and i think what you're proposing will do that
[14:41:37 EDT(-0400)] <awills> i do to
[14:42:00 EDT(-0400)] <athena> i do think the overall issue should get prioritized as a 3.2 fix
[14:42:08 EDT(-0400)] <awills> +1
[14:42:21 EDT(-0400)] <athena> we're getting to the point in the world where having a mobile theme would be really valuable and a good feature for uportal to be able to advertise
[14:42:26 EDT(-0400)] <awills> i'd like to see uP on modern phones asap
[14:42:34 EDT(-0400)] <athena> really we probably need this fix and at least one default mobile theme
[14:42:37 EDT(-0400)] <athena> me too
[14:42:58 EDT(-0400)] <awills> i'm on board... i'll do what I can to make it happen
[14:42:59 EDT(-0400)] <athena> i tried to convince yale to buy me an iphone a few years back so i could do iphone portal development, but that didn't really fly
[14:43:04 EDT(-0400)] <awills> and this is part of it
[14:43:13 EDT(-0400)] <athena> excellent
[14:43:28 EDT(-0400)] <athena> though ironically, i think there's real interest there from yale students: http://www.yaledailynews.com/articles/view/27336
[14:43:38 EDT(-0400)] <awills> i'm going to split for lunch, but will bb in a bit
[14:43:39 EDT(-0400)] <athena> they don't know they want a uportal mobile theme, but that's basically what they're asking for
[14:43:41 EDT(-0400)] <athena> cya!
[15:13:18 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[15:20:38 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal