uPortal IRC Logs-2011-10-31

Owned by Apereo Infrastructure
Last updated: Oct 31, 2011Version comment

[09:47:14 CDT(-0500)] <b-rock> Greetings uPortal devs: I'm working in uP4.0.1. I can see my fragments listed in the "Audit DLM Fragments" but in the "Fragment Administration" portlet, the drop down is empty with no portlets able to be selected. I don't see errors in the logs. do you know where the list for the drop down is generated?

[09:47:43 CDT(-0500)] <b-rock> maybe there is an issue w/ that or something else in the data.

[10:18:48 CDT(-0500)] <EricDalquist> b-rock: I'm wondering if you're missing some permissions setup

[10:18:55 CDT(-0500)] <EricDalquist> this is with your imported data set?

[10:19:57 CDT(-0500)] <b-rock> Hi EricDalquist.

[10:20:28 CDT(-0500)] <b-rock> I'm not sure. would that be something in the permissions folder of the exported data?

[10:20:47 CDT(-0500)] <EricDalquist> permissions usage changed from 3.x to 4

[10:20:59 CDT(-0500)] <EricDalquist> so my question is, are you seeing this with the default up4 dat

[10:21:11 CDT(-0500)] <EricDalquist> or are you see this with the data you imported from 3x

[10:21:15 CDT(-0500)] <b-rock> ok. I did do the import of the default data first.

[10:21:28 CDT(-0500)] <b-rock> maybe my 3.2 data imported broke the default settings

[10:21:34 CDT(-0500)] <EricDalquist> so you are seeing this with the data you imported from 3.x then?

[10:21:47 CDT(-0500)] <b-rock> yes after running the required and default imports.

[10:21:55 CDT(-0500)] <EricDalquist> right

[10:22:11 CDT(-0500)] <b-rock> should I maybe try re-importing the default data then?

[10:22:29 CDT(-0500)] <b-rock> or the required and default data?

[10:22:36 CDT(-0500)] <EricDalquist> no

[10:22:38 CDT(-0500)] <b-rock> ok

[10:22:46 CDT(-0500)] <EricDalquist> hold on a minute and let me look into a few things (smile)

[10:22:57 CDT(-0500)] <b-rock> ok. np. I know your swamped.

[10:23:00 CDT(-0500)] <EricDalquist> so it looks like we may need to move more data from quickstart to default

[10:23:06 CDT(-0500)] <b-rock> ok

[10:23:20 CDT(-0500)] <EricDalquist> all of the permissions grants are defined by files in uportal-war/src/main/data/quickstart_entities/permission_set

[10:23:26 CDT(-0500)] <b-rock> ahh

[10:24:02 CDT(-0500)] <EricDalquist> I'm thinking we need to move some of those into the default entities folder

[10:24:08 CDT(-0500)] <b-rock> ok

[10:24:27 CDT(-0500)] <EricDalquist> actually looking at them it might be prudent to move all of them ....

[10:25:23 CDT(-0500)] <EricDalquist> I think it might be Portal_Administrators_IMPERSONATE_UP_USERS.permission-set.xml that you need

[10:25:30 CDT(-0500)] <EricDalquist> athena: you there?

[10:25:47 CDT(-0500)] <b-rock> ok. I'll give that a try first to see if that fixes it

[10:26:50 CDT(-0500)] <EricDalquist> yup that is it

[10:27:12 CDT(-0500)] <EricDalquist> the fragment admin portlet does:

[10:27:16 CDT(-0500)] <EricDalquist> gets list of all fragment owners

[10:27:28 CDT(-0500)] <EricDalquist> for each fragment owner makes the check: principal.hasPermission(UP_USERS, IMPERSONATE, frag.getOwnerId())

[10:27:48 CDT(-0500)] <b-rock> ok that makes sense. importing now...

[10:28:13 CDT(-0500)] <athena> hey EricDalquist

[10:28:18 CDT(-0500)] <EricDalquist> hi athena

[10:28:42 CDT(-0500)] <athena> what's up?

[10:28:49 CDT(-0500)] <EricDalquist> so for some reason I stuck all of the permission_set data in the quickstart dat set and not the default data set

[10:28:51 CDT(-0500)] <EricDalquist> :/

[10:29:02 CDT(-0500)] <EricDalquist> looking through our base permissions they are fairly simple

[10:29:14 CDT(-0500)] <EricDalquist> so I'm thinking we should move that into the default data

[10:30:09 CDT(-0500)] <athena> ooh

[10:30:19 CDT(-0500)] <athena> yeah, i think that's a good idea

[10:30:37 CDT(-0500)] <athena> well

[10:30:53 CDT(-0500)] <athena> actually that might not be easy to do, because most of the permissions reference stuff that might not be in default?

[10:31:18 CDT(-0500)] <EricDalquist> not really they only reference a few of the core groups

