When attempting to add extended fields of cmdb_ci (and possibly other Table Per Partition) fields, large table structures can cause adding those fields to be unacceptably slow, and potentially locking the browser. This is likely to occur in any place where you are able to add extended fields using a slushbucket, such as in the Report Builder or when trying to add dot-walked fields to forms configuring Form Layout.

Steps to Reproduce

Note – These steps are valid for user interfaces prior to UI16. Although the issue does occur on UI16, reproducing it on that UI requires slightly different steps. if you get switched to UI16, click the gear icon in the upper right and switch to UI15.

  1. Go to / and set glide.ui.list.allow_extended_fields sys_property to true.

  2. Go to

  3. From the Data drop-down menu, select Table > Task (or any table that has a reference to the Configuration Item table).

  4. In the list of Available fields, scroll to find the Configuration Item field (or whatever field references cmdb_ci) and click it.

    Between the Available and Selected fields, a new "mapping" icon appears above the < and > icons.

  5. Click the new icon.

    Expected behavior: Available fields will be updated to show all of the fields that extend from the cmdb_ci table. This should take a reasonable period of time.

    Actual behavior: The browser locks. Although the browser will eventually become active again, its return takes an unacceptable period of time.




There is no effective workaround for this issue.  Since the issue only appears when the glide.ui.list.allow_extended_fields property is set to true and therefore if the fields aren't needed setting this to false is a potential, but limiting workaround as the if the extended fields are required then those will not be listed or available for the report.

Some customers have observed that Firefox performs better when the very large payload is returned from the server, so that it's just very slow, rather than crashing.  Firefox might be a temporary workaround for some customers.

Upgrading the software to a fixed version (JP6 or JP5 HF2) is the only way to get the report builder working the way the customer expects.


When an instance is already on a version that contains the fix and the "old reporting UI" is being used, the report would need to be re-created to see the fix take effect.

Alternatively, you can use the "new report UI", which will avoid this issue altogether.

Related Problem: PRB1169930

Seen In

Jakarta Patch 1 Hot Fix 1
Jakarta Patch 3
SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - VR - Qualys - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3

Fixed In

Jakarta Patch 5 Hot Fix 2
Jakarta Patch 6
Kingston Patch 1

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-11-27 05:12:11