This documentation applies to the 8.1 version of BMC Atrium Core, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Control of the layout of class forms

The following topics are discussed in this section:

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 CMDB BMC_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.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments

  1. Arturo Castro

    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.

    Sep 05, 2016 01:35
    1. Amol Redij

      Hi Arturo,

      I have taken a note of your comment.

      I shall discuss your comment with the SME and reply to you.

      Thanks,

      Amol

      Sep 06, 2016 04:25
    1. Vinay Bellare

      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

      Sep 07, 2017 12:47