Using the Assignee Group and dynamic groups

Scenario

Based on the example, Allen performs the following procedure to manage access for multiple users in multiple groups.

To use the Assignee Group to control access to requests

1. Create the groups (or roles) and users to which you want to assign access. In this example, the four groups are:
   • Apex Global Staff (Has access to all requests)
   • Beta Computers
   • Gamma Computers
   • Delta Computers
     Beta Computers, Gamma Computers, and Delta Computers users must belong only to their company group. Apex Global employees can be members of more than one group.
2. Create a form, and give the appropriate groups Visible permission for it.
   For example, giving the Public group Visible permission for the form enables all of the users to see it.
3. Add the Assignee Group access to the form.
   The Assignee Group capabilities of AR System are activated when you add a character field to the form with field ID 112 and a database input length of 255.

4. Restrict access to the necessary requests.
   Because only groups or roles with permission for the Request ID field can access a request, restricting access to the Request ID field is the key to restricting access to a request. In this example, the Apex Global Staff and the Assignee Group groups have the appropriate permissions for the Request ID field, as shown in the following figure.

   Field permissions for the Request ID field

   
   

   With Assignee Group access, a user from Beta Computers can submit requests, and anyone from Beta Computers can query them. However, no one from Gamma Computers or Delta Computers can query Beta Computer's requests.
   

   You might want to give permission to a single group, to begin with, and submit a sample request to determine if any group other than the designated group can access it.
   

5. Add a workflow that inserts at least one explicit group, role, or user name into field ID 112 according to the business rules at your site. If Enable Multiple Assign Groups is selected on the Configuration tab of the BMC AR System Administration: Server Information form, you can enter more than one explicit group, role, or user name into field ID 112. For sample syntax, see Defining access to requests at the group level.
   For more information about all settings in the BMC AR System Administration: Server Information form, see Configuring-AR-System-servers.
   Because field ID 112 is designed for administrators and your help desk staff, deny access for most groups to this field. You can define a filter to set the contents of this field and use an active link Change Field action to allow your help desk staff to see and change the field as needed. If you must change the group or role in the field, field ID 112 includes system-defined menus of all groups on the server and roles in the application if the form is owned by a deployable application. Administrators can override these menus in the Administrator field as needed. 
6. Change the permissions of other fields in the form to grant access as needed. Include the Assignee Group where appropriate.

In the example, Apex Global accesses its service call database from a browser but limits users to viewing only requests submitted by members of their company. An access control group is created for each different company name, and a filter, that copies the company name into field ID 112 labeled Assignee Group in the following image, executes when users submit requests:

When the filter is triggered, the Assignee Group for this request is Beta Computers.
You also can create individual filters. With one filter, Beta Computers can see their requests, and with the other filter, Gamma Computers can see their requests, and so on.

Use appropriate filter qualifications to make sure that only users from the Beta Computers group can run the filter. For example, set field ID 112 to Beta Computers.
For more information about creating and using filters, see Workflow-objects.

As a result of carefully defining access control in your system, when Allen searches all open help desk requests, he sees a results list that includes requests submitted by Beta, Gamma, and Delta Computers. In contrast, if users from Delta Computers perform the same search, they see only the requests where Delta Computers is the Assignee Group, that is, the requests submitted by anyone at Delta Computers.

To use a dynamic group to control access to requests

1. Create the groups (or roles) and users to which you want to assign access.
2. Create a dynamic group in the Group form.
   For example, create a group called Dynamic Access with a group ID of 60001.
3. Create a form, and give the appropriate groups Visible permission for it.
4. Add a character field to the form with field ID 60001, the same ID number as the dynamic group ID.
5. Restrict access to requests in the form by granting the group Dynamic Access permission to the Request ID field.
6. Add a workflow that inserts at least one explicit group name or ID, role name or ID, or user name into field ID 60001 according to the business rules at your site. If Enable Multiple Assign Groups is selected on the Configuration tab of the BMC AR System Administration: Server Information form, you can enter more than one explicit group, role, or user name into field ID 60001. For sample syntax, see Defining access to requests at the group level.
   For more information about all settings in the BMC AR System Administration: Server Information form, see Configuring-AR-System-servers.
   Like field ID 112, dynamic group fields can be modified manually. They include system-defined menus of all groups on the server and roles in the application (if the form is owned by a deployable application). Administrators can modify these menus as needed.