...
[11:51:17 CDT(-0500)] <EricDalquist> ok
[11:51:31 CDT(-0500)] <EricDalquist> just use the xslt isMemberOf tags to hide the ui features?
[11:51:44 CDT(-0500)] <drewwills> i don't think it's much trouble really
[11:52:15 CDT(-0500)] <drewwills> i was looking at adding upAuth:hasPermission(owner,activity[,target])
[11:52:40 CDT(-0500)] <EricDalquist> ah yeah
[11:52:42 CDT(-0500)] <EricDalquist> that would work
[11:52:50 CDT(-0500)] <EricDalquist> and more flexible than group based
[11:52:57 CDT(-0500)] <drewwills> extensible too, should we need it
[11:53:00 CDT(-0500)] <drewwills> yeah
[11:53:22 CDT(-0500)] <drewwills> the one thing I wonder about atm...
[11:53:49 CDT(-0500)] <drewwills> should I make 1 perm for access to the "Customize" widget, or 4-6 for access to the different elements within it
[11:53:59 CDT(-0500)] <EricDalquist> hrm
[11:54:07 CDT(-0500)] <drewwills> and then if you don't have access to any, disable it all together
[11:54:31 CDT(-0500)] <EricDalquist> can we do "super" permissions?
[11:54:38 CDT(-0500)] <drewwills> i'm leaning toward the former... because there is already perm infrastructure for what you can do to fragments
[11:54:43 CDT(-0500)] <EricDalquist> like permission X grants you permissions A, B, & C?
[11:55:24 CDT(-0500)] <drewwills> i believe we could do something like that... though it might not be completely transparent in the perm manager
[11:56:00 CDT(-0500)] <EricDalquist> yeah
[11:56:05 CDT(-0500)] <EricDalquist> maybe just one permission for now
[11:56:12 CDT(-0500)] <EricDalquist> it would be easy enough to build it out more if needed later
[11:56:18 CDT(-0500)] <drewwills> i'm starting with the most obvious... single permission to add a tab
[11:56:31 CDT(-0500)] <drewwills> yeah, sounds like a good perspective
[11:57:16 CDT(-0500)] <drewwills> this is not the first time this item has come up... this feature will be very valuable for ssp and anything of that kind
[15:07:55 CDT(-0500)] <jwennmacher> EricDalquist: I'm continuing looking at the refUrl business. Drew had an idea that I might be able to load up a SYSTEM_USER account and run through the url syntax provider, then do the same as the current (guest) user and compare those urls (might need to disregard certain items). Does that seem like that approach would be reasonable to you?
[15:08:24 CDT(-0500)] <EricDalquist> perhaps
[15:08:48 CDT(-0500)] <EricDalquist> I'm not sure how that would actually work but if it does that sounds good
[15:08:53 CDT(-0500)] <EricDalquist> again great care will be needed
[15:09:05 CDT(-0500)] <EricDalquist> to amke sure some error doesn';t result in someone with SYSTEM_USER permissions
[15:09:12 CDT(-0500)] <jwennmacher> I have to look into a few things. I need to verify I can create and destroy session
[15:09:31 CDT(-0500)] <jwennmacher> yeah. There are attributes that look like they might be stored in request as well.
[15:11:20 CDT(-0500)] <EricDalquist> yeah
[15:31:05 CDT(-0500)] <jwennmacher> EricDalquist: As a comparison between the two approach es I started to look into where the permission checks are in the areas you mentioned ... portlet definition, entity, and window registry. By entity do you mean PortletEntityRegistryImpl? For window registry I identified PortletWindowRegistryImpl. I'm not sure where the impact is with portlet definition. I'm assuming you mean whether the user has permissions to view
[15:31:21 CDT(-0500)] <EricDalquist> correct
[15:31:39 CDT(-0500)] <jwennmacher> So it's these two classes or is there a third?
[15:31:57 CDT(-0500)] <EricDalquist> there should be a PortletDefinitionRegistryImpl as well
[15:34:56 CDT(-0500)] <jwennmacher> Not sure how I see the user playing in that
[15:35:02 CDT(-0500)] <jwennmacher> in that class
[15:36:05 CDT(-0500)] <EricDalquist> hrm
[15:36:08 CDT(-0500)] <EricDalquist> must not be in there
[15:36:15 CDT(-0500)] <EricDalquist> like I said I can't remember all of it ...
[15:36:42 CDT(-0500)] <EricDalquist> but somewhere in that whole registry side I believe the "can a user view the portlet" permission checking is happening
[15:36:54 CDT(-0500)] <jwennmacher> ok
[15:38:28 CDT(-0500)] <jwennmacher> thanks. I think I have a very high level understanding, but there's a lot of code in that sequence I don't have a full understanding of at this point.
[15:38:43 CDT(-0500)] <EricDalquist> yeah
[15:38:49 CDT(-0500)] <jwennmacher> making my head spin ... 
[15:38:58 CDT(-0500)] <EricDalquist> there is A LOT of complexity in there
[15:39:07 CDT(-0500)] <EricDalquist> just because so much work gets done incrimentally
[15:39:17 CDT(-0500)] <EricDalquist> so what shouldn't in theory be tyhat complex of a system
[15:39:26 CDT(-0500)] <EricDalquist> ends up being very complex due to legacy API overhead