ROLES & SECURITY

This is an important functionality which is a part of XDS (extensible data security) which I have updated in my technical stuff list. XDS extends data security from a single table to the tables and views that contain related data.

The main difference between role-based security and record level security is  as follows.

Role-based security: By using role-based security, you restrict the menus, forms, and reports that role members can access.

Record level security: By using record level security to set restrictions on specific records or tables in the database, you can restrict the data that is shown in reports and on forms.

The following examples demonstrate how you can use record-level security.

• Allow members of a Sales role to see only the accounts they manage.
• Prohibit financial data from appearing on forms or reports for a specific role.
• Prohibit account details or account IDs from appearing on forms and reports for a specific role.
• Restrict form and report data according to location or country/region.

When a record-level security policy and a data security policy filter the same data, they may not work together as expected. For example, if the constrained table in the data security policy differs from the primary table in the record-level security filter, the existing record-level security policy is not added to the data security policy query. To achieve the desired behavior, you must add the ranges from the record-level security policy to the data security policy query.

Security policies enable developers and administrators to block access to subsets of data rows in tables. A policy is roughly similar to a where clause in an SQL selectstatement. A security permission increases the access a user has to data, but a security policy decreases access to data.

Data security policy concepts

When developing a data security policy, you need to become familiar with several concepts, such as constrained tables, primary tables, policy queries, and context. This section outlines these concepts. Subsequent sections will use these concepts to illustrate how they work together to provide a rich policy framework.

Constrained table
A constrained table is the table or tables in a given security policy from which data is filtered or secured, based on the associated policy query. For example, in a policy that secures all sales orders based on the customer group, the SalesOrder table would be the constrained table. Constrained tables are always explicitly related to the primary table in the policy.
Primary table
A primary table is used to secure the content of the related constrained table. For example, in a policy that secures all sales orders based on the customer group, the Customer table would be the primary table.
Policy query
A policy query is used to secure the constrained tables specified in a given extensible data security policy. This query will return data from a primary table that is then used to secure the contents of the constrained table.
Context
A policy context is a piece of information that controls the circumstances under which a given policy is considered to be applicable. If this context is not set, then the policy, even if enabled, is not enforced.
Contexts can be of two types: role contexts, and application contexts.

A role context enables policy application based on the role or roles to which the user has been assigned.

An application context enables policy application based on information set by the application.

Let us proceed with an example now.

Scenario: Restricting SO Form with read level access according to country wise through record level security.

Steps are as follows

1. privilege with which menuitem SalesTable form with read-level access
2. Drag above created privilege in newly created duty.
3. Drag this duty into newly created role.
4. Create query which is below.
5. Create a policy which is major part in record level security and assign query and primary table to it which is shown below.

As you can see from above screenshot, primary table is SalesTable andconstraint table is logisticspostalAddress. Context type is Role name in which you are using this policy.

Note: Range plays important part to filter records. Be Careful.

Use this role and test.