Do the two views built by the security package (from DDT) define all permissions for a user? I.e. if I query the SFSUserPermissionInfo for a us_pk = 1 and pm_key = 'myPerm' and I query the SFSUserRolePermissionInfo view for us_pk = 1 and pm_key = 'myPerm', I would know for certain if the user has the 'myPerm' permission right?

I don't understand why you are trying to access the raw views.  You can get this information logically through the SecurityBasics.CurrentUser.GetPermision(...).

Because your security system doesn't do row level security. I'm having to jump through all kinds of hoops to deal with it



I have to build forms that manage this row level security, including a form that allows users to be assigned to projects and to assign the roles they will be allowed on that project. I have to determine which users are eligible for this. I'm categorizing users based on a special permission, 'AllProjectAccess'. If they have this permission, they have access to all projects and shouldn't be handled by the row security system. Otherwise, I need to deal with them. So, I have need to determine if every user in the system has this permission.



I was using a very convoluted method of getting the BO of users, loop through all the users, creating a LoggedInUser for each, checking permissions, building the criterion for an In() clause, and finally the filling my custom BO with the appropriate users. Ugly. If these views work as expected, then life is MUCH easier. Create view that is a UNION of them, then query for a user/permission and I know if they have the permission...if it works like I think it does.



So, that why

That's fine.  Rather than me trying to understand your code, just execute the views to see if you get the data you want.  The structures are explained in the documentation.  Setup a simple sceneario first so that you are not looking at a lot of data.

OK, I'll check the documentation. I must have missed it.

Greg,

 

I’m also doing my own row based security and the problem I ran into is that I couldn’t find a method that returns all the permission keys assigned to a user. CurrentUser.GetPermission('Permission-Key') only returns information about the permission key specified in the method call. In my application I add new permissions programmatically when new “record types” are created and I wanted to be able to build a select statement based on the current user’s permissions to select the rows they are permitted to access.  

 

What I ended up using is a BO based on SFSUserRolePermissionInfo and filling it with a SELECT DISTINCT pm_key FROM the BO WHERE us_pk = the current user’s pk.  This gives me a BO containing all of the user’s permission keys from which to build my select statement

 

-Larry

Thanks for the info Larry. Based on what I've seen, the SFSUserRolesPermissionInfo view only provides info about permissions granted via roles. If a permission is assigned directly to a user, then one would have to also check the SFSUserPermissionInfo view. I've create a union view with both of these. Or am I missing something here?



Sounds like you are not just setting permissions based on rows, but actually creating the permissions based on rows. That sound interesting.



Of course, as I write this, I realize that I haven't thought of everything. What if a user is assigned a role that has a GRANT on "permission1", then explicitly denied that same permission? How does SF handle that? I'm guessing that if a user is explicitly granted or denied or readonlied (if that's a word) a permission, it would override any permission set at the role level. Am I right?

The user is always the most granular level.  This is explained in the docs, but if you override a users permission, that action will be used regardless of the role.

This shouldn't be the case, it was designed to be inclusive of all permission info regardless of source.

 Please refer to Permission Hierarchy topic in the help.  User level always takes precedence over roles and if a permission is contained within multiple roles, then the highest action takes precedence.

I don't see how. The view does not reference (in the FROM clause) the SFSUsersXPermissions table, which is where users are directly assigned permissions (if I understand the schema correctly). It only references SFSUsersXRoles table, which ties users to roles.



It seems to me that the only way to get all the permissions assigned to a user is to:



1. Get permissions from SFSUserRolePermissionInfo, which will list all permissions assigned via role.

2. Resolve any permissions that are duplicated at the role level, such that only one permission finally exists with the highest action winning (grant, read-only, block in that order).

3. Get permissions from SFSUserPermissionInfo, which will list all permissions assigned directly to the user.

4. Check permissions assigned by role to see if they are overridden at the user level (change action).

5. Add any permissions assigned at user level that aren't assigned via a role.



Based on the context we are discussing here (managing user permissions/roles outside the context of the CurrentLoggedInUser), I am ignoring restriction sets, which are only applicable at runtime for the current user.



This means either a sproc or code in a BO. No simple view will cut it. As I'm learning the SF way, I'm inclined to use a BO to do this.



If I understand how things work correctly