Case Vardefs incomplete during Elasticsearch index process #4955

New issue

Open

opened 2026-02-20 16:26:51 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 16:26:51 -05:00

Owner

Originally created by @simonr44 on GitHub (Feb 16, 2023).

Issue

During the Elasticsearch indexing process, the enabled modules are looped through and when Cases are enabled, errors are generated such as undefined "type" when building the where query for relations that are stored in the database fields_meta_data table by default: e.g. jjwg_maps_geocode_status_c

Expected Behavior

Case vardef's should be consistent, however loaded.

Actual Behavior

When the Case field definitions are first loaded the object name is set to "Case"
SugarBean.php Line 457

VardefManager::loadVardef($this->module_dir, $this->object_name);

This loads the vardefs from the following file: cache/modules/Cases/Casevardefs.php

When subsequent calls are made to VardefManager.php, originating from a relationship field, the object name is set to "aCase"
The "aCase" value comes from a call to getBeanName function in the BeanFactory as this returns the value from global $beanList

This tries and fails to load the following file: cache/modules/Cases/aCasevardefs.php

As the above fails VardefManager::refreshVardefs is called using the incorrect object name.

This ultimately leads to a new set of Vardefs being built and used. These are complete from a file perspective but do not contain the field definitions from the "fields_meta_data" table.

Possible Fix

There is some code in VardefManager.php around lines 288:293 which tries to load the object name from the Bean. But this is returning the true object name, rather than the one defined in the Case Bean file.

One option would be to ensure the correct name is used specifically for vardefs:

if (empty($dictionary[$object])) {
$newName = BeanFactory::getObjectName($module);
    if($newName === "aCase") {
        $newName = "Case";
     }
$object = $newName != false ? $newName : $object;
}

That's not an especially great fix and it may be worth further investigation into the different scenarios around "Case" and "aCase" and how they tie back to the Case bean defined object name.

Calls through the UI seem to use "Case" as the object name, retrieved from the global $objectList but this is empty in the above scenario

Steps to Reproduce

Default 7.13.1 install with Elasticsearch configured and enabled
Ensure Cases is enabled in Admin -> Search Settings
Perform the index process using robo

Your Environment

SuiteCRM Version used: 7.13.1
Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): N/A
Environment name and version (e.g. MySQL, PHP 7): PHP7.4, MariaDB
Operating System and version (e.g Ubuntu 16.04): Debian 11

Originally created by @simonr44 on GitHub (Feb 16, 2023). #### Issue During the Elasticsearch indexing process, the enabled modules are looped through and when Cases are enabled, errors are generated such as undefined "type" when building the where query for relations that are stored in the database `fields_meta_data` table by default: e.g. `jjwg_maps_geocode_status_c` #### Expected Behavior Case vardef's should be consistent, however loaded. #### Actual Behavior When the Case field definitions are first loaded the object name is set to "Case" SugarBean.php Line 457 ``` VardefManager::loadVardef($this->module_dir, $this->object_name); ``` This loads the vardefs from the following file: `cache/modules/Cases/Casevardefs.php` When subsequent calls are made to `VardefManager.php`, originating from a relationship field, the object name is set to "aCase" The "aCase" value comes from a call to `getBeanName` function in the `BeanFactory` as this returns the value from `global $beanList` This tries and fails to load the following file: `cache/modules/Cases/aCasevardefs.php` As the above fails `VardefManager::refreshVardefs` is called using the incorrect object name. This ultimately leads to a new set of Vardefs being built and used. These are complete from a file perspective but do not contain the field definitions from the "fields_meta_data" table. #### Possible Fix There is some code in VardefManager.php around lines 288:293 which tries to load the object name from the Bean. But this is returning the true object name, rather than the one defined in the Case Bean file. One option would be to ensure the correct name is used specifically for vardefs: ``` if (empty($dictionary[$object])) { $newName = BeanFactory::getObjectName($module); if($newName === "aCase") { $newName = "Case"; } $object = $newName != false ? $newName : $object; } ``` That's not an especially great fix and it may be worth further investigation into the different scenarios around "Case" and "aCase" and how they tie back to the Case bean defined object name. Calls through the UI seem to use "Case" as the object name, retrieved from the `global $objectList` but this is empty in the above scenario #### Steps to Reproduce 1. Default 7.13.1 install with Elasticsearch configured and enabled 2. Ensure Cases is enabled in Admin -> Search Settings 3. Perform the index process using robo #### Your Environment * SuiteCRM Version used: 7.13.1 * Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): N/A * Environment name and version (e.g. MySQL, PHP 7): PHP7.4, MariaDB * Operating System and version (e.g Ubuntu 16.04): Debian 11

deekerman added the

Type: Bug

Priority:Important

Area: Elasticsearch

labels

2026-02-20 16:26:51 -05:00

deekerman commented

2026-02-20 16:26:52 -05:00

Author

Owner

@SuiteBot commented on GitHub (Feb 16, 2023):

This issue has been mentioned on SuiteCRM. There might be relevant details there:

https://community.suitecrm.com/t/improved-elasticsearch-query-building/87273/6

@SuiteBot commented on GitHub (Feb 16, 2023): This issue has been mentioned on **SuiteCRM**. There might be relevant details there: https://community.suitecrm.com/t/improved-elasticsearch-query-building/87273/6