Creating groups
This section provides the steps to create BMC Remedy AR System access control groups. Although there is no limit to the number of groups that you can create, for maintenance purposes you might want to limit the number to avoid confusion. After you have created the necessary groups, see Adding-and-modifying-user-information, to assign individual users to the appropriate groups.
Use the Group form (shown in the following figure) in a browser to create and manage the access control groups to which you grant or deny access to AR System objects. You should restrict your users to making modifications only to custom objects and overlays.
Group Information form — New mode
(Click the image to expand it.) 
The following table lists the fields you can set the Group form.
Fields in the Group Information form
Field | Description |
|---|---|
Group Name | Name of the access control group. Use this name in the Group list field in the User form and in the Permission and No Permission lists when you are defining BMC Remedy AR System object permissions. Every group name should be different. Use caution when creating group names that include spaces, because group names in the Group list field on the User form are separated by spaces. For example, if you have a group named CUSTOMER_SUPPORT, you should not create a group named CUSTOMER or a group named SUPPORT. |
Group ID | Integer ID that is the recognized identity of the group. The ranges are:
If you use the same ID with multiple group names, you must keep the Group type the same for each because you are creating aliases for the same group. To make sure that you do not create duplicate Group IDs, use Remedy Administrator to build a unique index on the Group ID field in the Group form. (See Defining-indexes.) The Group ID defines the priority of a group when a user obtains a floating license. See About-floating-licenses-in-a-license-pool. Note: If you create multiple groups with the same ID, the User form displays the first available group name for the selected group id. |
Group Type | Maximum permission type intended for the group. Your choices are None (no access), View (view field contents), and Change (modify field contents). Specify None to disable all access for the group without deleting the group itself. The group remains as a placeholder (and can be restored in the future), but all permissions for the group are lost. To define a group used only for notifications, create a group with the type None. See Field-permissions. |
Long Group Name | Additional information about a group. The text should be descriptive of the group because it appears by default in the Results pane in the mid tier when listing groups. |
Group Category | The group category, such as Regular, Dynamic, or Computed, which is described in Regular-computed-and-dynamic-groups. To define a dynamic group, use a group ID in the range of 60000 to 60999. On the form containing requests to which you want to define row-level access, add a field with a field ID that is the same as the dynamic group ID. You can populate a dynamic group field with a group name, role name, or the name of an individual user. Dynamic Groups are used only to control access to requests (row-level access). To define a computed group, select Computed Group as the group category and enter a qualification string in the Computed Group Definition field. |
Parent Group | The parent group, if any, of the current group. This field is optional. If a parent group is assigned, members of the parent group have the same rights as members of the current group to objects that allow permissions inheritance. A group can have at most one parent group. Any regular or computed explicit group can act as a parent group, except for Administrator, Sub Administrator, and Customize. Implicit groups cannot be used as a parent group. (Implicit groups include Assignee, Submitter, Assignee Group, and dynamic groups.) To assign a parent group, the parent group must already exist. Select the parent group from the drop-down list. For:
|
Overlay Group | Use the setting to define the group as an Overlay Group. The Overlay Group option on the Group Information Form, provides the following access options:
For more information, see Groups-in-BMC-Remedy-AR-System and Operations-on-objects-restricted-by-development-mode. For information about how to create floating licenses in a license pool, see the article on BMC Communities About floating licenses in a license pool. Notes:
|
Computed Group Definition | Qualification string that defines a computed group. Construct the string from any valid combination of explicit group IDs, explicit group names (in double quotation marks), user names (in single quotation marks), and operators such as AND, OR, and NOT. Optionally, use the AND, OR, NOT, Append Group, Append User, and parentheses buttons to build the qualification string. Examples:
|
Floating Licenses | Number of floating licenses reserved for the group. See About-floating-licenses-in-a-license-pool. If this field is missing from the Group form, you can add it using Remedy Administrator. Use field ID 115. See Creating-data-fields. |
Application Floating License | Manually enter the information for this field. You can add more than one entry of application names and number of licenses, separated by a semicolon. Use the following syntax when providing users with application licenses: _vendorName_: _applicationName_ Note: For the Application Floating License field, the value of typeOfLicense is 'Floating'. Example:
XYZ:MusicManager User Floating:5;
XYZ:MusicManager User Floating:5; The applicationName string must be the same as the Product Name string in the Application Licensing dialog box (Application > License Application) in BMC Remedy Developer Studio. If the Application Floating License field is missing from the Group form, you can use Remedy Administrator to add the field. Use field ID 115. See Creating-data-fields. To use BMC Remedy AR System-based applications from BMC Software, you need an BMC Remedy AR System user (floating) license (to access the BMC Remedy AR System server) and an application user (floating) license (to access the application). |
Unique Identifier | A unique identifier for the group. A unique identifier is useful if you have two groups with the same name for different applications. You can use the unique identifier to differentiate the two. |
Datatag | Tags the data record as needed. This field is optional. For example, it can store the name of the application which uses this group. |
To create groups
- In a browser, open the Group form of the appropriate server in New mode.
- Enter information in the appropriate fields, as described in the previous table.
- Save your changes.
For a regular group, assign users to it by using the User form in a browser.
After you save a group, the server automatically reaches, and the new group appears in the Group menu in the User form after a short delay. For more information about adding users, see Adding-and-modifying-user-information.
To enable a dynamic group, add a field to the form with a field ID that is the same as the group ID.