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

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.

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

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

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?