Demystifying Menus and Groups in AR System: A Deep Dive for Developers and Administrators

In the intricate world of BMC Remedy AR System (now often referred to as ITSM or Helix ITSM), understanding the foundational concepts of menus and groups is paramount. These elements are the building blocks of user interaction, data presentation, and access control, shaping how users experience and interact with the system. This article aims to dissect these core components, offering practical insights for both seasoned professionals and those new to the AR System ecosystem. We’ll explore their types, configurations, and the implications for application development and administration.

Understanding Menus: The Gateway to Functionality

Menus in AR System are not just lists of options; they are sophisticated tools that guide users through the application’s features and data. They can be broadly categorized into two main types: static and dynamic. This distinction is crucial for understanding how menu items are populated and how they behave.

1. Static Menus

Static menus are the more straightforward of the two. Their content is predefined and typically loaded from specific data sources. The primary sources for static menus are:

• Character: This refers to menu items defined directly as text strings. These are often simple, hardcoded choices.
• Form Data Dictionary: This is a powerful source where menu items are dynamically populated from the data within a specific form. Each record in the form can represent a menu option. This is incredibly useful for creating dynamic dropdowns or selection lists based on existing data. Think of a “Status” field where the options are pulled directly from a Status form.
• Field Data Dictionary: Similar to the Form Data Dictionary, this allows menu items to be populated from the values of a specific field within a form. This is often used for selecting values that are stored as distinct fields in a related form.

2. Dynamic Menus

Dynamic menus offer greater flexibility by retrieving their content based on specific conditions or queries. This makes them ideal for situations where the available options change frequently or are dependent on user context. The key drivers for dynamic menus include:

• Search: Dynamic menus can be configured to perform a search against one or more forms to retrieve the data that will populate the menu. This allows for complex filtering and selection logic.
• SQL: For more advanced scenarios, dynamic menus can execute direct SQL queries against the underlying database. This provides the utmost flexibility but requires careful handling to maintain data integrity and security.

The File Menu: A Hybrid Example

It’s interesting to note that the “File” menu in many AR System applications often exhibits characteristics of both static and dynamic menus. For instance, recent files or project lists might be dynamically generated based on user activity (dynamic), while core file operations like “New,” “Open,” and “Save” are static, predefined actions.

The Interplay Between Menus and Data: Deletion Considerations

A common question that arises is: “When you delete a menu associated field or form, does it delete the menu itself?” The answer is generally no. AR System is designed with data integrity in mind. Deleting a form or a field that a menu references will typically break the menu’s ability to retrieve its data, causing it to become empty or display errors. However, the menu definition itself usually remains intact. This prevents accidental data loss and allows administrators to rebuild or reconfigure the menu if the associated data is restored or recreated. It’s a protective measure to ensure that the application’s structure isn’t compromised by data cleanup.

Menu Types: Defining Behavior and Purpose

Beyond the static/dynamic classification, menus can also be categorized by their inherent function and purpose:

• View: These menus are designed purely for displaying information or providing access to read-only data. They don’t allow for direct modification of data through the menu itself.
• Change: These menus are associated with actions that modify data, such as editing records, updating fields, or performing transactions.
• None: This indicates that the menu item itself doesn’t perform a direct action but might serve as a separator or a grouping element within a larger menu structure.

Group Categories and Ranges: Organizing Access and Identity

Groups are fundamental to AR System’s access control and permission management. They allow administrators to assign specific rights and privileges to collections of users, rather than managing them individually. The system uses a structured approach to categorize and manage these groups, often using numerical ranges to define their purpose and scope.

Understanding Group Categories

• Regular Groups: These are typically custom groups created by administrators to manage access for specific business functions or teams. Their range is generally from 1000 to 14999, and they are considered Explicit, meaning users must be manually added to them.
• Computed Groups: Similar to regular groups, computed groups are also explicitly defined and reside within the 1000 to 14999 range. The “computed” aspect might imply some level of dynamic membership calculation or derivation, though in practice, they function very much like regular explicit groups for access control.
• Dynamic Groups: These groups, with ranges like 60000-60999 (e.g., 60001, 60002, 60003), are Implicit. Users are automatically members of these groups based on certain conditions or their role within a request or the system.

Implicit vs. Explicit Groups: A Core Distinction

The concept of implicit versus explicit groups is critical for understanding how users gain permissions:

• Explicit Groups: These are groups where you, as an administrator, must manually assign users. When a user is added to an explicit group, they inherit all the permissions granted to that group. Examples provided include admin, sub-admin, customise, struct admin, and struct sub-admin. These are defined for a specific AR System server, so moving applications might require resolving permission conflicts. For broader, server-independent permissions, consider deployable applications using role mappings.
• Implicit Groups: These groups are assigned to users based on specific circumstances or conditions within the system, without direct manual assignment. Examples include public (group ID 0), assignee (group ID 4), assignee group (group ID 7), and submitter (group ID 3). Any dynamic groups you create also fall under this umbrella.