[10:31:54 CDT(-0500)] <athena> oh ok, cool then (smile)

[10:35:47 CDT(-0500)] <EricDalquist> I REALLY hate that Java doesn't read UTF-8 BOM files correctly :/

[10:36:36 CDT(-0500)] <athena> (sad)

[10:40:54 CDT(-0500)] <b-rock> ok thanks EricDalquist. that fixed it and I see the fragments now. I tried switching to a fragment which broke because there is no layout for the fragment owner.

[10:50:42 CDT(-0500)] <b-rock> ok. I notice that I can see the fragments in the drop down initially when I start the portal. but if I log into a fragment and log out the fragments go away from the dropdown.

[10:51:12 CDT(-0500)] <b-rock> the don't show up again until I restart the portal. Im wondering if maybe there is another permission I need to add.

[10:52:32 CDT(-0500)] <EricDalquist> huh

[10:52:34 CDT(-0500)] <EricDalquist> that is strange

[10:52:42 CDT(-0500)] <EricDalquist> either that or it is a bug in the idswap code

[10:52:48 CDT(-0500)] <EricDalquist> that is resulting in the broken permission check

[10:53:16 CDT(-0500)] <b-rock> I don't see anything in the logs, but I think they are set at INFO

[10:54:23 CDT(-0500)] <EricDalquist> the permissions service caches checks

[10:54:33 CDT(-0500)] <EricDalquist> I'm just wondering if something is getting confused on un-swap

[10:54:51 CDT(-0500)] <EricDalquist> and it is either using the fragment user for the look even though you're back to yourself

[10:55:02 CDT(-0500)] <EricDalquist> or the lookup as fragment user got cached somehow in your session

[10:55:08 CDT(-0500)] <EricDalquist> I'm not that familiar with that code

[10:56:06 CDT(-0500)] <b-rock> ok. do you know where that code is in the portal? I can add some debug lines to it and see if It will show whats happening.

[10:57:03 CDT(-0500)] <EricDalquist> not off the top of my head

[10:57:28 CDT(-0500)] <b-rock> ok np. I'll try digging around for it.

[10:58:12 CDT(-0500)] <EricDalquist> the top level bit of code that gets called by the webflow is FragmentAdministrationHelper

[10:58:45 CDT(-0500)] <b-rock> ok thanks.

[11:30:08 CDT(-0500)] <athena> apparently we need to drop the google search portlet

[11:30:13 CDT(-0500)] <athena> google is deprecating that API

[11:30:21 CDT(-0500)] <EricDalquist> oi

[11:30:22 CDT(-0500)] <athena> replacing it w/ a new custom search one that limits to 100 requests a day

[11:30:25 CDT(-0500)] <athena> all seems pretty pointless

[11:30:33 CDT(-0500)] <athena> also, that's not really a super high value portlet anyway

[11:30:34 CDT(-0500)] <EricDalquist> yeah

[11:30:41 CDT(-0500)] <athena> i vote we just kill it and move on

[11:30:47 CDT(-0500)] <EricDalquist> sounds good to me

[11:30:56 CDT(-0500)] <EricDalquist> we can focus on the built in uPortal search

[11:31:00 CDT(-0500)] <athena> yep!

[11:31:03 CDT(-0500)] <athena> much more interesting

[11:33:13 CDT(-0500)] <EricDalquist> ok found a commons-io class that seems to be much better about stripping the BOM

[11:33:23 CDT(-0500)] <EricDalquist> time for yet another resource server release :/

[11:36:08 CDT(-0500)] <EricDalquist> but I'll have a simple content portlet release out soon

[11:37:17 CDT(-0500)] <athena> oh excellent

[11:37:29 CDT(-0500)] <athena> seems like we should have a lot of great fixes in 4.0.2

[11:38:17 CDT(-0500)] <EricDalquist> yup

[11:38:31 CDT(-0500)] <EricDalquist> helps that we have so many people trying it out and working to upgrade

[11:38:35 CDT(-0500)] <EricDalquist> I'm having a hard time keeping up (tongue)

[11:38:46 CDT(-0500)] <athena> yeah

[11:38:49 CDT(-0500)] <athena> nice problem to have though

[11:39:01 CDT(-0500)] <athena> seems like people are looking to upgrade sooner than they have in the past

[11:39:25 CDT(-0500)] <EricDalquist> brb

[12:04:43 CDT(-0500)] <EricDalquist> athena: any thoughts on moving ckeditor into the resource server?

[12:04:51 CDT(-0500)] <EricDalquist> or is the code in simple CMS customized?

[13:05:21 CDT(-0500)] <EricDalquist> question on read only portlet preferences

[13:05:32 CDT(-0500)] <EricDalquist> should a portlet be able to modify them while in CONFIG mode?

[13:05:35 CDT(-0500)] <EricDalquist> during publishing

