Group: Forum Members
Posts: 2K,
Visits: 6.6K
|
Kotowari,
The key I was referring to is what you are handling with the SetSecurityKeyAndVectorForUserAuthentication method call. However, you should understand what this is doing as it affects how the user data is encrypted within the db table. Make sure you understand how this works.
Check out the Role Based Security section of the SF help file. Specificially the section on Defining Security within the Application. The first topic will give you an overview, Adding Security to an Application. Then use the links within that topic to understand the specifics as needed.
You can create roles and permissions via their respective SFS BO. In order to get this done, you likely will have to do a bit of digging to make sure that you are doing everything that needs to be done. As I suggested earlier, likely as part of the import process, you can create roles as needed and assign them to users, but permissions should likely be done during app development, as this is the connection point between RBS and the app. I.e. the security keys used on forms and data fields are the names of permissions. Roles are easy to manipulate, where as permissions require changes to the application.
As to your roles, you should likely understand how the built in Administrator role works. This is not set via a role or a permission, but is a property of a user (us_IsAdministrator). It allows access to everything.
As to your normal user role, I'd first suggest that you just create it manually. However, if based on how you are testing your import process, if you find yourself continually needing to recreate it, then I'd look into using the SFSRolesBO to create it. You'll need to access the role's PK when assigning users to that role though, no matter how you create it.
To assign the user to a role, use the SFSUsersXRolesBO. It's just a linking BO that links the PK of a user to the PK of a role.
Hope that helps!
|