Implicit Group IDs and Their Meanings

The numerical IDs for implicit groups often have predefined meanings:

• Public (0): This is a special implicit group. Users are automatically members, granting them basic, often read-only, access to certain objects.
• Administrator (1): An explicit group, typically reserved for system administrators.
• Customize (2): An explicit group, likely for users who can customize certain aspects of the application.
• Submitter (3): An implicit group. Users are members when they submit a request. This often grants them permissions to view and modify their own submissions.
• Assignee (4): An implicit group. Users are members when a request is assigned to them. This grants them permissions to work on assigned tasks.
• Sub Administrator (5): An explicit group, a tier below the main administrator.
• Assignee Group (7): An implicit group. Users are members if they belong to a group that is assigned the request.
• Struct Admin (8): An explicit group, likely for administrators within a specific organizational structure.
• Sub Struct Admin (9): An explicit group, a tier below the Struct Admin.

Group ID Ranges: A Comprehensive View

The system uses specific numerical ranges to define the purpose of Group IDs:

• 0-1000: Reserved for AR System base groups and current AR System applications.
• 1000-13004 and 13007-14999: For Regular and Computed groups.
• 13005-13006: Specifically for CMDB (Configuration Management Database) groups.
• 14999-59999: Allocated for future AR System applications.
• 60000-60999: Designated for Dynamic groups.

Overlay Groups: Fine-Tuning Development Access

Overlay groups are a critical feature for managing customization and development in AR System, particularly when dealing with “out-of-the-box” (OOTB) objects. They allow administrators to define whether users can work on base mode objects or only on overlay and custom mode objects.

• Overlay Group field set to 1: Users are restricted to working on overlay and custom mode objects. In Developer Studio, this translates to working in Best Practice Customization mode. This is the recommended approach for customizations to ensure smoother upgrades.
• Overlay Group field set to 0: Users are restricted to working on base mode objects. In Developer Studio, this means working in Base Developer mode. This is generally discouraged for new customizations as it can lead to merge conflicts during upgrades.
• Overlay Group set to (clear): This provides no restrictions. Users can access and modify base, overlay, or custom objects.

For more in-depth information on Overlay Groups, consult the BMC Remedy AR System Developing an Application and Administering documentation.

Granular Overlays: Precision in Customization

Granular overlays take the concept of customization a step further by allowing you to apply different overlay types to subcomponents of an object, rather than the entire object at once. This “subcomponent” approach offers significant advantages in managing customizations, especially during system upgrades or patch applications.

Here are the three types of granular overlays:

1. Additive Overlay (or Extensions Overlay): This is used when you want to add new functionality or data to an OOTB object without altering the original. If the origin object changes during an upgrade, your additions are appended, minimizing conflicts. Think of adding a new field or a custom workflow to an existing form.
2. Overwrite Overlay: In this type, the entire overlaid object is used, and the origin object is completely ignored. This behaves like non-granular overlays in older versions. It’s useful for scenarios where you need to completely replace the OOTB functionality or settings, such as removing specific permissions from an object.
3. No Overlay (or Inheritance Overlay): Despite its name, this is still a form of overlay. It’s the default for all objects and their parts if no modifications are made. These overlays inherit properties from the origin object without changes. They are used when you want a component to retain its original behavior and properties, especially during upgrades.

Troubleshooting Tip: If you encounter unexpected behavior after an upgrade, check your overlay types. An incorrect overlay type, especially an overwrite that wasn’t intended, can cause existing functionality to break. Granular overlays, when used correctly, significantly reduce the need for manual reconciliation after patches.

Workflows: The Engine of Automation

Workflows are the backbone of any AR System application, defining the automated processes and actions that drive the system’s functionality. They are triggered by specific events and can range from simple user notifications to complex data manipulations across multiple forms.

What is Workflow?

Workflow can be defined as the set of processes that your company uses to run itself. In AR System, workflow automates these processes through the use of Active Links, Filters, and Escalations. These components trigger actions in response to predefined execution options.

Key Workflow Objects and Their Functions

• Active Link: Executes based on client operations or information on the current screen. They are triggered by user interaction within the application on the client side.
  
  Function: Triggered by user interaction (e.g., clicking a button, changing a field). Can perform operations like displaying messages, changing field label colors, or pushing/inserting/fetching data to/from other forms.
  
  Limitations: Cannot be triggered via API programs. Always execute on the client, in the current form window. If you save an active link with the same name, it will automatically append _c to the name. At least one “Add” action is necessary for an active link to be valid. Saving a form using “Save As” will not copy active links; renaming might.