[13:05:55 CDT(-0500)] <athena> hmm

[13:06:07 CDT(-0500)] <athena> i think that does sort of seem consistent with how we treat them

[13:06:12 CDT(-0500)] <holdorph> it could back in the channel manager days

[13:06:23 CDT(-0500)] <holdorph> not exactly config mode, but it was what we had at that time

[13:06:25 CDT(-0500)] <athena> seems like we in have been using read-only prefs to represent properties that aren't user-editable

[13:06:28 CDT(-0500)] <holdorph> it was useful

[13:06:31 CDT(-0500)] <athena> does the spec say anything about it?

[13:06:31 CDT(-0500)] <athena> yeah

[13:06:37 CDT(-0500)] <athena> sort of like the override yes/no

[13:06:41 CDT(-0500)] <EricDalquist> it is completely up to us

[13:06:59 CDT(-0500)] <holdorph> CONIFG mode is not detailed extensively in the portlet spec, it's loosely in the appendix

[13:07:00 CDT(-0500)] <athena> sounds like a useful distinction to me, as long as we document it

[13:08:21 CDT(-0500)] <EricDalquist> ok, sounds like we're all on the same page

[13:10:20 CDT(-0500)] <athena> awesome

[13:10:25 CDT(-0500)] <athena> features! hurray!

[13:10:35 CDT(-0500)] <EricDalquist> well bug fixes (smile)

[13:11:45 CDT(-0500)] <athena> (smile)

[15:52:09 CDT(-0500)] <athena> ok, so to merge changes from uportal trunk into the umobile branch

[15:52:22 CDT(-0500)] <EricDalquist> I think:

[15:52:27 CDT(-0500)] <athena> i assume i'd check out the umobile branch

[15:52:28 CDT(-0500)] <EricDalquist> git checkout umobile

[15:52:30 CDT(-0500)] <athena> then merge the master into it?

[15:52:31 CDT(-0500)] <EricDalquist> git mege master

[15:52:32 CDT(-0500)] <athena> and then push?

[15:52:35 CDT(-0500)] <EricDalquist> yup

[15:52:38 CDT(-0500)] <athena> ok

[15:52:44 CDT(-0500)] <athena> shall try (smile)

[15:53:10 CDT(-0500)] <EricDalquist> cutting CMS portlet release ...

[16:05:44 CDT(-0500)] <EricDalquist> athena: did you see nick's latest caching tweaks>?

[16:05:55 CDT(-0500)] <athena> yes, just finished testing it!

[16:05:57 CDT(-0500)] <athena> seems like it works

[16:05:58 CDT(-0500)] <EricDalquist> the portal should now be setting expires and cache-control headers

[16:06:14 CDT(-0500)] <athena> goign to go through and pullt hose into the umobile codebase so i can make sure it's all in order

[16:06:24 CDT(-0500)] <EricDalquist> cache-control should be really nice if we have things that do public news feeds

[16:06:51 CDT(-0500)] <athena> yeah

[16:07:01 CDT(-0500)] <athena> actually

[16:07:11 CDT(-0500)] <athena> i bet we could start using that for the single-feed portlet version

[16:07:31 CDT(-0500)] <EricDalquist> (smile)

[16:07:38 CDT(-0500)] <athena> though would have to figure out how the portlet's existing feed cache and the portal-facing cache shoudl interact

[16:07:47 CDT(-0500)] <athena> so that you don't get stuff living longer than you meant to

[16:08:09 CDT(-0500)] <EricDalquist> true

[16:09:51 CDT(-0500)] <EricDalquist> also I added a batch-aggregation goal in the aggregator plugin

[16:10:17 CDT(-0500)] <EricDalquist> so you can do stuff like: <include>media/skins/universality/**/skin.xml</include>

[16:10:33 CDT(-0500)] <EricDalquist> then places like us with 20 skins don't have to list them all explicitly (tongue)

[16:12:00 CDT(-0500)] <athena> oh! hurray!

[16:12:07 CDT(-0500)] <athena> that sounds really useful

[16:12:15 CDT(-0500)] <athena> plus forgetting to map skins is a pretty common bug

[16:12:23 CDT(-0500)] <EricDalquist> yeah

[16:41:50 CDT(-0500)] <EricDalquist> bah bit again by bamboo and new dependencies (tongue)

[16:42:14 CDT(-0500)] <athena> uhoh!

[16:50:54 CDT(-0500)] <Daskreech> Hello

[16:50:58 CDT(-0500)] <Daskreech> I'm trying to get a web proxy working with a medium complexity site

[16:51:01 CDT(-0500)] <Daskreech> I am getting a channel failed to render error

[16:51:04 CDT(-0500)] <Daskreech> Is there a way to try and change something to get around a rendering problem?

