Control of the layout of class forms
The following topics are discussed in this section:
- Modification of the views of forms in BMC Atrium CMDB
- Modifying views of forms in BMC Remedy IT Service Management applications
- Generating forms for other applications
- Synchronizing CMDB class forms for BPCU-created overlays
The default view in the join form for a new regular class is generated by using the form for its superclass as a basis. The forms for CDM classes also have more usable views, using panel fields to organize content instead of placing all attribute fields in one column.
BMC Atrium CMDB provides the following layout algorithms:
- Built-in CMDB logic that controls the default layout for all CMDB forms and extensions.
- Utility that updates third-party application forms.
These application forms are not actually CMDB forms but can mirror them by mapping to the CMDB form. For example, BMC Remedy Asset Management has its own form for a Computer System class. This utility can automatically update the BMC Remedy Asset Management form to reflect any changes to the CMDBBMC_ComputerSystem
class.
Both of these algorithms place new attributes in a custom tab. When a custom tab runs out of space to hold more attributes, CMDB creates additional custom tabs. For CMDB forms, the maximum number of custom tabs is 20. For cmdb2asset
forms, the maximum number of custom tabs is 50.
In addition, the position of the attributes within the custom tab might be reshuffled by the CMDB layout. One notable difference between the two algorithms is how the custom tab appears. For CMDB forms, the custom tab is visible by default when you add a new attribute. For cmdb2asset
forms, they are hidden. If you change the visibility, in the next data model change the visibility might revert to the default.
For more information about BMC Remedy AR System views, see Defining and managing form views.
Warning
Do not modify the ObjectStoreView
view (ID 399999100) of the class form for any class in the BMC.CORE
or BMC.CORE.CONFIG
namespaces. Your changes could be overwritten by future releases of patches to the BMC Atrium CMDB. Instead, copy ObjectStoreView
to a new view for that form and modify the new view. There is no risk to modifying the ObjectStoreView
view of class forms in other namespaces.
Comments
Hello.
What happens if we need to add values to a selection type attribute on a class (BaseElement, for example), and we need to reflex that new values to other locale views (es)? There is no place to add "alias" to the new values on the corresponding locale view, so the values are mixed when displaying to user. In this case, it will be necessary to create a new view? or modify "ObjectStoreView - es" view? Thank you.
Hi Arturo,
I have taken a note of your comment.
I shall discuss your comment with the SME and reply to you.
Thanks,
Amol
Hi Arturo,
We seem to have somehow missed your query. Apologies for the delayed response.
As per our SME, there are valid use-cases in which ObjectStore Views need to be modified. However, for all the Remedy customers, generic rule for customization is to create the Overlay of what comes out-of-the-box to avoid accidental overwrites to customized forms/views. If BMC upgrade modifies the views for new attribute addition or new selection enum value to existing attributes, then corresponding changes to view will not be reflected in the Overlaid views. It will take manual effort for customer to add the corresponding fields and/or selection field enum alias values to overlaid views.
Regards,
Vinay