uPortal IRC Logs-2012-08-04

[14:33:12 CDT(-0500)] <dmccallum54> ok what's the secret sauce to grant local user creation permissions

[14:33:29 CDT(-0500)] <dmccallum54> guessing my target string is incorrect

[14:33:37 CDT(-0500)] <dmccallum54> tried Everyone and ALL

[14:33:43 CDT(-0500)] <dmccallum54> but still get....

[14:34:14 CDT(-0500)]

<dmccallum54> Caused by: java.lang.RuntimeException: Current user

Unknown macro: {current.user.name}

does not have permissions to update person

Unknown macro: {new.user.name}

[14:41:16 CDT(-0500)] <dmccallum54> i stepped through the code in a debugger and see the EDIT_USER permission being checked in AnyUnblockedGrantPermissionPolicy.doesPrincipalHavePermission()

[14:41:52 CDT(-0500)] <dmccallum54> but there's no logic that seems to fall back to checking for targets intended as wildcards, like "ALL", so the user create attempt fails

[14:42:01 CDT(-0500)] <dmccallum54> so i'm clearly missing something...

[14:50:10 CDT(-0500)] <dmccallum54> I see the check for wildcarded group targets

[14:50:16 CDT(-0500)] <dmccallum54> but the new username doesn't resolve to a group

[14:50:22 CDT(-0500)] <dmccallum54> so that check doesn't run

[19:41:19 CDT(-0500)] <athena> dmccallum54: it depends on how you're setting the permission. if it's in code or via an ajax api, the target is likely the principal id of the person or group (something like local.0 for Everyone). if it's in import/export, there's logic to automatically resolve names like "Everyone" to the appropriate principal

[19:41:41 CDT(-0500)] <athena> also most systems don't use wildcards and i'd recommend avoiding them where possible

[19:42:02 CDT(-0500)] <athena> but permission inherit - so assign to Everyone, and all members of Everyone get the permission (which under normal circumstances means all users)

[19:42:19 CDT(-0500)] <athena> if you want to assign things manually you can use the permission admin portlet

[19:42:54 CDT(-0500)] <athena> also you may need both EDIT_USER and EDIT_USER_ATTRIBUTE permissions, and those permissions could use some improvement

[19:43:06 CDT(-0500)] <athena> happy to discuss exactly what the limitations are next week

[21:54:37 CDT(-0500)] <dmccallum54> athena thx. are you saying there is no OOTB way to set perms either via UI or import so that users in a given group can create a new local user?

[21:55:49 CDT(-0500)] <dmccallum54> from what i see in the debugger, my issue isn't with wildcarding the principal, it's with wildcarding the target b/c the target seems to be the username of the to-be-created user, which of course can't be known ahead of time

[22:52:32 CDT(-0500)] <athena> dmccallum54: sorry, in and out (smile) but permissions on targets are inherited, and uportal isn't really generally designed for wildcards

[22:52:45 CDT(-0500)] <athena> however, i think in this case the target you want is the magic one-off permission SELF

[22:52:59 CDT(-0500)] <athena> which is sort of really only supported by the user managed portlet, maybe

[22:53:09 CDT(-0500)] <athena> errr

[22:53:10 CDT(-0500)] <athena> ok

[22:54:36 CDT(-0500)] <athena> so i think what you want is to create edit permissions such that whoever the creating group is can edit users in general

[22:54:46 CDT(-0500)] <athena> or add some custom logic to add new users to a group that the editors have permission over

[23:21:34 CDT(-0500)] <dmccallum54> athena thx. will have a look tomorrow or mon.

[23:23:05 CDT(-0500)] <dmccallum54> you're saying SELF isn't likely to actually work? i believe it is the user manager portlet i'm trying to use to create users

[23:23:21 CDT(-0500)] <athena> no i realized you weren't actually asking about users editing themselves, i think

[23:23:28 CDT(-0500)] <dmccallum54> right

[23:23:38 CDT(-0500)] <athena> so you probably need EDIT_USER and EDIT_USER_ATTRIBUTE

[23:23:49 CDT(-0500)] <dmccallum54> it's blowing up on EDIT_USER

[23:23:50 CDT(-0500)] <athena> oh you know . . .

[23:23:57 CDT(-0500)] <athena> i think i see what you're talking about

[23:24:00 CDT(-0500)] <athena> you create user

[23:24:07 CDT(-0500)] <athena> but even if you have permissions on everyone

[23:24:11 CDT(-0500)] <athena> they're not in that group yet

[23:24:18 CDT(-0500)] <dmccallum54> apparently not

[23:24:20 CDT(-0500)] <athena> yeah.

[23:24:22 CDT(-0500)]

<dmccallum54> the target is

Unknown macro: {username}

[23:24:35 CDT(-0500)] <dmccallum54> and the attempt to resolve that principal to a group returns no results

[23:24:36 CDT(-0500)] <athena> ok, this all makes sense

[23:24:39 CDT(-0500)] <dmccallum54> ok (smile)

[23:24:55 CDT(-0500)] <athena> so one thing we could do is add a group selection UI to the workflow

[23:25:02 CDT(-0500)] <dmccallum54> well

[23:25:10 CDT(-0500)] <athena> and then you select a group to put the user into to start with and it checks those permissions

[23:25:23 CDT(-0500)] <dmccallum54> this is for a monday afternoon or tuesday morning SSP training

[23:25:30 CDT(-0500)] <athena> which is consistent with how how the portlet admin portlet works, but probably not really what you want

[23:25:31 CDT(-0500)] <athena> ah.

[23:25:44 CDT(-0500)] <athena> so . . . for now can you just make people admins? or is that not going to fly?

[23:25:50 CDT(-0500)] <dmccallum54> so if it's gunna involve a code change it either wont happen or it'll be super ugly

[23:26:03 CDT(-0500)] <dmccallum54> i can definitely ask if that's acceptable (making people admins)

[23:26:14 CDT(-0500)] <athena> particularly if it's just for training that might be a quick fix

[23:26:24 CDT(-0500)] <athena> but we should certainly fix the overall use case

[23:26:55 CDT(-0500)] <dmccallum54> alright. i wash my hands of this for today. thanks once again. very appreciated.

[23:27:10 CDT(-0500)] <athena> happy to help, and hope we can sort this out better in the long run

[23:32:02 CDT(-0500)] <dmccallum54> wrote patty to see if we really truly even need this for the training

[23:32:17 CDT(-0500)] <dmccallum54> i have a sneaking suspicion it's not a legit use case

[23:32:40 CDT(-0500)] <athena> in theory the uportal admin tools should support delegated administration use cases

[23:32:57 CDT(-0500)] <athena> but 1 - the user administration portlet isn't finished yet (ongoing coop dev effort)

[23:33:21 CDT(-0500)] <athena> and 2 - no one in the community has articulated a lot of coherent use cases or done testing

[23:33:44 CDT(-0500)] <athena> so actually if you want to use this and declare what you'd like the functionality to be . . . (smile)

[23:34:18 CDT(-0500)] <athena> i think it's actually terrific to have alternate packages like umobile and SSP that bring additional communities and use cases to the table

[23:34:22 CDT(-0500)] <athena> should make the code more flexible