How to Set Up the Data Partition

Data partitions can be assigned to individual contacts, but the preferred method is to assign data partitions based on access type. After associating data partitions with different access types, you can associate a contact to a particular access type, and define its data partition. The access type has a specific option to override the contact data partition.
casm1401
Data partitions can be assigned to individual contacts, but the preferred method is to assign data partitions based on access type. After associating data partitions with different access types, you can associate a contact to a particular access type, and define its data partition. The access type has a specific option to override the contact data partition.
To associate a data partition to an access type, you set up data partitions that are meaningful to your site and then select one of the data partitions when you define or modify an access type.
Other CA SDM security settings can take precedence over data partition.
The data partition is a subset of CA SDM database that controls a user access to tickets and other data records based on their content.
For example, you can restrict a user view of the database to only those configuration items that are assigned to the user organization. You can also restrict a user to update only assigned tickets and allow read-only access to other configuration items.
A data partition consists of a set of constraints. The data partition constraints identify the table that is being controlled by the data partition and the constraint type. The constraint typesspecify what the user can do, such as create, delete, update, view, and so forth, within the data partition. After you assign a data partition to an access type, which you in turn assign to a user contact record, the constraints and constraint types are what control the user access to the records in the CA SDM database table.
You can also view constraints independent of the data partition using them. For example, you want to view all constraints for a specific table, regardless of the data partition.
Follow these steps:
Verify the Prerequisites
Before you set up the data partition, verify the following prerequisites:
Data Security Structure and Policy
Planning data security involves enforcing restrictions to access the specific portion of the database. These restrictions can be enforced on individual contacts either through roles or access types:
  • Roles
    Defines the functionality that users in the role are allowed to access. You can assign one or more roles to an individual contact record, or to an access type to define the functional access for all of the access types who are associated with contacts.
  • Access Type
    Defines how contacts are authenticated when they log in to the web interface. For example, an access type decides whether the contacts can modify web forms or the database schema using Web Screen Painter and which roles are available for the contacts.
As a service desk administrator, you can modify the predefined access types and also create new ones. You can enforce the restriction to the individual users or a group of users through Roles.
Identify the following:
  • The objects and the type of restrictions you want to enforce on these objects.
  • The Users or Roles on whom the Data Partition are applied. Data Partitions can be applied to contacts directly, but the preferred method is to assign data partitions based on the role and assign this role to all the contacts directly or through the access type.
Data Partitions Setup Specifications
You can define an unlimited number of data partitions. Each data partition consists of a set of constraints and validations on each database table that is restricted by the data partition. For each table in a data partition, you can specify independent authorizations to view, update, create, or delete records using criteria that are specified in a format similar to an SQL WHERE clause. You can base the restriction on any attribute in the record being accessed, combined with any data in the user contact record. This allows considerable flexibility when defining data partitions. For example, using the Vendor field in the Contact table allows data partition restrictions to be placed on vendors that are permitted to access CA SDM directly.
For performance reasons, CA SDM does not allow a data partition constraint to contain a Cartesian join. A Cartesian join results from a constraint containing an “OR” that does fully restrict all joined tables on both sides of the OR. To ensure that your data partition constraint does not produce a Cartesian product join, enter the following command:
  • Windows
    bop_cmd -f $NX_ROOT\bopcfg\interp\bop_diag.frg "check_queries()"
  • UNIX
    bop_cmd -f $NX_ROOT/bopcfg/interp/bop_diag.frg "check_queries()"
Any data partitions that are flagged by this program must be updated appropriately.
Constraint Specifications
You specify constraints and validation tests in Majic using the object definition metalanguage.
Constraints that are defined in Majic closely resemble an SQL WHERE clause, with the following exceptions:
  • Attribute names in the constraint are object attribute names, not the database attribute name from the schema.
  • You can refer to the value of an attribute in the contact record for the logged-in user with a name of the following form, where
    att_name
    is the Majic name of the desired attribute:
    @root.att_name
    For example, specifying @root.location refers to the location ID of the current contact.
    You specify joins with a specification of the following form, where the
    foreign-key
    is the Majic name of the SREL attribute in the table for which you are writing the data partition constraint, and
    attribute-in-referenced-table
    is the Majic name of the attribute in the table being joined:
    foreign-key.attribute-in-referenced-table
    For example, to refer to the maintenance vendor of the asset that is associated with an incident report, specify the following:
    resource.vendor_repair
    This specification is recursive. For example, you could refer to the name of the vendor with the following name:
    resource.vendor_repair.name
The following table contains examples of valid constraints to use for the Change_Request table, used to store change order information:
Constraint Type
Code and Description
View
assignee.organization = @root.organization
Specifies the user can only view change orders where the assignee’s organization is the same as the user’s organization.
Pre-Update
requestor = @root.id
Specifies the user can only update the change orders where he is the caller or requester.
However, you cannot write a constraint that uses joins on both sides of the expression, as shown in the following example:
assignee.org = requestor.org
Configure Knowledge Management Data Partition Constraints for Role-Based Permissions
Knowledge Management data partitions are enabled to let you use group and role permissions by default in CA SDM. If you are upgrading from a previous release, the migration tool updates your data partition constraints.
If you used custom data partition constraints to manage knowledge permissions in a previous release, update the constraints manually for the O_INDEXES and SKELETONS tables. You can view the default data partition constraints and apply the changes, as appropriate to your environment.
Follow these steps:
  1. Select Security and Role Management, Data Partitions, Data Partition Constraints on the Administration tab.
    The Data Partition Constraints List page opens.
  2. Click Show Filter and search use the following search criteria:
    • Service Desk Analyst
      in the Data Partition search.
    • O_INDEXES
      in the Table search.
  3. Edit the View constraint type by modifying the Constraint tab to replace "READ_PGROUP in @root.pgroups" as follows:
    READ_PGROUP in @root.pgroups OR READ_PGROUP.[pgroup]contained_roles.role IN @root.id
  4. Save the constraint.
  5. Edit the Delete and Pre-Update constraint types by modifying the Constraint tab to replace "WRITE_PGROUP in @root.pgroups"as follows:
    WRITE_PGROUP in @root.pgroups OR WRITE_PGROUP.[pgroup]contained_roles.role IN @root.role
  6. Save the constraints.
  7. Repeat the steps to update the View, Delete, and Pre-Update constraints in the SKELETONS table in your data partition.
    The data partition constraints are updated.