Field permissions

Field permissions determine the types of access that groups or roles have for individual fields in a form:

• View — Users can read the contents of the field.
• Change — Users can read and write the contents of the field.

If neither permission is selected, members of the group or role cannot view or change the field.
Groups and roles are defined with maximum privileges of View or Change, as explained in To define default permissions for a server or an application and in the Field permissions example. Groups or roles with maximum View permission can never be assigned Change permission for a field; groups or roles with maximum Change permission can be assigned Change, View, or no permission for a field.

If the form is configured to allow static permissions inheritance, granting permission to a field in the form for a group also grants the same permission to any ancestors (parent groups at all levels) of that group. Similarly, when you map a role to a group, the role permissions for the application also apply to any ancestors of the mapped group.

Users must belong to a group or role with permission to view a form's Request ID field (core field 1), or they cannot access any information from that request. After you give a group or role access to the Request ID field, or to any field in the form, the user does not automatically have access to the form or to workflow attached to the field. You must grant permissions to each object individually.

Field permissions lists the questions that you can ask to determine the access that users have to fields in BMC Remedy AR System. Some of the questions are covered in Configuring after installation.

Accessing fields

Advanced data fields

Advanced data fields require you to set permission on various levels. The advanced data field types are table fields, panel fields, and attachment pools. For example, a panel field consists of three levels, each requiring consistent permission settings: the panel holder, the panel, and the fields on the panel (so the user can see the complete panel set). See Field types for more information about the following advanced fields.

Table field permissions properties

Table field permissions are set in the same way as button field permissions, with the exception that you must set permissions at four levels. You must grant or deny a user access to the:

• Table field
• Columns in the table
• Form from which rows are drawn
• Fields from which each column draws its data

The following examples explain the permission hierarchy:

• If a user does not have permission to view any columns, the field or list appears blank in the user client.

• If a user does not have permission to access a field in the supporting form that contains column data, the user sees a blank cell.

• If the user has no permission to access any of the cells in a row, the row is not displayed.

Panel field permissions properties

Panel field permissions are set at three levels. You must grant or deny a user access to

• The panel holder
• Each panel in the panel holder
• Each field in each panel

To see an individual field (the lowest level of the permission hierarchy), the user must have permission to the upper levels of the hierarchy--that is, to the panel holder and the individual panels.

Attachment pool permissions properties

For attachment pool field and attachment field permissions, you must grant or deny a user access to both.
To see an individual attachment field, the user must have permission to the attachment pool field.

If a user does not have permission to view any attachment fields, the attachment pool appears blank in the user client.

Special submit setting

A special submit setting allows users to submit a new request without Change permission for data and attachment fields that require a value. To use this feature, set the Allow Any User to Submit property to Yes for each applicable field.
If the Allow Any User to Submit property is set to No and the field requires a value, a user must have a Write license and belong to a group with Change permission for the field to submit a request. For more information about using this feature, see Defining default permissions and Assigning permissions for individual or multiple objects.

Field permissions example

The following figure illustrates how both permissions and field definitions work together to determine the access to a field. The example lists three groups: Browser, CS Staff, and Sales Staff. These groups have different maximum privileges of View or Change, as explained in Defining default permissions.

Specifying field access control



At the field level, each group is granted specific access to the Short Description data field:

• CS Staff group — Change
• Sales Staff group — View
• Browser group — View Because the Browser group has a maximum access of View, Change access at the field level is not possible.

John is a member of the CS Staff group and the Browser group. Although membership in the Browser group alone does not allow him to change the field, he can change it because of his group permission in the CS Staff group. When a user belongs to more than one group with different permissions to a field, the user has the highest level of permission granted by a group to which the user belongs.

Alice is a member of the Sales Staff group, which has maximum permission of Change. However, at the field level, members of the Sales Staff group can only view the contents of this field.

Rick also can only view the contents of the Short Description field because he is a member of the Browser group. Because the Browser group has maximum privileges of View, you can never give him Change permission for the Short Description field through the Browser group as it is currently defined.