[11:22:46 CDT(-0500)] <b-rock> Greetings EricDalquist: I'm working through importing data from 3.2 to up4.0.1 and have come up with an issue. http://pastebin.com/JNQAVT9X seems like groups from the grouper service are being compared to categories during the channel imports.
[11:23:30 CDT(-0500)] <b-rock> I wonder if I should just disable grouper for the import and then re-apply the group settings for each portlet from the front end.
[11:24:18 CDT(-0500)] <b-rock> other parts of the import are working with grouper enabled,
[11:24:29 CDT(-0500)] <EricDalquist> do you have portlets that are permissioned to your grouper groups?
[11:24:58 CDT(-0500)] <b-rock> yes there are some of those but the failure seems to be happening for portlets that do not use grouper groups.
[11:25:17 CDT(-0500)] <b-rock> when I have grouper turned off the portlets with grouper groups crash.
[11:25:51 CDT(-0500)] <b-rock> It may be easier though just removing those channels grouper group's and manually applying them after the import
[11:26:33 CDT(-0500)] <b-rock> I haven't figured out yet when grouper is being called during the import.
[11:26:54 CDT(-0500)] <b-rock> or where it is being called
[11:27:27 CDT(-0500)] <EricDalquist> it will be called for every portlet
[11:28:03 CDT(-0500)] <EricDalquist> when you're doing a migration your target portal instance needs to have all of the user attribute and groups sources configured that the old portal did
[11:28:07 CDT(-0500)] <b-rock> ok that makes since since there can be grouper groups in the groups section of the data but it looks like grouper is being called while the categories seciton is being compared
[11:28:19 CDT(-0500)] <EricDalquist> categories are just groups of portlets
[11:28:24 CDT(-0500)] <EricDalquist> instead of groups of people
[11:28:28 CDT(-0500)] <b-rock> ok
[11:28:37 CDT(-0500)] <EricDalquist> so it is all part of the groups system
[11:28:59 CDT(-0500)] <b-rock> I did take your advice and make sure all of the configurations in the 4.0.1 build have our settings as they are in the 3.2 builds
[11:29:18 CDT(-0500)] <EricDalquist> great
[11:29:20 CDT(-0500)] <b-rock> same dlm.xml pagsGroupStore and other configs
[11:30:05 CDT(-0500)] <b-rock> so far users, profile and fragment_layouts all import without error consistently. every other data set is hit or miss.
[11:30:45 CDT(-0500)] <b-rock> sometimes they run to completion but the data doen't make it to the db. other times it just errors out.
[11:31:39 CDT(-0500)] <b-rock> I was thinking the data needs to be imported in a certain order based on some of the errors I've been seeing. like group_membership needs to happen before permission_set
[11:33:07 CDT(-0500)] <b-rock> I know your still swamped but I thought this could be helpful for others trying to upgrade if there are still some issues in the import. probably complicated though with grouper in place.
[11:37:05 CDT(-0500)] <EricDalquist> all of the per-type ordering is very explicitly enforced by the import process
[11:37:51 CDT(-0500)] <EricDalquist> if you want to try and simplify what you see go into portal.properties in the 4.0 code and change the property org.jasig.portal.io.threadPool.maxThreads to 1
[11:37:52 CDT(-0500)] <b-rock> yeah I figured that but I dont know what the order is. is it documented somewhere or can I add it to the wiki if you have it?
[11:38:15 CDT(-0500)] <EricDalquist> well what you should be doing is just pointing the import process at your exported data dir
[11:38:28 CDT(-0500)] <EricDalquist> and the importer will load up ALL the files and import the in the right order
[11:38:40 CDT(-0500)] <EricDalquist> but the order is:
[11:38:41 CDT(-0500)] <b-rock> ok I'll make the mod and re-run.
[11:39:03 CDT(-0500)] <EricDalquist> defined by the dataTypeImportOrder bean in uportal-war/src/main/resources/properties/contexts/importExportContext.xml
[11:39:42 CDT(-0500)] <b-rock> I've been chunking it up because parts of it would run ok but then bomb half way through. I though I could do them in chunks and then focus in on debugging where the import fails.
[11:40:08 CDT(-0500)] <b-rock> initially i did just point the importer at the exported data
[11:40:41 CDT(-0500)] <b-rock> thanks. I 'll take a look at he importExportcontext.xml file to make sure I've got the order right.
[11:40:48 CDT(-0500)] <EricDalquist> sounds good
[11:40:52 CDT(-0500)] <EricDalquist> thanks for your help on this as well
[11:41:07 CDT(-0500)] <EricDalquist> I did a lot of testing but unfortunatly its still bumpy for the early adopters
[11:41:40 CDT(-0500)] <b-rock> yeah np. I hoped I would have had this process nailed down by now since I've been through 2 schema change upgrades
[11:42:18 CDT(-0500)] <EricDalquist> yeah, its always the layouts that cause all the problems
[11:42:30 CDT(-0500)] <EricDalquist> I cannot wait until we can get that code rewritten
[11:42:39 CDT(-0500)] <EricDalquist> should save us A LOT of headaches
[11:42:50 CDT(-0500)] <b-rock> yeah
[13:35:43 CDT(-0500)] <b-rock> Hi EricDalquist. I think I found the issue with the our channel imports. the PortletDefinitionImporterExporter searches the group service for categories. grouper returns results regardless of leafType. I think it needs to do what PAGS does and short circuit if the leafType is not IPerson.
[13:36:02 CDT(-0500)] <EricDalquist> yes
[13:36:08 CDT(-0500)] <b-rock> I re-ran the import w/ this check and it did just fine
[13:36:18 CDT(-0500)] <EricDalquist> that would be the correct thing for it to do if it can only group people
[13:36:21 CDT(-0500)] <b-rock> do you want me to send you the patch for this?
[13:36:24 CDT(-0500)] <EricDalquist> yes please
[13:36:29 CDT(-0500)] <b-rock> sure thing...
[13:36:30 CDT(-0500)] <EricDalquist> open up a jira issue and attach a patch
[13:45:42 CDT(-0500)] <b-rock> ok https://issues.jasig.org/browse/UP-3223 not sure if the same logic needs to be applied for searching for entities because I haven't run into that query yet.
[14:25:34 CDT(-0500)] <brandon_> hello
[14:26:30 CDT(-0500)] <brandon_> had a question about overlays
[14:27:10 CDT(-0500)] <brandon_> uportal came with an overlay for cas which i was using up until i made cas external on its own server
[14:28:37 CDT(-0500)] <brandon_> now i can build it on the uportal server and copy the cas.war over to the cas server but i'd rather not
[14:28:57 CDT(-0500)] <brandon_> would the uportal's cas overlay work if i just copied it to the cas server?
[14:32:23 CDT(-0500)] <athena> i suppose it would, but if you're managing cas separately i'd recommend just managing it as a separate project
[14:32:29 CDT(-0500)] <athena> which you're welcome to do with an overlay style
[14:32:35 CDT(-0500)] <athena> might look at the cas documentation directly
[14:35:24 CDT(-0500)] <brandon_> yeah, that's what i'm going for
[14:35:36 CDT(-0500)] <brandon_> just that now it's working but is on the uportal machine
[14:35:48 CDT(-0500)] <brandon_> and i wanted to know if it would break if i transferred it to the cas machine
[14:40:53 CDT(-0500)] <athena> should probably be ok
[15:02:56 CDT(-0500)] <b-rock> shoot booted of freenode.
[15:03:04 CDT(-0500)] <b-rock> more shoot. meeting now.
[15:51:27 CDT(-0500)] <b-rock> Hi EricDalquist. I amended the patch I submitted earlier today and reposted it to the ticket. It fixes the issues we were having importing permission_set data. the mod is to allow the searchForGroups() to toggle between an exact match or fuzzy group search