[00:06:29] *** tlev has quit IRC
[00:34:29] *** vertein has quit IRC
[00:56:59] *** goldmantx has quit IRC
[00:58:06] *** goldmantx has joined #jasig-uportal
[01:04:44] *** colinclark has quit IRC
[01:53:21] *** goldmantx has quit IRC
[02:22:49] *** jwennmacher has quit IRC
[02:31:46] *** drewwills has left #jasig-uportal
[03:13:02] *** goldmantx has joined #jasig-uportal
[07:22:48] *** goldmantx has quit IRC
[14:14:15] *** colinclark has joined #jasig-uportal
[15:15:13] *** vertein has joined #jasig-uportal
[15:24:45] *** goldmantx has joined #jasig-uportal
[15:39:23] *** tlev has joined #jasig-uportal
[16:36:17] *** lfuller has joined #jasig-uportal
[17:27:06] *** drewwills has joined #jasig-uportal
[17:34:18] <drewwills> are you theree apetro_, tlev, vertein?
[17:36:07] <tlev> hello drewwills
[17:36:22] <drewwills> Which do you prefer (to name a permission) "PUBLISH_PORTLET_TYPE" or "DEFINE_PORTLET_TYPE" or "SELECT_PORTLET_TYPE"
[17:37:02] <drewwills> Permission to select a portlet type (i.e. CPD) in the portlet manager when defining a NEW portlet
[17:37:29] <vertein> Hola!
[17:38:02] <vertein> If I'm selecting from a list, I guess I prefer select
[17:38:10] <tlev> i vote for select
[17:38:32] <drewwills> i think i was heading that way too
[17:44:23] <drewwills> any updated thoughts on cutting an RC?
[17:44:49] <tlev> yeah, we added a story to our current sprint (just started today). So we would like to do it in the next 2 weeks
[17:44:59] <drewwills> awesome
[17:45:17] <tlev> I was thinking of sending a note to the dev list
[17:45:24] <drewwills> can we then add cutting a GA to the following sprint?  :)
[17:45:53] <drewwills> terrific tlev
[17:47:00] <tlev> If we get all the bugs out then I think that could be possible
[17:47:28] *** goldmantx has quit IRC
[18:04:39] *** jsittler has quit IRC
[18:09:11] *** apetro__ has joined #jasig-uportal
[18:11:13] <apetro__> More likely looking at going into the conference with an RC and using the conference to focus in on a GA, I would think.
[18:15:55] <drewwills> perhaps we should organize a virtual meeting and catalog what's holding us up?
[18:17:19] <tlev> i think it would be good to have a RC, then see where we are at.  I like the idea of a virtual meeting post RC creation, before conference.
[18:18:18] *** jwennmacher has joined #jasig-uportal
[18:22:19] <jwennmacher> Wisc team: jgribonvald had added a comment (https://github.com/jameswennmacher/uPortal/commit/e817ab2c5420dd87c42c5baab33c7f8e4b5e43b3#commitcomment-6151437)  that channels in sidebar are considered rendered in statistics.  Does the same behavior exists for favorites or favorite collections?
[18:23:34] <apetro__> Offhand, I doubt it, since the favorites portions of the layout are not passed to the theme transform for rendering.  They're layout content.  But I haven't empirically looked at whether and what statistics is picking up about favorites, so I guess I could be wrong.
[18:25:41] <apetro__> That is, I think there's a distinction between content that is rendered by the server but then conditionally displayed based on client-side CSS and JavaScript magic (e.g. customize drawer portlet) vs portlets that are conditionally included in the theme for rendering (e.g., any portlet that's on a not-selected regular tab) vs. layout portions that are in fact *never* rendered as such (e.g. the "favorites" folder, wh
[18:25:41] <apetro__> ich is valuable layout data that informs the Favorites portlet, but which is never (except for troubleshooting) rendered as layout.
[18:26:07] <apetro__> )
[18:28:47] *** jsittler has joined #jasig-uportal
[18:29:25] *** vertein has quit IRC
[18:29:25] <tlev> they are only picked up if rendered
[18:29:53] <jwennmacher> good to hear
[18:57:41] *** goldmantx has joined #jasig-uportal
[19:56:23] <apetro__> Easy review and merge: https://github.com/Jasig/uPortal/pull/310
[20:00:49] <drewwills> looking
[20:06:24] <drewwills> so it looks like Marketplace-related plumbing (there's probably a better word) is in o.j.p.portlet.marketplace, but Marketplace UI is in o.j.p.portlets.marketplace
[20:07:15] <apetro__> Right.
[20:07:50] <apetro__> That's precisely the refactor undertaken in that changeset, to separate the Marketplace guts from the MarketplacePortlet view on those guts.
[20:08:17] <apetro__> This is towards re-using those guts in a MarketplaceServletController / servlet JSPs, and possibly in JSON APIs.
[20:09:27] <drewwills> perfectly sensible
[20:11:38] <drewwills> (This is not a suggestion -- merely brainstorming)  Did you consider org.jasig.portal.marketplace?
[20:13:16] <apetro__> considered
[20:13:29] <apetro__> didn't consider at any length
[20:14:00] <apetro__> that changeset *isn't* the result of a bunch of whiteboarding and implementation discussion and review here at Wisc, it's genuinely a changeset up for discussion and review.
[20:14:06] <apetro__> So, like, this is the considering. :)
[20:14:35] <apetro__> But, in coding it, it felt more like a recognition that Marketplace is becoming an aspect of uPortal's portlet container.
[20:14:55] <drewwills> heh... so "public class MarketplacePortletDefinition implements IPortletDefinition" suggests to me that (at least some of) this tech is an extention of other stuff in org.jasig.portal.portlet
[20:14:57] <apetro__> Marketplace is touching the portlet object model down in the database, it probably wants to surface into the portlet manager UI at some point, etc.
[20:15:09] <apetro__> Right.  That.
[20:15:27] <drewwills> sounds good
[20:35:59] *** goldmantx has quit IRC
[20:56:25] <apetro__> does `ant clean initportal` fail for anyone else against Jasig/master ( 2038450039ec40eeb1360fab2e40b18131bb9c39 )
[20:56:40] <apetro__> failed for me even after deleting the uPortal/data directory and re-starting hsql
[20:56:55] <jwennmacher> I am in process. I'll let you know shortly
[20:57:39] <jwennmacher> what's the thought on having porlets access a CDN vs. resource server URL for something common like bootstrap or fontawesome.  Except for not depending upon an external URL, what's the advantage?
[20:57:40] <apetro__> (fails in entity import, not in a compile step that Travis-CI would have currently caught)
[20:58:17] <apetro__> I'd prefer a CDN.
[20:58:29] <apetro__> (Individual opinion, not something thoroughly discussed and consensus-ified here).
[20:58:47] <apetro__> I figure if there's a reliable CDN, let's use it, and get even more cache hits!
[20:59:03] <jwennmacher> advantage with a CDN is that your desktop or tablet might have it cached already and less duplication.
[20:59:04] <apetro__> and if there's not a CDN, great, we roll our own poor-man's CDN via ResourceServingWebapp.
[20:59:11] <apetro__> Right.
[20:59:28] <jwennmacher> to me that makes sense.  I'd like to see if there are other opinions....  am I missing something??
[20:59:40] <apetro__> Some CDNs also let us reference by minor version but leave patch version unspecified, and they'll keep it up to date to latest patch, which helps keep things up-to-date.
[20:59:56] <jwennmacher> It would avoid us having to constantly release resource server with common CDN-available content
[20:59:59] <jwennmacher> as a bonus
[21:00:03] <apetro__> Yes.
[21:02:30] <jwennmacher> OK I'll email portal-dev and portlet-dev for discussion and consensus building
[21:07:32] <apetro__> cool
[21:07:42] <apetro__> how'd that ant clean initportal work for you against jasig/master ?
[21:07:51] <apetro__> I re-tested just now against a fresh checkout, still fails.
[21:07:56] <jwennmacher> looks like it failed the same as yours
[21:08:59] <jwennmacher> integrity constraint violation: foreign key no parent; FKF564C5CAC8D6888 table: UP_PORTLET_DEF
[21:09:09] <apetro__> yup
[21:09:39] <apetro__> (Locally backlogged for Product Owner consideration: enhancing Travis-CI to run `ant clean initportal` for extra surety.)
[21:10:02] <apetro__> hypotheses?
[21:10:30] <jwennmacher> was it UP-4064? Have you started looking at what introduced it?
[21:10:55] <apetro__> heh.  I was just going to suggest UP-4064, https://github.com/Jasig/uPortal/commit/f030680f1a301ce7848f56ec82578d35535735f7 , as a possible cause
[21:11:10] <apetro__> I haven't gotten anywhere in figuring out a real root cause, no, only seeing symptoms.
[21:11:54] <apetro__> but yeah, looking at stack traces, that's it
[21:12:09] <apetro__> there's going to end up being some import ordering dependency between permissions and portlet types
[21:12:40] <apetro__> and that changeset introduced that ordering dependency for the first time, since for the first time portlet *types* become a permission target, and so need to be available sooner, as in, when those permission-sets happen.
[21:13:22] <apetro__> makes one think of make-style (not Maven-style) dependency ordering detection
[21:13:28] <apetro__> maybe a multi-pass import process
[21:19:53] <apetro__> @drewwills how do we want to handle this broken jasig/master tactically?
[21:20:24] <apetro__> Revert https://github.com/Jasig/uPortal/commit/f030680f1a301ce7848f56ec82578d35535735f7 and try again later?
[21:31:45] <apetro__> (Composing the revert commit here and will propose via Pull Request in order to fix Jasig/master)
[21:37:21] <jwennmacher> verified that commit caused the issue
[21:47:21] <apetro__> I think this will revert the commit : https://github.com/Jasig/uPortal/pull/311
[21:47:29] <apetro__> Locally testing.
[21:48:21] <apetro__> Reverting it was slightly complected by the permission rename in the commit following. :)
[21:49:44] <jwennmacher> I'm just checking out the commit prior and waiting for Drew to return from lunch :-)
[22:04:44] <drewwills> apetro__ just got back from lunch
[22:05:20] <drewwills> how could the additional activity be any different from the others?
[22:08:34] <apetro__> different permission target
[22:08:41] <apetro__> the changeset introduces portlet types as a permission target
[22:09:26] <drewwills> true... just reading up on this... still loading details
[22:09:28] <apetro__> and in the details of the implementation, it eagerly initializes via a `@PostConstruct` such that the DAO will be invoked even if we're not actually referencing a portlet type identifier
[22:10:02] <drewwills> could easily switch to lazy init or jit access of types
[22:10:16] <drewwills> and I could do it now
[22:10:28] <apetro__> could
[22:10:38] <apetro__> I favor merging this: https://github.com/Jasig/uPortal/pull/311
[22:10:47] <apetro__> and then looking forward to your pull request with whatever you come up with :)
[22:17:50] *** colinclark has quit IRC
[22:26:07] *** goldmantx has joined #jasig-uportal
[22:28:09] *** goldmantx has quit IRC
[22:31:02] *** goldmantx has joined #jasig-uportal
[22:52:31] *** tlev has quit IRC
[22:53:59] *** tlev has joined #jasig-uportal
[23:07:56] <apetro__> So, now that I'm thinking about portlet-types as permission targets: what should happen when one has MANAGE permission over a portlet-definition that uses a portlet-type that one doesn't have permission to select?
[23:09:11] <apetro__> lack of permission to publish the type vetoes permission to manage the individual portlet publication, so as to avoid providing an illicit avenue to, through modification, publish a portlet of the illicit type?
[23:11:22] <drewwills> i'm open to that
[23:12:06] <drewwills> but i don't see that it _has_ to be that way
[23:12:14] <drewwills> it's only a SELECT permission
[23:13:54] <drewwills> alternatively you could block access to CONFIG mode or to setting prefs for a portlet type you can't select
[23:15:45] <drewwills> in practice, I think delegated portlet admin probably means that you create/publish/manage portlets in your own "sandbox" (e.g. category), and the only portlets in there are ones that you or someone like you created in the first place
[23:17:58] <drewwills> As I was working in this area, I noticed there is already an EntityTargetProviderImpl... at first I hoped to expand its capabilities to cover portlet types as well
[23:19:00] <drewwills> but as I dug in, I realized it means 'Entity' in the sense of things that are put into GaP, not 'Entity' in the sense of src/main/data
[23:30:15] <drewwills> okay apetro_  -- portlet type permissions targets works with initportal
[23:32:34] <apetro__> nice!  much to be said for working with initportal. ;)
[23:37:43] <drewwills> yeah i $ant initportal constantly... still not sure why a subsequent initdb worked with the issue present
[23:38:22] <apetro__> ah.  The difference between $ant clean initportal and $ant initportal , no?
[23:38:40] <apetro__> Only with the `clean` does it drop the existing data, yes?
[23:38:57] <apetro__> And only with the data dropped can one run afoul of needed data not being present in time.
[23:39:52] <apetro__> which relates to another story arc that I think will continue to need to get some love: by factoring uPortal differently it should be possible to make $ant clean initportal much, much, much faster, so that it's less painful to do it continually in development.
[23:40:24] <apetro__> Because right now it's painful.  I don't want to do it.  It's disruptive to my flow.  I sometimes comment out the unit tests so as to not wait for how long they take. It's not a great scene.
[23:41:06] <apetro__> Smaller components that build faster and only have to re-build smaller pieces in order to test the thing being worked on, I think that's going to be a fruitful avenue for build engineering.
[23:44:47] *** jsittler has quit IRC
[23:45:51] <drewwills> I don't believe 'clean' drops data... would be very surprised
[23:46:08] <drewwills> the initdb, i thought, is what does that
[23:49:21] *** goldmantx has quit IRC
[23:49:57] <apetro__> hmm, looks like you're right.  Interesting.
[23:51:52] <drewwills> certainly you can do an $ant clean deploy-ear to get all new stuff in Tomcat, w/o touching data
[23:52:25] <apetro__> right
[23:52:51] <apetro__> and it looks like the db-import-* targets are all pointed at /src/.../data/..entities/...
[23:53:11] <apetro__> rather than /target , which would make them behave potentially differently in a not-clean-ed state
[23:53:44] <apetro__> so offhand I don't have an explanation for why a not-clean-ed initportal wouldn't have tripped over the data import dependency problem.
[23:54:28] <apetro__> anyway, I've been tripped up by not-clean more generally enough times that I run 'ant clean initportal' quite frequently.  and then lose a lot of enamel to grinding my teeth waiting for it.
[23:56:18] *** drewwills1 has joined #jasig-uportal
[23:56:53] <jwennmacher> apetro couple of questions on HRS portlets.
[23:58:23] <jwennmacher> I'm looking at bootstrap-styled versions of StaffLeaveBalances and PayrollInformation (the latter also adjusted to use data tables).  I'm contemplating how best to proceed. It would be nice to have both in the existing project as user-selectable.  Thoughts?
[23:58:47] *** drewwills has quit IRC
[23:59:48] *** jsittler has joined #jasig-uportal
[23:59:57] <jwennmacher> Is Wisc wanting to move toward bootstrap styled versions?  Should we keep the older style?

   April 29, 2014  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >