How access to tickets and resources works in Smart IT
Row-level security (RLS)
The RLS feature belongs to Action Request System. It controls access to ticket data in BMC Helix ITSM and Smart IT. RLS is based on the principle that only those associated with the ticket must have access to the ticket. InAction Request System, every form contains a set of core fields. Permissions defined for the fields determine ticket access. Accordingly, users and groups included in the Assignee Group (field 112), and Submitter (field 2) in Action Request System can access and view that ticket. Users who can access and edit tickets are defined in other fields such as Assignee (field 4), Assignee Group Parent (field 60989) and so on. To learn more about fields that provide access to tickets, and for additional information about the field 112, see Access control with implicit groups: Row-level security.
Hierarchical groups
In Smart IT, the hierarchy in which support groups are organized is based on the hierarchical group feature in Action Request System. It is a structure that enables you to organize groups, especially larger groups in hierarchical order. Groups are organized in hierarchy, and user's access to ticket data depends on where they are placed in the hierarchy. In this structure, groups are organized in parent and child hierarchy. Parent groups have larger access as compared to child groups.
Impact of RLS on access to tickets and resources
With the implementation of RLS in BMC Helix ITSM and Smart IT, access to ticket data is streamlined and only those users who are directly related to tickets and resources can access it. This section covers the impact of RLS on Smart IT as per the released versions of BMC Helix ITSMand Smart IT.
Access to ticket data is restricted only to users who are directly connected to the ticket or to a support group associated with the ticket
Users can access tickets on the basis of support group or company and support group. In BMC Helix ITSM, on the System Settings form, in the Applications Permissions Model list, the administrator can select one of the two options:
- Support Group—Ticket data access is managed on the basis of individuals (for example, submitter, on behalf of, and assignee) and support groups associated with tickets. This restricts ticket access to only those users who are directly connected to tickets or to support groups associated with tickets. If you select Support Group, the field 112 displays Support Group ID. Support Group includes the following users:
- Submitter of the ticket.
- Assignee of the ticket.
- Owner group who owns the ticket.
- Members of the support group associated with the ticket (child support group).
- Members of the group that is the parent of a support group associated with the ticket (parent group of the child support group).
- Support Group and Company—Ticket data access is based on the support group and company that are associated with the ticket. If you select Support Group and Company, the field 112 displays Support Group ID, Company ID, Contact Name, and Customer name. It includes the following users:
- Users who are part of the Support Group (listed under Support Group).
- All the members of a location and customer company referenced on the ticket.
- All the members of a parent group of the location and customer companies.
Impact of hierarchical groups on access to tickets and resources
Hierarchical groups is a structure that enables you to organize larger groups in hierarchical order. Groups are organized in a hierarchy, and users' access to ticket data depends on the where they are placed in the hierarchy. In this structure, groups are organized in parent and child hierarchy. Parent groups have larger access as compared to child groups.
Important features of the parent and child hierarchical groups are:
- Child groups can access their own tickets.
- Parent groups can access their own tickets and tickets of their respective child groups.
- All permissions assigned to a child group are passed on to its parent group.