[00:03:11 CDT(-0500)] * deuce (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[09:20:20 CDT(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:23:06 CDT(-0500)] * deuce_ (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[10:40:19 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[10:46:54 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[11:54:44 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[12:10:07 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[12:25:09 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[12:42:47 CDT(-0500)] * peterk (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[12:43:27 CDT(-0500)] <peterk> deuce_: I don't think it makes sense to have both ways of passing params to/from the servant portlets. We should either decide that the servant/client should be aware of the parameters that are coming from another portlet, or make it transparent. Allowing for both alternatives would just add confusion.
[12:44:07 CDT(-0500)] <peterk> Can you briefly describe why would using portlet-scoped params directly would be useful?
[12:58:07 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has left ##uportal
[13:06:02 CDT(-0500)] <deuce_> peter, for example, the permissions manager servant needs to know what owner, target and activities when utilized from the groups manager
[13:07:15 CDT(-0500)] <deuce_> and it's the web flow artifacts that are the recipients of this information and have no access to their window ids .. so they cannot access attributes set by the current ServantUtil
[13:07:38 CDT(-0500)] <deuce_> they can, however, access portlet scoped attributes in the portlet session
[13:10:54 CDT(-0500)] <peterk> you mean webflow constructs can't access information from some arbitrary static method call
[13:10:56 CDT(-0500)] <peterk> right?
[13:11:31 CDT(-0500)] <deuce_> not the ones in ServantUtil
[13:12:26 CDT(-0500)] <deuce_> they don't have direct access to the portlet session
[13:13:07 CDT(-0500)] <peterk> weird :/
[13:13:11 CDT(-0500)] <deuce_> er .. PorletRequest
[13:13:58 CDT(-0500)] <deuce_> yeah it's that abstraction that allows them to be used within a servant or portlet context i believe
[13:14:05 CDT(-0500)] <deuce_> servlet
[13:14:07 CDT(-0500)] <deuce_> 
[13:15:53 CDT(-0500)] <peterk> hmm ... on one hand, I think that we should have a consistent (i.e. a single) way of passing attributes between servants and clinets. On the other, I can picture weird problems arizing because servant overrides some param that the client doesn't expect or the other way around ...
[13:16:40 CDT(-0500)] <deuce_> instead .. perhaps we should think about how we could use controllers directly for servants
[13:17:19 CDT(-0500)] <deuce_> like ICallableController
[13:17:24 CDT(-0500)] <peterk> but they would still have to pass params to the servants somehow
[13:17:39 CDT(-0500)] <deuce_> it would be through that interface
[13:18:23 CDT(-0500)] <deuce_> the controller knows about the portlet session and can set portlet scoped attributes
[13:18:37 CDT(-0500)] <peterk> right
[13:18:45 CDT(-0500)] <peterk> except we'd have to redo controllers
[13:19:03 CDT(-0500)] <deuce_> slightly extend them yes
[13:20:33 CDT(-0500)] <peterk> well, that would be preferrable I guess. If we can't get this to work, let's change implementation to abandon attribute namespacing and use portlet scope directly
[13:20:53 CDT(-0500)] <deuce_> i think it might be more plausible to get non-spring portlets wrapped in a controller than wrapper spring portlets in the IServant
[13:21:59 CDT(-0500)] <deuce_> that's the way i currently have it working in my local env .. portlet scope only
[13:22:59 CDT(-0500)] <peterk> ok, let's do it this way for now. We'll have to revisit all this anyway when moving to jsr-286.
[13:23:18 CDT(-0500)] <deuce_> ok. sounds good.
[14:43:21 CDT(-0500)] <deuce_> hey .. what do folks think about extending our default permissions policy to include knowledge about super users? it seems like this should be centralized instead of making clients provide this logic
[14:45:16 CDT(-0500)] <andrewpetro> I'm not sure what you mean
[14:45:26 CDT(-0500)] <andrewpetro> super users should be immune to permission restrictions
[14:45:36 CDT(-0500)] <andrewpetro> for any question about whether the super user has permission to do something, the answer is yes
[14:45:50 CDT(-0500)] <deuce_> yup .. that's why we need a different policy. one that provides that immunity
[14:51:06 CDT(-0500)] <peterk> I think this shouldn't be abused. For instance, we shouldn't build administrative portlets that rely on existance of such superuser - we should follow portlet roles and configure internal permissions. Superuser access should be a last-resort thing (right up there with running sql queries against production db
[14:51:41 CDT(-0500)] <peterk> but I agree that having such an option for such permission policy would be useful
[14:53:25 CDT(-0500)] <deuce_> really? i guess reason why i'd like this is so that admin portlets don't need to be permissed out of the box. otherwise, you manually have to set all the permissions to true for the portal admin group
[14:55:03 CDT(-0500)] <andrewpetro> "I think this shouldn't be abused. For instance, we shouldn't build administrative portlets that rely on existance of such superuser - we should follow portlet roles and configure internal permissions."
[14:55:08 CDT(-0500)] <andrewpetro> Only where the portlet is actually that complicated.
[14:55:19 CDT(-0500)] <andrewpetro> there's something quite elegant about the simple case where the only permission is whether you can get to the portlet at all
[14:55:28 CDT(-0500)] <andrewpetro> and that permission is handled by portlet subscription permissions
General
Content
Integrations