Page Comparison

[10:00:34 CST(-0600)] <EricDalquist> anyone have any thoughts on the SDF files going forward?
[10:00:53 CST(-0600)] <EricDalquist> I need to do some re-working of them in conjunction with re-working the user preferences objects
[10:00:59 CST(-0600)] <athena> awesome
[10:01:04 CST(-0600)] <EricDalquist> would there be value in moving that data from flat files into the DB?
[10:01:08 CST(-0600)] <athena> they seem confusingly out of step with the rest of our progress
[10:01:09 CST(-0600)] <athena> YES
[10:01:13 CST(-0600)] <EricDalquist> making it part of the .theme entity files?
[10:01:19 CST(-0600)] <athena> i think so
[10:01:21 CST(-0600)] <EricDalquist> ok
[10:01:26 CST(-0600)] <athena> and i think there's already a confusing amount of overlap?
[10:01:29 CST(-0600)] <EricDalquist> yeah
[10:01:30 CST(-0600)] <EricDalquist> there is
[10:01:38 CST(-0600)] <athena> course, right now the theme stuff is not JPA, right?
[10:01:39 CST(-0600)] <EricDalquist> and very very little from them is used in trunk
[10:01:51 CST(-0600)] <EricDalquist> right, so that would be part of the work if possible
[10:02:09 CST(-0600)] <athena> think we can JPA that without doing the rest of the layout stuff?
[10:02:20 CST(-0600)] <EricDalquist> I think so
[10:02:22 CST(-0600)] <EricDalquist> we'll see
[10:02:32 CST(-0600)] <athena> cool
[10:04:56 CST(-0600)] <EricDalquist> I need to write this up in the wiki but my plans for these is to allow definition of XSLT parameters and XML attributes
[10:05:08 CST(-0600)] <EricDalquist> both would have a name, default value and scope
[10:05:18 CST(-0600)] <EricDalquist> out of the box we would have request, session and persistent scopes
[10:05:41 CST(-0600)] <athena> sounds great to me
[10:05:41 CST(-0600)] <EricDalquist> so something like the activeTab would be a request scoped XSLT parameter with no default value
[10:06:15 CST(-0600)] <EricDalquist> once the data/dao side is done I'll update the request parsing code to update these based on the URL and other parameters
[10:06:29 CST(-0600)] <EricDalquist> and we should more easily be able to control where these bits come from
[10:06:58 CST(-0600)] <EricDalquist> and avoid ever overloading stuff again where one parameter is both tracked in the session and db (what happens with activeTab right now)
[10:07:12 CST(-0600)] <athena> yeah
[10:07:25 CST(-0600)] <athena> well we fixed that by creating defaultTab
[10:07:27 CST(-0600)] <athena> but still
[10:07:29 CST(-0600)] <EricDalquist> right
[10:08:32 CST(-0600)] <EricDalquist> ok good to know I'm not the only one thinking that info should be in the db
[10:08:38 CST(-0600)] <EricDalquist> I'll plan on tackling that tonight
[10:08:47 CST(-0600)] <athena> aewsome
[10:08:55 CST(-0600)] <athena> how's the jsr-286 stuff going?
[10:09:32 CST(-0600)] <EricDalquist> pretty good
[10:09:35 CST(-0600)] <EricDalquist> I think cookie support is done
[10:09:44 CST(-0600)] <EricDalquist> events still need a little work
[10:09:47 CST(-0600)] <EricDalquist> but it is URL related
[10:09:51 CST(-0600)] <EricDalquist> so I want to get this other stuff done first
[10:10:22 CST(-0600)] <athena> gotcha
[10:10:31 CST(-0600)] <EricDalquist> which will help clarify things for the event work
[10:10:36 CST(-0600)] <athena> we ever get the stuff required for etag caching to work?
[10:10:49 CST(-0600)] <EricDalquist> and that work will get CONFIG working again
[10:10:55 CST(-0600)] <athena> also, if there's anything i can help with, let me know
[10:10:59 CST(-0600)] <EricDalquist> will do
[10:11:05 CST(-0600)] <EricDalquist> I haven't even looked at the portlet caching stuff
[10:11:12 CST(-0600)] <athena> ok
[10:11:13 CST(-0600)] <EricDalquist> if you're interested in digging into that you'd be more than welcome
[10:11:22 CST(-0600)] <athena> ok - i'll see where my schedule's at
[10:11:25 CST(-0600)] <EricDalquist> ok
[14:11:06 CST(-0600)] <RickardAtWork> Is there a way to access the portlet parameters from within the portlet code? The parameters I'm referring to are "Show Portlet Window Chrome", "Use 'Alternate' Appearance" etc.
[14:12:01 CST(-0600)] <RickardAtWork> I'd like to use different appearances for my portlet depending on whether the portlet window chrome is displayed or not.
[14:12:33 CST(-0600)] <athena> not that i know of
[14:12:45 CST(-0600)] <RickardAtWork> Damn
[14:12:49 CST(-0600)] <athena> how big are the differneces? if they're not big, maybe the could be handled more easily w/ css?
[14:13:09 CST(-0600)] <RickardAtWork> Well, that was one scenario.
[14:13:16 CST(-0600)] <athena> (for the record, that's a "not that i know of" rather than a "no")
[15:54:07 CST(-0600)] <athena> so EricDalquist: if you have time, i have a few permission-y topics to get sorted out before we close a few of the trunk tickets
[15:55:42 CST(-0600)] <athena> particularly permission handling for our new REST services
[15:55:46 CST(-0600)] <athena> got any time for that this afternoon?
[15:57:08 CST(-0600)] <EricDalquist> auew
[15:57:10 CST(-0600)] <EricDalquist> sure
[15:57:12 CST(-0600)] <EricDalquist> right now is good
[15:57:27 CST(-0600)] <athena> awesome
[15:57:37 CST(-0600)] <athena> ok
[15:57:53 CST(-0600)] <athena> so for group administration i think we're in the best shape, because that system already had some permissions and we already updated them to be mostly sane
[15:58:06 CST(-0600)] <athena> i've also wrapped the group administration calls in methods and do the permissions checks
[15:58:35 CST(-0600)] <athena> it seems like that's consistent with how previous uportal services have worked? accept an IPerson object as a parameter and do the check, rather than just trusting the caller
[15:58:42 CST(-0600)] <EricDalquist> yeah
[15:58:50 CST(-0600)] <athena> ok
[15:58:54 CST(-0600)] <EricDalquist> I'm really wondering how much work it would be to start using spring-security on some of this stuff
[15:58:57 CST(-0600)] <athena> so now we have things like public void updateGroupDetails(GroupForm groupForm, IPerson updater);
[15:58:58 CST(-0600)] <EricDalquist> :/
[15:59:08 CST(-0600)] <EricDalquist> one of those questions if it is worth the pain now
[15:59:12 CST(-0600)] <athena> and canEditGroup(IPerson, String);
[15:59:15 CST(-0600)] <athena> yeah, that is a good question
[15:59:18 CST(-0600)] <athena> i can look into that a bit
[15:59:35 CST(-0600)] <EricDalquist> since they have annotations with SpringEL that let you do permission checks
[15:59:42 CST(-0600)] <athena> yeah - it's a realy nice syntax
[15:59:44 CST(-0600)] <EricDalquist> maybe not worry about using it for authN/Z yet
[15:59:48 CST(-0600)] <athena> yeah
[15:59:52 CST(-0600)] <EricDalquist> but just try to get it working on the new REST APIs
[15:59:55 CST(-0600)] <EricDalquist> and then we can go from there
[16:00:06 CST(-0600)] <athena> my guess is that's going to be hard to get in right now, to be honest
[16:00:12 CST(-0600)] <EricDalquist> yeah
[16:00:15 CST(-0600)] <athena> but i'll certainly look at it at least
[16:00:16 CST(-0600)] <EricDalquist> thats my guess too
[16:00:33 CST(-0600)] <athena> so for these methods, what do we want to do when the user can't edit the group? throw a runtimeexception?
[16:00:45 CST(-0600)] <EricDalquist> yeah
[16:00:59 CST(-0600)] <EricDalquist> some sort of PermissionDenied exception
[16:01:03 CST(-0600)] <athena> yeah
[16:01:06 CST(-0600)] <EricDalquist> not sure if we need a custom type
[16:01:11 CST(-0600)] <athena> right now we have an AuthorizationException, but it's a checked exception
[16:01:17 CST(-0600)] <EricDalquist> ah
[16:01:19 CST(-0600)] <athena> that subclasses PortalException
[16:01:24 CST(-0600)] <EricDalquist> bah
[16:01:27 CST(-0600)] <athena> so i'm guessing we don't want to use that
[16:01:29 CST(-0600)] <athena> yes, agreed
[16:01:40 CST(-0600)] <athena> thinking maybe new Runtime auth exception
[16:01:54 CST(-0600)] <athena> if we really need to that way we could attach info about what failed, but we probably don't need to?
[16:02:14 CST(-0600)] <EricDalquist> yeah
[16:02:19 CST(-0600)] <EricDalquist> just a decent message would be good
[16:02:23 CST(-0600)] <athena> ok
[16:02:25 CST(-0600)] <EricDalquist> which permission(s) they were lacking
[16:02:50 CST(-0600)] <athena> just a logged message you mean, or a message that's part of the exception object?
[16:03:03 CST(-0600)] <EricDalquist> part of the exception message
[16:03:09 CST(-0600)] <athena> ok
[16:03:09 CST(-0600)] <EricDalquist> less likely to get lost then
[16:03:11 CST(-0600)] <athena> yeah
[16:03:14 CST(-0600)] <athena> makes sense to me
[16:03:25 CST(-0600)] <athena> great - i think we're on the same page for all the group stuff
[16:03:34 CST(-0600)] <EricDalquist> sounds good
[16:03:41 CST(-0600)] <athena> so for the permissions systems, i haven't found much evidence of permissions for viewing/updating permissions
[16:04:01 CST(-0600)] <EricDalquist> I'm guessing they just assumed admin-only
[16:04:05 CST(-0600)] <EricDalquist> and left it at that
[16:04:08 CST(-0600)] <athena> yeah, that's my guess
[16:04:12 CST(-0600)] <EricDalquist> it would be good to actually have permissions defined for those
[16:04:15 CST(-0600)] <athena> yeah
[16:04:25 CST(-0600)] <athena> it'd be nice to be able to delegate permission administration
[16:04:32 CST(-0600)] <EricDalquist> yes
[16:04:33 CST(-0600)] <athena> thinking we'd need something for viewing permissions and for updating them?
[16:04:39 CST(-0600)] <athena> create/delete doesn't necessarily make sense in this context
[16:04:46 CST(-0600)] <EricDalquist> essentially as we go forward we really should define specific permissions for each action
[16:04:51 CST(-0600)] <athena> yeah
[16:04:54 CST(-0600)] <EricDalquist> so delegation can actually be implemented
[16:05:01 CST(-0600)] <EricDalquist> yup
[16:05:02 CST(-0600)] <athena> i guess the question here is what the target is in this case
[16:05:15 CST(-0600)] <athena> is the target the permission that can be set? the target it can be set on?
[16:05:24 CST(-0600)] <EricDalquist> oi
[16:05:30 CST(-0600)] <EricDalquist> that I'm not sure about
[16:05:58 CST(-0600)] <athena> i could see use cases for either "joe can set permissions on this portlet category" or "jill can set X permission"
[16:05:59 CST(-0600)] <athena> yeah
[16:06:05 CST(-0600)] <athena> in that case maybe i'll email the list
[16:06:12 CST(-0600)] <athena> i don't think our permission model supports both though
[16:06:30 CST(-0600)] <EricDalquist> yeah
[16:06:35 CST(-0600)] <athena> or maybe the permissions even need to be on the principal rather than the target?
[16:06:40 CST(-0600)] <athena> i dunno - oi, as you said
[16:07:09 CST(-0600)] <athena> if we need to we could punt temporarily by creating just a VIEW_PERMISSION and EDIT_PERMISSION permission and ignoring the target until we figure it out
[16:07:53 CST(-0600)] <EricDalquist> so that would be generic "you can view all permissions" and "you can edit all permissions"?
[16:07:58 CST(-0600)] <athena> iyeah
[16:08:01 CST(-0600)] <EricDalquist> I think an email to the list would be good
[16:08:05 CST(-0600)] <athena> yeah, i'll do that
[16:08:07 CST(-0600)] <athena> ok, next issue
[16:08:10 CST(-0600)] <athena> import/export
[16:08:19 CST(-0600)] <EricDalquist>
[16:08:26 CST(-0600)] <athena> in an ideal world the permissions for that would delegate to the permissions for actually creating/editing those objects
[16:08:31 CST(-0600)] <athena> but . . . that's not an option right now
[16:09:02 CST(-0600)] <athena> i think we need to keep that in mind for the future, but for now maybe we have some import/export-specific permissions?
[16:09:09 CST(-0600)] <EricDalquist> ok
[16:09:32 CST(-0600)] <EricDalquist> so right now we can only really permission the portlets to people
[16:09:41 CST(-0600)] <EricDalquist> but have little control over what they can and cannot import/export?
[16:09:49 CST(-0600)] <athena> well
[16:09:58 CST(-0600)] <athena> up through 3.2 we had portlets, and we could just permission them to people
[16:10:11 CST(-0600)] <athena> which entities were import/export-able was controlled w/ portlet prefs
[16:10:17 CST(-0600)] <athena> now we have a portlet that uses REST targets
[16:10:26 CST(-0600)] <EricDalquist> ah
[16:10:27 CST(-0600)] <EricDalquist> ok
[16:10:34 CST(-0600)] <EricDalquist> and so the REST targets need additional checks
[16:10:37 CST(-0600)] <athena> yeah
[16:10:38 CST(-0600)] <EricDalquist> got it
[16:10:40 CST(-0600)] <EricDalquist> hrm
[16:10:46 CST(-0600)] <athena> and i think it's better to use permission anyway
[16:11:00 CST(-0600)] <EricDalquist> yeah, then a set of import/export perms are needed
[16:11:01 CST(-0600)] <athena> that way you don't have to publish the portlet multiple times to achieve different permission configurations for different users
[16:11:08 CST(-0600)] <EricDalquist> yup
[16:11:13 CST(-0600)] <athena> thinking we could have import, export, and delete activities
[16:11:21 CST(-0600)] <athena> and have the targets be the object types?
[16:11:34 CST(-0600)] <EricDalquist> yes, I think that would work well
[16:11:43 CST(-0600)] <athena> ok, great
[16:11:56 CST(-0600)] <athena> as a nitpicky side note, we kind of need a word other than "entities" for those database types
[16:12:20 CST(-0600)] <athena> since IEntity is a real uportal thing, and not all of the things that are importable actually subclass IEntity
[16:12:25 CST(-0600)] <EricDalquist> ah right
[16:12:30 CST(-0600)] <athena> and then entitiy types themselves are importable, for extra confusion
[16:12:36 CST(-0600)] <EricDalquist> heh
[16:12:50 CST(-0600)] <athena> was also thinking about this in the context of the REST url targets, since we already have an /api/entity service that does actual IEntities
[16:12:51 CST(-0600)] <EricDalquist> Domain Objects is probably too verbose
[16:13:03 CST(-0600)] <athena> naming things isn't my strong point, i have to admit
[16:13:15 CST(-0600)] <athena> you happen to have any ideas?
[16:13:43 CST(-0600)] <athena> if not, i can poke apetro or someone else who tends to have naming opinions
[16:14:32 CST(-0600)] <lfuller>
[16:14:47 CST(-0600)] <athena> lfuller: are you that person?
[16:15:00 CST(-0600)] <lfuller> nooo... I tend to pester other people for names.
[16:15:13 CST(-0600)] <lfuller> shelley being my first stop
[16:15:19 CST(-0600)] <athena> lol
[16:15:34 CST(-0600)] <athena> yeah, i know names are important and i know i should care, but well . . .
[16:15:46 CST(-0600)] <athena> lets just say that i made apetro help me with all my jasig presentation titles and leave it at that
[16:15:53 CST(-0600)] <lfuller> lol... yeah, am more about functionality
[16:15:56 CST(-0600)] <athena> some people are better at that stuff than others, i guess
[16:15:57 CST(-0600)] <athena> ok
[16:15:57 CST(-0600)] <athena> so
[16:16:02 CST(-0600)] <athena> back to the functionality!
[16:16:44 CST(-0600)] <EricDalquist> lol
[16:16:45 CST(-0600)] <athena> the one weird side effect of using the permissions framework for determining which entities are importable, etc. is that it's not possible to turn deletion off
[16:17:09 CST(-0600)] <EricDalquist> ?
[16:17:10 CST(-0600)] <athena> in our current configuration, you have to actively reconfigure the portlet to allow you to delete <namehere> types
[16:17:16 CST(-0600)] <EricDalquist> ah
[16:17:30 CST(-0600)] <EricDalquist> well you could by removing the delete permission right?
[16:17:33 CST(-0600)] <athena> but now with our magic admin-has-all-privs feature, well, you can't say that a superadmin doesn't have a priv
[16:17:42 CST(-0600)] <athena> you can except for superadmis
[16:18:14 CST(-0600)] <EricDalquist> ah ok
[16:18:23 CST(-0600)] <EricDalquist> hrm
[16:18:29 CST(-0600)] <EricDalquist> thats a good thing to think about then
[16:18:32 CST(-0600)] <athena> yeah
[16:18:54 CST(-0600)] <EricDalquist> I wonder if we would have a way to do something like confluence's re-auth for admin
[16:19:09 CST(-0600)] <EricDalquist> without actually requiring auth since we may not have authn available in the portal
[16:19:09 CST(-0600)] <athena> dunno if we want to go back to having a configured list of "supported" <namehere> types for each operation (import, export, delete) such that it's a combination of that type being enabled, plus having the user permission
[16:20:11 CST(-0600)] <EricDalquist> hrm
[16:20:23 CST(-0600)] <EricDalquist> It really would be nice if the config was permissions only
[16:20:39 CST(-0600)] <EricDalquist> though it could be useful that delete is a big enough deal that we just fall back on portal.properties
[16:20:46 CST(-0600)] <EricDalquist> and just have a flag in there for delete in general
[16:21:16 CST(-0600)] <athena> another thing to ask the list?
[16:22:13 CST(-0600)] <EricDalquist> yeah
[16:22:16 CST(-0600)] <athena> ok
[16:22:22 CST(-0600)] <athena> i think we're through most of my list
[16:22:23 CST(-0600)] <EricDalquist> how much control over delete is needed
[16:23:01 CST(-0600)] <athena> so the final thing i have is about how we keep track of the owner and activity names
[16:23:19 CST(-0600)] <athena> historically they were either hard-coded into IPermission.java or into an IOwner class
[16:23:32 CST(-0600)] <athena> owners are just database-configured now, so we don't have per-owner java classes
[16:23:51 CST(-0600)] <athena> but we do still need to keep track of the strings that represent owners and activities
[16:24:13 CST(-0600)] <athena> guess we could
[16:24:22 CST(-0600)] <athena> 1. hard-code them into IPermission, which seems kind of sad and messy
[16:24:43 CST(-0600)] <athena> 2. hard-code them into the helper/service class for the owner, since it seems like most of them have one
[16:24:52 CST(-0600)] <athena> 3. make them configurable properties of the helper/service class
[16:24:55 CST(-0600)] <athena> 4. ?
[16:25:58 CST(-0600)] <EricDalquist> hrm
[16:26:00 CST(-0600)] <EricDalquist> O
[16:26:05 CST(-0600)] <EricDalquist> I'd lean towards 2
[16:26:15 CST(-0600)] <EricDalquist> really they are just arbitrary strings
[16:27:09 CST(-0600)] <athena> ok
[16:27:23 CST(-0600)] <athena> i have no problem with that, since it seems like that's the strategy i've accidentally been moving towards
[16:27:54 CST(-0600)] <EricDalquist> so it makes sense that the code that primarily uses them declares them
[16:28:02 CST(-0600)] <EricDalquist> that is how I do other constant declaration in uportal
[16:28:15 CST(-0600)] <EricDalquist> like IPortletRenderer has all of the portlet related constants
[16:28:22 CST(-0600)] <athena> sounds good to me
[16:28:28 CST(-0600)] <athena> i don't really seem much value in making them configurable
[16:29:29 CST(-0600)] <EricDalquist> nope
[16:29:34 CST(-0600)] <EricDalquist> that would just be asking for breakage
[16:29:39 CST(-0600)] <athena> yeah
[16:29:40 CST(-0600)] <athena> ok
[16:29:48 CST(-0600)] <athena> i think that's actually most of everything on my list
[16:30:00 CST(-0600)] <EricDalquist> great
[16:30:00 CST(-0600)] <athena> thanks for indulging the rapid-fire-questioning
[16:30:06 CST(-0600)] <EricDalquist> any time
[16:30:08 CST(-0600)] <athena> hopefully i can actually go finish some features
[16:30:11 CST(-0600)] <EricDalquist> oh I had a brain storm about refactoring layout persistence in the shower this morning (I know, getting just a little a head of myself) I have it down in a notepad so I'll try to get it into the wiki
[16:30:14 CST(-0600)] <athena> we have a bunch of stuff that's not-quite-done
[16:30:19 CST(-0600)] <EricDalquist> yes
[16:30:20 CST(-0600)] <EricDalquist> we do
[16:30:20 CST(-0600)] <athena> man
[16:30:28 CST(-0600)] <athena> i want layout persistence refactored SO BAD
[16:30:43 CST(-0600)] <EricDalquist> yeah so I'm thinking that we really don't need to persist true XML in the DB
[16:30:46 CST(-0600)] <EricDalquist> we're not doing that right now
[16:31:11 CST(-0600)] <EricDalquist> and coming up with a fairly simple LayoutNode, FolderNode extends LayoutNode, PortletNode extends LayoutNode
[16:31:12 CST(-0600)] <athena> it wouldn't suck
[16:31:22 CST(-0600)] <athena> but yeah, we probably don't have to
[16:31:27 CST(-0600)] <athena> man i wish we had multi-layout support
[16:31:32 CST(-0600)] <EricDalquist> yeah
[16:31:40 CST(-0600)] <athena> we're going to wind up wanting that pretty badly as this mobile stuff heats up
[16:31:43 CST(-0600)] <EricDalquist> fixing profile concepts would be huge as well
[16:31:44 CST(-0600)] <EricDalquist> yes
[16:31:48 CST(-0600)] <EricDalquist> we already do at madison
[16:31:57 CST(-0600)] <EricDalquist> that is the thing that is vexing our talks about a mobile rollout
[16:32:21 CST(-0600)] <athena> yeah, we've done some thinking about DLM evaluators that check the user agent string or something
[16:32:27 CST(-0600)] <athena> might work
[16:32:39 CST(-0600)] <EricDalquist> yeah
[16:32:39 CST(-0600)] <athena> alternately of course you could just deploy a whole different portal server, but that's less than ideal
[16:32:43 CST(-0600)] <EricDalquist> we've thought about the same thing
[16:32:46 CST(-0600)] <EricDalquist> we're already vhosting
[16:32:49 CST(-0600)] <athena> but yes, what we really want is multiple layouts
[16:32:58 CST(-0600)] <athena> and then!
[16:32:58 CST(-0600)] <EricDalquist> my.wisc.edu & my.wisconsin.edu are both the same server
[16:33:02 CST(-0600)] <athena> we could make them modifiable!
[16:33:12 CST(-0600)] <EricDalquist> so we'd do my.m.wisc.edu or some such
[16:33:13 CST(-0600)] <EricDalquist> yes
[16:33:16 CST(-0600)] <athena> and have happy little controls that let you drag stuff around on the mobile view!!
[16:33:23 CST(-0600)] <athena> woooo
[16:33:25 CST(-0600)] <athena> ALSO
[16:33:29 CST(-0600)] <athena> i've been playing with jQuery mobile
[16:33:36 CST(-0600)] <athena> which has fun touch eventy things
[16:33:50 CST(-0600)] <athena> so you could set a jquery handler for the on hold stuff down for a long time event
[16:34:20 CST(-0600)] <EricDalquist> neat
[16:34:23 CST(-0600)] <athena> yeah
[16:34:35 CST(-0600)] <athena> we'll have to talk about some of the weirdness in jquery mobile and how much of an issue it is for us
[16:34:38 CST(-0600)] <athena> i have mixed feelings
[16:35:24 CST(-0600)] <athena> i think the oooo-pretty-page-slide-transition is going to cause too many problems to be worth it, among other things
[16:36:15 CST(-0600)] <EricDalquist> yeah
[16:36:20 CST(-0600)] <EricDalquist> though with the new URLs it may be easier