Page Comparison

[01:05:23 EDT(-0400)] * Sememmon (~Sememmon@unaffiliated/sememmon) has joined ##uportal
[01:06:27 EDT(-0400)] * Sememmon_ (~Sememmon@ip24-56-46-252.ph.ph.cox.net) has joined ##uportal
[08:31:58 EDT(-0400)] * EricDalquist (~apollo@adsl-76-208-69-152.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:32:09 EDT(-0400)] <EricDalquist> yay: http://repo1.maven.org/maven2/org/jasig/parent/jasig-parent/
[09:47:16 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined ##uportal
[10:20:29 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[10:24:45 EDT(-0400)] * athena wishes she had the day off too because it's so niiiiiiiice out
[10:35:59 EDT(-0400)] * EricDalquist (~apollo@adsl-76-208-69-152.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[10:41:14 EDT(-0400)] <athena> hey EricDalquist - i've done some more digging into the permissions target stuff
[10:41:24 EDT(-0400)] <athena> i suspect that actually it is legal to use static strings as targets
[10:41:34 EDT(-0400)] <EricDalquist> ok
[10:41:50 EDT(-0400)] <athena> the error channel uses "DETAILS" to describe the ability to view the stack trace associated w/ an error
[10:42:14 EDT(-0400)] <athena> and that probably makes sense to be able to represent a permission granted to someone over something that isn't necessarily a group or portlet
[10:42:21 EDT(-0400)] <athena> so it seems like we have two use cases
[10:42:28 EDT(-0400)] <EricDalquist> yeah
[10:42:35 EDT(-0400)] <athena> 1. the target is some sort of IEntity, perhaps a group or a channel or a person
[10:42:56 EDT(-0400)] <athena> 2. the target is an arbitrary string specific to that permissions system
[10:43:17 EDT(-0400)] <EricDalquist> so how does the permission sentence again?
[10:43:48 EDT(-0400)] <EricDalquist> there is the target, action, and is there something else?
[10:44:03 EDT(-0400)] <EricDalquist> I just remember andrew writing out that sentence on the board
[10:44:11 EDT(-0400)] <athena> yeah
[10:44:15 EDT(-0400)] <athena> principal
[10:44:38 EDT(-0400)] <EricDalquist> so of the stack trace example
[10:44:43 EDT(-0400)] <athena> so a PRINCIPAL has permission to perform some ACTIVITY on a TARGET
[10:44:51 EDT(-0400)] <athena> i'm sure that's not the actual sentence, but it's something like that
[10:44:57 EDT(-0400)] <EricDalquist> so would something like:
[10:45:21 EDT(-0400)] <EricDalquist> "Administrators" has permission to "view stack trace" on "ErrorPortlet"
[10:45:30 EDT(-0400)] <EricDalquist> then the target is still an entity
[10:45:38 EDT(-0400)] <athena> actually
[10:45:43 EDT(-0400)] <EricDalquist> and activity is the random string
[10:46:00 EDT(-0400)] <athena> "Administrators" has permission to "view" on "stack trace" is much closer to what's actually being used
[10:46:12 EDT(-0400)] <EricDalquist> yeah
[10:46:15 EDT(-0400)] <athena> in that case, "ErrorPortlet" is actually the owning permissions system
[10:46:21 EDT(-0400)] <EricDalquist> ah
[10:46:33 EDT(-0400)] <EricDalquist> thats right. there are owners in this system too
[10:46:52 EDT(-0400)] <athena> yeah - those can kind of be thought of as categories of permissions, i guess
[10:47:22 EDT(-0400)] <EricDalquist> so "ErrorPortlet" gives "Administrators" permission "view" on "stack trace"
[10:47:49 EDT(-0400)] <EricDalquist> OWNER grants PRINCIPAL permission ACTIVITY on TARGET
[10:48:04 EDT(-0400)] <athena> yes, that sounds right
[10:48:38 EDT(-0400)] <EricDalquist> owner and principal would be entities, activity and target would be strings specific to the owner impl
[10:49:02 EDT(-0400)] <athena> the principal is an entity
[10:49:22 EDT(-0400)] <athena> not sure if the owner is
[10:49:29 EDT(-0400)] <athena> i dont' think it is
[10:49:36 EDT(-0400)] <athena> and yes, activity and target are specific to the owner impl
[10:49:53 EDT(-0400)] <athena> i suspect that in things like the announcements channel, topics were actually permission targets, though i need to double check that
[10:50:29 EDT(-0400)] <athena> so i guess that's actually a third use case where the owner defines some targets that are meaningful to it's own system - that aren't either static pre-defined strings or uportal entities
[10:50:50 EDT(-0400)] <EricDalquist> right
[10:51:01 EDT(-0400)] <athena> hmmm
[10:51:17 EDT(-0400)] <athena> that makes it really hard to have any kind of validation or help populating the targets
[10:51:26 EDT(-0400)] <EricDalquist> yeah
[10:51:34 EDT(-0400)] <EricDalquist> it does
[10:51:40 EDT(-0400)] <athena> i suppose one thing we coudl do would be to make the target provider optional
[10:52:12 EDT(-0400)] <athena> so you could provide one for the things uportal really knows about and owns - like the group and portlet management pieces
[10:52:20 EDT(-0400)] <EricDalquist> yeah, or perhaps provide an API for owners to register TargetProviders
[10:52:45 EDT(-0400)] <athena> yeah - though in that case likely the target provider code would want to be in a different web context, or maybe even a different webapp?
[10:53:08 EDT(-0400)] <EricDalquist> well I'm thinking just internal to uPortal right now
[10:53:21 EDT(-0400)] <EricDalquist> dealing with this cross-context adds a lot of complexity
[10:53:26 EDT(-0400)] <athena> yeah
[10:53:32 EDT(-0400)] <EricDalquist> though it could be done if we defined a REST api
[10:53:37 EDT(-0400)] <athena> not suggesting we actually do that just that that might be what people want
[10:53:39 EDT(-0400)] <EricDalquist> then you register your API callback
[10:53:40 EDT(-0400)] <athena> that's a good point
[10:53:43 EDT(-0400)] <athena> yeah
[10:53:54 EDT(-0400)] <athena> ok
[10:54:18 EDT(-0400)] <athena> so maybe for now we just start with ones that are internal to the portal, since likely no one's using this from other systems yet anyway, since it was all so confusing
[10:55:27 EDT(-0400)] <athena> what would we want the owner's target to look like in the database? maybe the name of a target provider that's registered in the spring context, or maybe registered by that name in a spring-wired registry/map?
[10:56:35 EDT(-0400)] <EricDalquist> hrm
[10:56:59 EDT(-0400)] <EricDalquist> I think first would be defining the TargetProvider API
[10:57:04 EDT(-0400)] <EricDalquist> and perhaps even a Target object
[10:57:33 EDT(-0400)] <EricDalquist> TargetProvider could have some basic DAO style calls
[10:57:47 EDT(-0400)] <EricDalquist> public Target getTarget(long targetId);
[10:58:17 EDT(-0400)] <EricDalquist> and then in the permissions DB you just store target keys as a combo of "owner + targetId"
[10:58:41 EDT(-0400)] <EricDalquist> then in spring, or somewhere, we have a mapping of owner -> TargetProvider
[10:58:42 EDT(-0400)] <EricDalquist> ?
[10:59:04 EDT(-0400)] <athena> well, we can't store all targets in the database, of course
[10:59:22 EDT(-0400)] <athena> there are just a couple small systems that use static strings
[10:59:56 EDT(-0400)] <athena> we'd need a mapping of owner -> TargetProvider, though at the moment we've been talking about storing owners in the database, so not sure where we want that mapping to me
[10:59:58 EDT(-0400)] <athena> er, to be
[11:03:15 EDT(-0400)] <athena> i don't think we can store targets in the database when they're things like groups or users that are provided by a group store external to the portal
[11:04:38 EDT(-0400)] <EricDalquist> then how are they tracked?
[11:05:10 EDT(-0400)] <athena> the permissions system stores the entity key as the target
[11:05:37 EDT(-0400)] <athena> and the IPermissible system does things like call the group API to get a list of all groups
[11:06:13 EDT(-0400)] <athena> and then sends the array of entity keys for all those groups back as the array of valid target keys
[11:06:31 EDT(-0400)] <EricDalquist> ok
[11:07:02 EDT(-0400)] <EricDalquist> I guess I'm a bit confused
[11:07:19 EDT(-0400)] <EricDalquist> so what is the plan for the new version then? Wouldn't it need to do something similar?
[11:08:31 EDT(-0400)] <athena> yep
[11:08:39 EDT(-0400)] <athena> ok
[11:08:45 EDT(-0400)] <athena> so right now there's this API called IPermissible
[11:09:10 EDT(-0400)] <athena> http://developer.jasig.org/projects/uportal/3.3.0-SNAPSHOT/uportal-impl/apidocs/org/jasig/portal/IPermissible.html
[11:09:25 EDT(-0400)] <athena> generally IChannels actually implement it
[11:09:31 EDT(-0400)] <athena> or have a class that does
[11:09:42 EDT(-0400)] <athena> so CGroupsManager implements IPermissible, for example
[11:10:01 EDT(-0400)] <athena> in the case of CGroupsManager, the owner name and token, and the set of activity names and tokens are all hard-coded
[11:10:39 EDT(-0400)] <athena> since that information is known in advance, and permission assignments reference those activity strings, it seems like it would make sense to move that stuff from code into the database
[11:11:19 EDT(-0400)] <athena> that also gives us a way to allow uportal implementers to add new owner systems for portlets if they need to as they migrate away from channels
[11:11:27 EDT(-0400)] <athena> the only thing that isn't known in advance is the set of targets
[11:11:42 EDT(-0400)] <EricDalquist> ok
[11:11:48 EDT(-0400)] <athena> it seems like we probably need the target provider to be a spring-wired service
[11:12:03 EDT(-0400)] <athena> perhaps we could have one implementation that does actually store its static strings to the database
[11:12:20 EDT(-0400)] <athena> and another that can be configured to send back lists of IEntity keys as targets?
[11:12:38 EDT(-0400)] <EricDalquist> yeah
[11:12:39 EDT(-0400)] <athena> and then allow people to implement that API to do whatever else they need to do
[11:13:20 EDT(-0400)] <athena> so i guess if we decide that all makes sense, we just need to make sure that the database-serialized IPermissionOwner object is capable of knowing what it's TargetProvider is, and is able to return some kind of usable handle to it
[11:13:43 EDT(-0400)] <athena> do we currently have other places in uportal where the database returns something that's turned into a spring-wired object?
[11:14:17 EDT(-0400)] <EricDalquist> nope
[11:14:38 EDT(-0400)] <EricDalquist> my only idea there is to have a TargetProviderRegistry which would really be a glorified Map
[11:14:53 EDT(-0400)] <athena> ok, i was hoping something like that wouldn't be unreasonable
[11:14:56 EDT(-0400)] <EricDalquist> and the DB just stores a fname style name for the TargetProvider
[11:15:00 EDT(-0400)] <athena> great
[11:15:18 EDT(-0400)] <athena> so we just save a target provider key name, and then the code goes and looks up that key in the spring-wired TargetProviderRegistry
[11:15:44 EDT(-0400)] <EricDalquist> yup
[11:15:55 EDT(-0400)] <athena> i think that'll also make life easier when we someday start moving away from static code
[11:16:35 EDT(-0400)] <EricDalquist> yup
[11:17:07 EDT(-0400)] <athena> cool
[11:17:10 EDT(-0400)] <athena> thanks for the discussion
[11:17:16 EDT(-0400)] <athena> i think it's helpful to talk through this stuff
[11:17:31 EDT(-0400)] <EricDalquist> yup
[11:17:52 EDT(-0400)] <EricDalquist> oh, once ehcache releases version 2.0.1 to fix their caching filter I'll be doing a new resource manager release
[11:17:56 EDT(-0400)] <athena> i'm thinking i'd like to type up a summary of not just this, but what we think the original intentions of the permissions system was and how we've modified its behavior in 3.1 and 3.2
[11:18:00 EDT(-0400)] <athena> oh! fantastic
[11:18:01 EDT(-0400)] <EricDalquist> and this one should be able to make it into the central maven repo
[11:18:36 EDT(-0400)] <athena> awesome!
[11:18:40 EDT(-0400)] <athena> very exciting
[11:18:56 EDT(-0400)] <athena> i thought the link you sent about that other aggregation project was really interesting - would like to try it out
[11:19:11 EDT(-0400)] <EricDalquist> yeah
[11:19:21 EDT(-0400)] <EricDalquist> Something on the todo list
[11:19:33 EDT(-0400)] <EricDalquist> it looks like just where we were going with the aggregation tool in 3.2
[11:19:53 EDT(-0400)] <athena> yeah, definitely
[11:20:00 EDT(-0400)] * lfuller (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[11:20:11 EDT(-0400)] <athena> and what we have now doesn't really help as much w/ JSP-based portelts, so it seems like something to look at
[11:20:16 EDT(-0400)] <EricDalquist> yup
[11:20:17 EDT(-0400)] <athena> does that project seem relatively well-maintained?
[11:20:22 EDT(-0400)] <EricDalquist> I think so
[11:20:30 EDT(-0400)] <EricDalquist> I didn't look into it in great detail
[11:21:21 EDT(-0400)] <athena>
[11:21:29 EDT(-0400)] <athena> i like using other people's code
[11:21:33 EDT(-0400)] <EricDalquist> me too
[11:22:18 EDT(-0400)] <athena> good to just concentrate on what you're really tryign to get done
[11:22:32 EDT(-0400)] <EricDalquist> yeah
[11:22:58 EDT(-0400)] <EricDalquist> oi … some of the changes that were made to pluto for 2.0 are … weird
[11:23:12 EDT(-0400)] <EricDalquist> it looks like I'm going to be helping do a bunch of refactoring for pluto 2.1
[11:24:32 EDT(-0400)] <athena> too bad they have weirdness, though i'm glad you're involved enough to help make it go away
[11:25:05 EDT(-0400)] <EricDalquist> yeah
[11:25:22 EDT(-0400)] <EricDalquist> so a lot of it is because the primary devs for the 2.0 release were from jetspeed
[11:25:32 EDT(-0400)] <EricDalquist> which does lots of things in a very different way
[11:25:41 EDT(-0400)] <EricDalquist> and there are a lot of good changes
[11:25:47 EDT(-0400)] <EricDalquist> but a few things that need some cleanup
[11:27:06 EDT(-0400)] <athena> ah, gotcha
[11:27:13 EDT(-0400)] <athena> so is it looking pretty good on the whole?
[11:27:23 EDT(-0400)] <EricDalquist> yeah, I think so
[11:27:26 EDT(-0400)] <athena> last time we'd talked i think we weren't sure how complete the impleemntation was
[11:27:28 EDT(-0400)] <athena> that's good
[12:44:33 EDT(-0400)] <athena> EricDalquist: do we have a convention yet for auto-wiring beans that require something that needs to be explicitly defined in the spring xml?
[12:44:56 EDT(-0400)] <EricDalquist> that should 'just work'
[12:44:58 EDT(-0400)] <athena> do we want to just wire the requirement in with @Resource or would it be better to just define that bean in the spring xml as well?
[12:45:18 EDT(-0400)] <EricDalquist> if there are multiple beans of one type use @Qualifier
[12:45:25 EDT(-0400)] <athena> just wanted to make sure that using @Resource wasn't going to create any confusion
[12:45:28 EDT(-0400)] <athena> hm
[12:45:42 EDT(-0400)] <athena> this will be a map, i think
[12:45:58 EDT(-0400)] <athena> can we use @Qualifier for those, or does it need to be the Resource annotation?
[12:46:00 EDT(-0400)] <EricDalquist> I think @Qualifier and <qualifier> will work
[12:46:16 EDT(-0400)] <EricDalquist> I've heard @Resource can cause problems if you ever run in a real J2EE container
[12:46:23 EDT(-0400)] <EricDalquist> since that changes the behavior of those annotations
[12:46:31 EDT(-0400)] <athena> oh, interesting
[12:46:34 EDT(-0400)] <athena> i hadn't heard that
[12:46:38 EDT(-0400)] <athena> i'll go the qualifier route then
[12:46:49 EDT(-0400)] <athena> so you can use that w/ maps w/o issue?
[12:46:55 EDT(-0400)] <EricDalquist> I would assume so
[12:47:41 EDT(-0400)] <athena> ok
[12:47:43 EDT(-0400)] <athena> i'll try it out
[12:48:34 EDT(-0400)] * Sememmon (~Sememmon@unaffiliated/sememmon) has joined ##uportal
[12:57:21 EDT(-0400)] <athena> looks like spring does recommend using @Resource for injecting a specific bean by ID
[12:57:21 EDT(-0400)] <athena> http://jira.springframework.org/browse/SPR-4492
[12:57:30 EDT(-0400)] <EricDalquist> huh, ok
[12:57:34 EDT(-0400)] <EricDalquist> lets go with that then
[13:01:27 EDT(-0400)] <athena> ok
[13:19:44 EDT(-0400)] <EricDalquist> doing uportal dev with autowiring is so much nicer
[13:19:58 EDT(-0400)] <EricDalquist> not having to hunt down the right place in XML to edit
[13:20:05 EDT(-0400)] <EricDalquist> just add @Autowired to my stter
[13:20:49 EDT(-0400)] <athena> yeah, it really is
[13:41:14 EDT(-0400)] <athena> hoping i'm close to having something i can play w/ and see if it works reasonably well
[13:42:06 EDT(-0400)] <athena> i worry a little bit about iterating through every single child of the Everyone group
[13:42:12 EDT(-0400)] <athena> but it seems like the code did that to begin w/
[13:42:23 EDT(-0400)] <athena> just seems like it'd be bad when you have 100K users
[13:42:23 EDT(-0400)] <EricDalquist> yeah
[13:42:35 EDT(-0400)] <EricDalquist> well that is why we have that pags.everyone sub-group
[13:42:52 EDT(-0400)] <EricDalquist> there was actually a bug a while back where out of the box users were getting added directly under Everyone
[13:43:06 EDT(-0400)] <EricDalquist> and it caused groups related things to hang because of that issue
[13:44:14 EDT(-0400)] <athena> i dunno, i'm not sure that would matter for this logic
[13:44:15 EDT(-0400)] <athena> c
[13:44:22 EDT(-0400)] <athena> take a look at the init method: https://www.ja-sig.org/svn/uPortal/tags/rel-3-2-1-GA/uportal-impl/src/main/java/org/jasig/portal/channels/groupsmanager/CGroupsManager.java
[13:44:41 EDT(-0400)] <athena> it looks to me like it iterates through every single member and submember of the Everyone group?
[13:45:02 EDT(-0400)] <athena> though it doesn't do anything expensive for each
[13:45:40 EDT(-0400)] <EricDalquist> wow neat
[13:45:42 EDT(-0400)] <EricDalquist> yeah
[13:45:49 EDT(-0400)] <EricDalquist> thats a little crazy
[13:45:52 EDT(-0400)] <athena> guess only once at portal startup time
[13:46:00 EDT(-0400)] <EricDalquist> yeah ...
[13:46:07 EDT(-0400)] <athena> which also seems like a problem
[13:46:23 EDT(-0400)] <athena> since i don't see how that would pick up any changes to the groups hierarchy
[13:46:30 EDT(-0400)] <EricDalquist> yeah
[13:47:43 EDT(-0400)] <athena> i'm not really sure how to get around that, either
[13:48:00 EDT(-0400)] <athena> unless we come up w/ some target provider API that doesn't provide a full list of targets
[13:48:04 EDT(-0400)] <athena> maybe just validates them
[13:48:19 EDT(-0400)] <EricDalquist> yeah
[13:48:24 EDT(-0400)] <athena> suppose we could have an interface that validates targets, and a subinterface that also provides the list
[13:48:41 EDT(-0400)] <athena> the static string one could implement the subinterface and the group evilness one could just decline to implement that
[13:48:42 EDT(-0400)] <EricDalquist> perhaps the API can have result set size limiting built in
[13:49:05 EDT(-0400)] <EricDalquist> Set<Target> getMatchingTargets(String search, int limit)
[13:49:18 EDT(-0400)] <athena> yeah, that would make sense
[13:49:24 EDT(-0400)] <EricDalquist> that at least gives you the auto-complete capabilities
[13:49:29 EDT(-0400)] <athena> yep
[13:50:00 EDT(-0400)] <athena> though to be honest, i don't think we necessarily need the groups target provider to provide a list of valid targets, since we'll probably just delegate the whole interface for that to the existing groups selector
[13:50:10 EDT(-0400)] <EricDalquist> yeah
[13:52:05 EDT(-0400)] <athena> well, i feel like we're making progress at least
[13:52:14 EDT(-0400)] <athena> will be good to clean up and document these parts of uportal
[13:52:34 EDT(-0400)] <athena> and really, the permissions system has the potential to be interesting and powerful - it's just been buried behind a crappy UI for too long
[13:52:42 EDT(-0400)] <EricDalquist> yup
[13:56:44 EDT(-0400)] <athena> wonder if target providers should be associated w/ the owner or the activity
[13:57:01 EDT(-0400)] <EricDalquist> probably
[13:57:04 EDT(-0400)] <athena> it seems conceivable that two different activities under the same system might relate to different sets of targets
[13:57:15 EDT(-0400)] <EricDalquist> hrm
[13:57:31 EDT(-0400)] <EricDalquist> well maybe the TargetProvider API needs to include the activity that it is getting the target for
[13:57:58 EDT(-0400)] <athena> or instead of associating a targetprovider w/ an owner, we just associate it one level down w/ the activity
[13:58:33 EDT(-0400)] <athena> seems reasonable that some system might have a named permission that's targeted to users, and another one that's associated w/ a static string
[13:58:35 EDT(-0400)] <EricDalquist> yeah
[13:58:45 EDT(-0400)] <EricDalquist> that would work
[13:58:57 EDT(-0400)] <athena> that'd be a pretty simple change
[14:00:07 EDT(-0400)] <EricDalquist> yup
[14:02:51 EDT(-0400)] <EricDalquist> brb
[14:12:31 EDT(-0400)] * EricDalquist (~apollo@adsl-76-208-69-152.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[14:30:08 EDT(-0400)] <athena> ergh i can't figure out why spring's not populating this resource annotation
[14:30:31 EDT(-0400)] <EricDalquist>
[14:30:57 EDT(-0400)] <EricDalquist> you can always just move the whole mean into xml
[14:32:07 EDT(-0400)] <athena> yeah, guess maybe i'll just do that for now and troubleshoot it later
[16:05:23 EDT(-0400)] <athena> any idea what UP_SECURE_INFO_CHAN is supposed to be?
[16:05:39 EDT(-0400)] <EricDalquist> no
[16:05:44 EDT(-0400)] <athena> weird
[16:05:51 EDT(-0400)] <EricDalquist> no mentions in the source?
[16:11:00 EDT(-0400)] <athena> eh, trying to even find the source
[16:11:05 EDT(-0400)] <athena> going back through the history of the data.xml file
[16:11:20 EDT(-0400)] <EricDalquist> I'm doing a " find . -type f | xargs grep UP_SECURE_INFO_CHAN"
[16:11:24 EDT(-0400)] <EricDalquist> nothing interesting yet
[16:11:27 EDT(-0400)] <EricDalquist> other than the entity file
[16:11:42 EDT(-0400)] <athena> weird
[16:11:52 EDT(-0400)] <athena> maybe it's just an orphaned permission
[16:11:54 EDT(-0400)] <EricDalquist> still searching though
[16:11:58 EDT(-0400)] <EricDalquist> but that would be my guess
[16:11:58 EDT(-0400)] <athena> or maybe the owner is just unregistered
[16:12:09 EDT(-0400)] <EricDalquist> I even have 2.5 and 2.6 source checked out
[16:12:12 EDT(-0400)] <EricDalquist> nothing from them
[16:12:19 EDT(-0400)] <EricDalquist> other than the data.xml entries
[16:12:25 EDT(-0400)] <athena> i think the owners are only used for the permissions manager UI, some permissions wound up getting created w/ bogus owners
[16:12:28 EDT(-0400)] <athena> like "system"
[16:12:33 EDT(-0400)] <athena> which is not actually a registered owner
[16:13:29 EDT(-0400)] <athena> similarly we have permission names that aren't activities that can be provided by any owner
[16:13:40 EDT(-0400)] <athena> same thing for targets
[16:14:58 EDT(-0400)] <EricDalquist> yeah nothing from my search
[16:15:00 EDT(-0400)] <athena> yeah i can't find any use for that one
[16:15:02 EDT(-0400)] <EricDalquist> must be orphaned
[16:15:06 EDT(-0400)] <EricDalquist> from long ago
[16:15:11 EDT(-0400)] <athena> will be good to get this cleaned up
[16:15:35 EDT(-0400)] <athena> i'm tempted to just delete the account manager permission for now
[16:15:44 EDT(-0400)] <athena> the channel's gone, and we'll need to write a new portlet
[16:16:09 EDT(-0400)] <athena> if we want someone to be able to administer all portal users, we can just leave it so that you only grant permission to the portlet to people you want to admin users
[16:16:19 EDT(-0400)] <EricDalquist> yup
[16:16:23 EDT(-0400)] <EricDalquist> i think that sounds sane
[16:16:23 EDT(-0400)] <athena> and if we want to introduce group-specific user administration, that can't be accomplished by a single string anyway
[16:16:33 EDT(-0400)] <athena> so it's kind of a pointless permission
[16:17:30 EDT(-0400)] <athena> so i guess permission activity fnames should probably be unique system-wide?
[16:17:39 EDT(-0400)] <athena> i think right now they're just unique within a permission owner
[16:17:49 EDT(-0400)] <athena> which i guess makes sense if it's something like "VIEW"
[16:18:38 EDT(-0400)] <EricDalquist> hrm
[16:18:56 EDT(-0400)] <EricDalquist> I'm not sure, brain is too fried by pluto
[16:19:14 EDT(-0400)] <athena> lol it's ok
[16:19:26 EDT(-0400)] <athena> hmm, think i might have found a bug in i/o for permission sets
[16:19:29 EDT(-0400)] <athena> will have to ping drew about that