By Greg McGuffey - 1/25/2007
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?
|
By Trent L. Taylor - 1/25/2007
I don't understand why you are trying to access the raw views. You can get this information logically through the SecurityBasics.CurrentUser.GetPermision(...).
|
By Greg McGuffey - 1/25/2007
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 
|
By Trent L. Taylor - 1/26/2007
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.
|
By Greg McGuffey - 1/26/2007
OK, I'll check the documentation. I must have missed it.
|
By Larry Caylor - 1/28/2007
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
|
By Greg McGuffey - 1/28/2007
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?
|
By Trent L. Taylor - 1/29/2007
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.
|
By Steve L. Taylor - 1/29/2007
Based on what I've seen, the SFSUserRolesPermissionInfo view only provides info about permissions granted via roles This shouldn't be the case, it was designed to be inclusive of all permission info regardless of source. 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? 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.
|
By Greg McGuffey - 1/29/2007
(regarding SFSUserRolePermissionInfo view)...This shouldn't be the case, it was designed to be inclusive of all permission info regardless of source.
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
|
By Steve L. Taylor - 1/29/2007
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.
|
By Greg McGuffey - 1/29/2007
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
|
By Greg McGuffey - 1/29/2007
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).
|
By StrataFrame Team - 1/30/2007
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.
|
By Greg McGuffey - 1/30/2007
Doh... I did miss something! 
This is going to make life easier!
Thanks!
|