By Philipp Guntermann - 7/27/2008
Is there a simple way to access the rules assigned to a specified user ?this is what i got so far: ISecurityUser U = MicroFour.StrataFrame.Security.SecurityBasics.CurrentUser;MicroFour.StrataFrame.Security.BusinessObjects. SFSRolesBO RolesBO = new MicroFour.StrataFrame.Security.BusinessObjects.SFSRolesBO();RolesBO.FillAllByUser(U.UserPK); .. thanks 
|
By Greg McGuffey - 7/28/2008
I'm not sure what you mean by "rule". Essentially, the RBS system works via permissions (and restrictions). The easiest way to review a permission for a user is using the GetPermission() method on the CurrentUser. However, this won't tell you all their permissions, just permission for a specific key. To get all their permissions, you'd likely need to loop through the SFSPermissionsBO and call GetPermission() for each one on the current user.
SFSPermissionsBO permBO = new SFSPermissionsBO();
permBO.FillAll(0); // Or use the most appropriate fill method for your needs
foreach (DataRow row in permBO.Rows)
{
// Get permission key
String key = row.pm_key;
// See what permission user has
PermissionInfo permInfo = SecurityBasics.CurrentUser.GetPermission(key)
// Do something with it...
}
There are some fill methods that take a user ID, so those might be more appropriate, but I'm not sure...I haven't used them yet.
However, if you are just interested in roles, you are heading the right way.
|
By Philipp Guntermann - 7/28/2008
hi,sorry i meant "Role(s)" off course instead of "rule"  i allready have code in place to read the permissions, but it would be nice to read the roles of a user aswell without having to assign some permission key to each role for identification.
|
By Greg McGuffey - 7/29/2008
To get the roles, the code you originally posted will work nicely, I'd think.
However, I'm a bit confused about this statement:
...but it would be nice to read the roles of a user as well without having to assign some permission key to each role for identification.
This seems to suggest that you are conceptualizing that roles should be used to determine access to some feature in your application. This is not the case. Permissions are intended to be used to control access. This makes sense once you work it out. Permissions have an action (GRANT, READONLY, DENY) that determine access, while roles are simply containers for permissions. Thus the permission determines what access, while the role simply allows a set of permissions to be assigned to a user at once. Also, since multiple roles might use the same permission, with conflicting actions (i.e. one role might have an action of GRANT for a permission and another the action of DENY) AND the user might be directly assigned a permission, the SF RBS enforces the rules related to this (see help for more details). The GetPermission() method sorts all that out and returns the final verdict for any permission. In code, or via the SecurityKey setting in forms or BOs, you then set the security key that controls access to a feature. I hope that this makes sense (if it didn't already).
Of course, there could be many reasons you might also want to access the roles assigned to a user and for those uses, the SFS BOs are how you'd do it (and how you are doing it). And you don't have to assign permissions to a role for this to work. I.e. you can create empty roles (with no permissions assigned to the role) and then assign users to them. Also note that the RBS system is designed to allow the end users to create users, create roles and assign users to roles/permissions, unless you disable that feature. So, there could be roles you don't know about out in the field.
Hope that helps. If not, keep asking!
|
By Philipp Guntermann - 7/30/2008
Greg McGuffey (07/29/2008)
To get the roles, the code you originally posted will work nicely, I'd think. However, I'm a bit confused about this statement: ...but it would be nice to read the roles of a user as well without having to assign some permission key to each role for identification. This seems to suggest that you are conceptualizing that roles should be used to determine access to some feature in your application. This is not the case. Permissions are intended to be used to control access. This makes sense once you work it out. Permissions have an action (GRANT, READONLY, DENY) that determine access, while roles are simply containers for permissions. Thus the permission determines what access, while the role simply allows a set of permissions to be assigned to a user at once. Also, since multiple roles might use the same permission, with conflicting actions (i.e. one role might have an action of GRANT for a permission and another the action of DENY) AND the user might be directly assigned a permission, the SF RBS enforces the rules related to this (see help for more details). The GetPermission() method sorts all that out and returns the final verdict for any permission. In code, or via the SecurityKey setting in forms or BOs, you then set the security key that controls access to a feature. I hope that this makes sense (if it didn't already). Of course, there could be many reasons you might also want to access the roles assigned to a user and for those uses, the SFS BOs are how you'd do it (and how you are doing it). And you don't have to assign permissions to a role for this to work. I.e. you can create empty roles (with no permissions assigned to the role) and then assign users to them. Also note that the RBS system is designed to allow the end users to create users, create roles and assign users to roles/permissions, unless you disable that feature. So, there could be roles you don't know about out in the field. Hope that helps. If not, keep asking! hi greg, yes i understand the permission based system. however i'd still want to have the oppertunity to pull the roles associated with a user through our class library, if only for display purposes. I thought there might be away to get this information directly through the SecurityBasics class, rather than having to query the UserRolesBO. Tho it seems there isnt. Thanks for you reply
|
By Greg McGuffey - 7/30/2008
Yes, I think currently, using the SFSUserRolesBO is the only way to access the roles used by a user. Of course, the SF security dialog also shows all the roles/permissions assigned for a user, so you have that option as well (but that probably doesn't work in your situation). You could, of course, make an enhancement suggestion
|
By Guillermo Vilas - 11/7/2008
I just wanted to share what I did to accomplish this.
I have a button that launchs the Inventory Transaction Number Dialog, I want this Dialog to show only to the Warehouse Manager Role:
Private Sub TransTypeEventHandler(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdTransacTypes.Click
Using rol As New MicroFour.StrataFrame.Security.BusinessObjects.SFSRolesBO
rol.FillAllByUser(MicroFour.StrataFrame.Security.SecurityBasics.CurrentUser.UserPK)
If rol.Seek("rl_Role='Warehouse Manager'") Then
LaunchForm(GetType(InventoryTransactListEditor))
Else
MicroFour.StrataFrame.Messaging.MessageForm.ShowMessage("Access Denied.")
End If
End Using
End Sub
Even if the user has the IsAdministrator check he wont be able to Launch the Dialog if he doesn´t belong to the requested role.
Note: I haven´t tested the result when deleting the "Warehouse Manager" Role from the Security Tables.
Cheers 
|
By Greg McGuffey - 11/12/2008
Thanks for the example!
|
|