[16:51:45 CDT(-0500)] <EricDalquist> Daskreech: your best bet is to share the full stack trace and error message from the portlet's log file on the portlet-user email list: https://wiki.jasig.org/display/JSG/portlet-user

[16:51:57 CDT(-0500)] <Daskreech> can I also how I find out what version of uPortal I'm running?

[16:52:18 CDT(-0500)] <EricDalquist> you are not the one who installed uPortal?

[16:54:38 CDT(-0500)] <EricDalquist> athena: in the umobile common_skin.xml file

[16:55:59 CDT(-0500)] <EricDalquist> <js>../common/javascript/up-mobile-config.js</js> is listed before jquery.mobile-1.0b1

[16:56:18 CDT(-0500)] <EricDalquist> and then there are more local js files listed after that

[16:56:23 CDT(-0500)] <Daskreech> EricDalquist: Nope

[16:56:56 CDT(-0500)] <EricDalquist> I'm not sure if it would break things but if possible moving the up-mobile-config.js files after jquery.mobile it would reduce the number of js fiels to download by 1

[16:56:57 CDT(-0500)] <Daskreech> Just asked to have a Face book and a Calendar turn up in WebProxy for a site

[16:57:27 CDT(-0500)] <EricDalquist> Daskreech do you have access to the uPortal build directory for the project?

[16:57:33 CDT(-0500)] <EricDalquist> brb

[16:57:37 CDT(-0500)] <Daskreech> EricDalquist: Yes

[16:57:38 CDT(-0500)] <Daskreech> ok

[17:00:32 CDT(-0500)] <EricDalquist> is there a pom.xml file in the uPortal source dir?

[17:06:01 CDT(-0500)] <athena> no, sadly that config file actually has to get loaded before jquery mobile

[17:06:12 CDT(-0500)] <athena> it sets some configuration that's used at jqm initialization time

[17:06:20 CDT(-0500)] <athena> i'm not really thrilled about their config style, but that's how it works

[17:06:21 CDT(-0500)] <Daskreech> EricDalquist: version 3.1.0

[17:06:43 CDT(-0500)] <Daskreech> in META-INF/maven//

[17:07:07 CDT(-0500)] <Daskreech> in META-INF/maven/*/uportal-war

[17:08:35 CDT(-0500)] <EricDalquist> there ya go (smile)

[17:08:39 CDT(-0500)] <EricDalquist> athena: oh well

[17:08:43 CDT(-0500)] <athena> yeah (sad)

[17:15:47 CDT(-0500)] <Daskreech> EricDalquist: hmm just looked at the portal.log and WebProxy.log and they are from Feb of this year

[17:16:39 CDT(-0500)] <EricDalquist> Daskreech: hrm, if you're seeing "channel failed to render error" that implies an uncaught exception was thrown by the portlet and that should end up in the portal log

[17:17:17 CDT(-0500)] <Daskreech> Yeah I'm going to do a find on the directory to see any files which changed in the past week to see if something is going awry

[17:17:46 CDT(-0500)] <EricDalquist> athena: how did the master->umobile merge go?

[17:18:32 CDT(-0500)] <athena> seems to have gone well

[17:19:31 CDT(-0500)] <EricDalquist> thats good, github seems to think it is up to date with master (smile)

[17:20:10 CDT(-0500)] <athena> yeah (smile)

[17:20:13 CDT(-0500)] <athena> nice to have that graph

[17:20:26 CDT(-0500)] <EricDalquist> yeah, makes it a lot easier to track where branches are in relation to each other

[17:20:27 CDT(-0500)] <athena> just fixing a few issues right now - it pulled in uportal version numbers for some of the overlays

[17:20:30 CDT(-0500)] <athena> easily fixable

[17:20:31 CDT(-0500)] <athena> yeah

[17:26:02 CDT(-0500)] <Daskreech> Ah found it someone moved it to a new location and left the old one

[17:27:52 CDT(-0500)] <Daskreech> client.CASReceipt.[] Oct/18 06:42:44 - validation of [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] [edu.yale.its.tp.cas.client.ServiceTicketValidator BROKEN SECURITY MODE SUITABLE ONLY FOR DEMO PURPOSES <---- would that be relevant ?

[17:28:10 CDT(-0500)] <EricDalquist> probably not

[17:28:31 CDT(-0500)] <EricDalquist> though I wouldn't want to see that message in a prod log for anything I admin (smile)

[17:28:48 CDT(-0500)] <EricDalquist> it is related to how the portal validates CAS login tickets I think

[17:28:58 CDT(-0500)] <Daskreech> Yeah I'll look at it when I'm done

[17:30:10 CDT(-0500)] <EricDalquist> ok time to head home, catch everyone tomorrow

[17:30:19 CDT(-0500)] <Daskreech> Night

[17:30:29 CDT(-0500)] <Daskreech> I just got kicked from the server in any case (sad)