Creating and managing access control groups

Access control groups are collections of Developer Studio users. A user gains access to an object, a field, or a request if a group the user is in has access, or a role mapped to such a group has access. Notifications also can use groups. For example, you can designate an entire group to be notified in a filter action.

Developer Studio includes a Public group and eight other special groups that are essential for access control within the system. You can define additional groups based on a common profile and assign access accordingly. For example, you might create a Sales group and allow members to view the status of a request but not to change it. A group can also be a general category, such as Browsers. 

Developer Studio provides two types of groups:

• Explicit groups—Groups to which you must manually assign users in the User form. When a user becomes a member of a group, the user is given access to all objects and fields to which the group is granted access. Explicit groups that you create are defined for a particular server. If you move the objects to a new server with its own defined explicit groups, you might need to resolve permission conflicts. Consider using a deployable application, which uses role permissions that can be mapped to different groups on different servers. For more information, see Creating-and-modifying-users.
• Implicit groups—Groups that depend on specific user circumstances and situations. Users belong to these groups based on specific conditions, such as the contents of special fields within each request. You do not directly assign users to implicit groups. Any dynamic groups that you create are also implicit groups. For more information, see Controlling-access-by-using-implicit-groups-Row-level-security.

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 Creating-and-modifying-users, to assign individual users to the appropriate groups.

You should restrict your users to making modifications only to custom objects and overlays.

To create groups

1. In a browser, as an Administrator, open the Group form of the appropriate server in New mode.
   
   
   

2. Enter information in the appropriate fields.

   If attributes that you want to specify in the group definition are not represented in the Group form, you can use Remedy Administrator to add the appropriate fields. However, be careful that you do not modify or delete any of the original fields or field IDs.

   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: 0 – 1000—For AR System groups and current AR System applications 1000 – 1049, 1061 – 13004, 13021 – 13999, 14102 – 14450, and 14452 – 14998—For non-BMC regular and computed groups 1050 – 1060, 13005 – 13020, 14000 – 14101, and 14451—Reserved for current AR System applications 14999 – 59999—For current and future AR System applications 60000 and 60002 – 60099—For non-BMC dynamic groups 60001 and 60100 – 60999—For AR System application dynamic groups 61000 – 99999—For AR System applications 100000 – 999999999—For non-BMC regular and computed groups 1000000000+—For BMC company permissions 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. For information about floating licenses in a license pool, see License-types-for-users-to-access-AR-System-server. 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: An overview of hierarchical groups, see Using-a-parent-group-for-permissions-inheritance. Information about setting permissions inheritance for an object, see Assigning-permissions-for-individual-or-multiple-objects. Information about row-level access control and hierarchical groups, see Controlling-access-to-requests-for-hierarchical-groups.
   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: Overlay Group field set to 1: When a group assigned to the user has the Overlay Group field set to 1, the user is restricted to working on overlay and custom mode objects. In Developer Studio, the user can work only in Best Practice Customization mode. Overlay Group field set to 0: When a group assigned to the user has the Overlay Group field set to 0, the user is restricted to working on base mode objects. In Developer Studio, the user can work only in Base Developer mode.  Overlay Group set to (clear): When the Overlay Group is set to (clear), the Group provides no restrictions on access to base, overlay, or custom objects. Overlay Group field set to 999999999: When a group assigned to the user has the Overlay Group field set to 999999999, the user can work only in read-only mode on all base, overlay, and custom objects. For more information, see User-and-group-access 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. Do not assign an overlay to a computed group. If you assign an overlay to a computed group, the ARERR 8821 warning occurs and the computed group is saved with Overlay Group as NULL in the AR System server. Users must have administrator or sub administrator privileges on the AR System server to access Developer Studio.
   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. Following are some examples: 12000 OR 12001—Includes all users in group ID 12000 or group ID 12001. "A" OR "B"—Includes all users in group A or group B. "A" AND "B"—Includes only those users in group A and group B. ("A" OR "B") AND (NOT "C")—Includes all users in groups A or B, except for those users who are in group C. "A" OR "Mary Manager—Includes all users in group A, and the user Mary Manager.
   Floating Licenses	Number of floating licenses reserved for the group. See License-types-for-users-to-access-AR-System-server. If this field is missing from the Group form, you can add it using Remedy Administrator. Use field ID 115. See Creating-common-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_  user _typeOfLicense_: _Number of licenses_ ; For the Application Floating License field, the value of typeOfLicense is Floating. Following are some examples: For a single application: XYZ:MusicManager User Floating:5; For multiple applications, separate multiple licenses with semicolons: XYZ:MusicManager User Floating:5;    XYZ:NoiseManager User Floating:2; The applicationName string must be the same as the Product Name string in the Application Licensing dialog box (Application > License Application) in 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-common-data-fields. To use Developer Studio-based applications from BMC, you need a AR System user (floating) license (to access the 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.

3. 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 Creating-and-modifying-users.
   To enable a dynamic group, add a field to the form with a field ID that is the same as the group ID. 
   If you create and save a group in the Group form using a browser, and then flush the mid tier cache, the new group still does not appear when a user opens the field menu of a group list in a form. The user must click the browser Refresh button to see the new group.

To search for groups

1. In a browser, open the Group form of the appropriate server in Search mode.
2. Enter values in fields, or use the Advanced Search Bar to specify search criteria.
   For computed groups, enter one group ID or one user name (in single quotation marks) in the Computed Group Definition field. If you use the Advance Search Bar, use the LIKE operator to indicate that you are searching for a portion of a string. (See Operators for more information.) The search returns all computed groups that include the specified user or group in the definition.
   You cannot search the Computed Group Definition field for group names, or for strings that include operators such as AND, OR, and NOT. This is because BMC Remedy AR System converts group names to group IDs and encodes operators before storing them in the database. However, the search results do show the strings as they were originally entered, with group names and operators.
3. Choose Actions > Search to retrieve the list of currently defined groups that match your search criteria.

To modify groups

1. In a browser, open the Group form of the appropriate server in Search mode.
2. Perform a search to retrieve a list of currently defined groups.
3. Select the appropriate group from the list.
4. Modify information in the appropriate fields.
5. Save your changes.

To delete groups

1. In a browser, open the Group form of the appropriate server in Search mode.
2. Perform a search to retrieve a list of currently defined groups.
3. Select the appropriate group from the list.
4. Choose Actions > Delete.
   A confirmation box appears to verify that you want to delete the group entry.

5. Click OK.

   Permissions for a user are determined by the list of groups in the Group list field of the user's entry in the User form. If you later delete a group or change its Group ID, the users originally assigned to the group are still attached to the old ID. If there is no group with the old ID, these users are no longer attached to any group.