Doh... I did miss something!



This is going to make life easier!



Thanks!

There are 4 solutions that are part of the StrataFrame Source Code download:

1) MicroFour StrataFrame.sln
2) MicroFour StrataFrame Security.sln (it's in this one...)
3) MicroFour StrataFrame Infragistics Wrapper.sln
4) MicroFour StrataFrame Inherited UI.sln (DevExpress wrapper)

So, when you want to get to other DLLs besides just Base, Business, DBEngine or UI, you have to open one of the other source code solutions.

Steve,



I can't find the LoggedInUser class in any of the source that I have (unless I'm missing something). Object viewer says that this class in the security DLL. Is the source for that DLL included with the SF source?



If not, could you just verify that I'm using the correct rules to figure out the final permssions (posted a few posts up).

This is what I figured out Use the two views from within code to figure out the final, flat permission list. I was about to figure this out myself, but now I'm making a b-line for LoggedInUser

Yes, the SFSUserRolePermissionInfo view does only return the roles granted to a user but it is not the only thing used to determine a user's permissions at runtime. The other view, SFSUserPermissionInfo contains the permissions assigend directly to a user.  These two views would be far to complex to combine in a SQL code so they are run separately and combinded programmatically in the LoggedInUser class.

The flat list of PermissionInfo objects is not compiled until runtime.  You can go view the source code for the LoggedInUser class to see how it is done.

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

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.

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.

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?

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