• Filter: Filters check form transactions as they undergo server processing. They are triggered by interactions or operations happening at the data/records/transaction level on the form/table (e.g., Submit, Modify, Delete).
  
  Function: Process data changes or transactions on the server-side after an event (like submission or modification).
• Escalation: At a predetermined time interval, escalations check requests in the database. Similar to filters, but their trigger is based on a time interval rather than immediate transaction events.
  
  Function: Execute actions based on time-based criteria (e.g., send a reminder email if a ticket is not resolved within 24 hours).

Forms: Schema to Represent Data

Forms in AR System are the primary objects used to represent data, analogous to tables in a database. They define the structure, fields, and data types for the information being stored and managed.

View Related Complications

AR System offers sophisticated ways to present data through views:

• View Field: A field that displays data from another form or a calculated value.
• View Form: A type of form that acts as a virtual representation of data from one or more other forms, allowing for customized data presentation without duplicating underlying data.
• Form View: The ability to create a specific view of a form tailored for different users or user groups, often controlled by permissions or roles.

Form IDs: Categorizing Form Types

Different form types have associated IDs, aiding in their identification and management:

• Regular Form: 1
• Display Form: 4
• Join Form: 2
• View Form: 3
• Vendor Form: 5

Troubleshooting Tip: When working with Join Forms, be aware that once the join criteria are defined, they are typically immutable. This is noted as a potential bug in older versions (e.g., 8.1 Dev). You can create join forms of other form types, including regular, view, vendor, archive, and audit forms.

Help Text: Enhancing User Guidance

Help text is a valuable feature for providing context and instructions to users directly within the application. Its display can vary depending on the login user:

• Login by Demo User: Will show the Field Name (label), Field ID, and the actual Help Text value.
• Login by Other User: Will show only the Help Text value. If no help text is defined, it will display the field’s description, including its symbol, keyword, and length.

Access Control: Permissions, Groups, and Roles

Access control is a cornerstone of AR System security, ensuring that only authorized users can view, modify, or delete specific data and objects. This is primarily achieved through the interplay of Permission Groups and Roles.

Permission Groups and Roles

These are the two primary objects used in Remedy to control access to forms, rows (records), and columns (fields). Users are assigned to groups, and groups can be associated with roles, or permissions can be granted directly to groups. This layered approach allows for granular control over who can do what within the system.

System Information and Configuration

Understanding how to access system information and some common configuration details can be very helpful for troubleshooting and administration.

Finding Version Information

The most comprehensive way to find version information for the AR System is typically through the Application Properties form. This form usually displays all relevant details about the installed application versions.

Port Numbers in AR System Communication

Different services and components within the AR System ecosystem communicate using specific port numbers. Knowing these can be crucial for network configuration and troubleshooting connectivity issues:

• DB2: 50,000
• Oracle: 1521
• SQL Server: 1433
• JAVA plugin port: 9999
• Flash/Board: 1150
• SMTP: 25
• E-mail Engine: (specific port may vary, often configured)
• DIS Server Port: 2000

Client Connections

AR System supports a wide array of clients, capable of handling thousands of concurrent connections. Some common client types and their typical connection IDs (though these can vary based on configuration and version) include:

• Mid Tier: 9 (often refers to a specific connection pool or type)
• User Tool: 3 (represents the traditional client application)

Modifying Workflow Action Limits

In rare cases, you might need to increase the default limit for actions within a workflow. This can be done by editing a header file. For example, in older versions, you might find this setting in C:\Program Files\BMC Software\ARSystem\Arserver\api\include\ar.h. You would open this file and adjust the `MAX_IF_ACTION` (or similar) definition.

Vendor Forms and Data Extraction

A Vendor form is a specific type of form used when the system needs to extract data from external text files. This makes it a ‘vendor’ of data, hence the name. If you see a form classified as type ‘Vendor’ in server information, it’s likely serving this purpose.

When Forms are Deleted: Impact on Active Links

A critical question for application maintenance: “When a form is deleted, do associated active links get deleted?” The answer is yes, but with a condition. If you delete all active links that are associated with a form, then the active links themselves will be removed or invalidated. However, if other forms or components still rely on or reference that active link, it might persist or become orphaned. It’s generally good practice to audit and clean up associated workflows when decommissioning forms.

Conclusion

Menus and groups are more than just interface elements or access control lists; they are fundamental architectural components of AR System applications. Understanding their types, configurations, and interdependencies is crucial for building robust, maintainable, and secure applications. By grasping the nuances of static versus dynamic menus, the hierarchy of group types, and the precise control offered by granular overlays, administrators and developers can leverage these powerful features to their full potential. Keep these concepts in mind during development, troubleshooting, and when preparing for system upgrades. They form the bedrock of efficient AR System management and customization.