Custom drop down lists don't appear in quickcreate forms in 5.0b - here's why

**gregwatson** · 2008-04-11, 06:43 PM

I've noticed that if you add a custom drop down list field to a quickcreate form it will not display custom drop down list values. Here's are some quick steps to reproduce followed by an explanation of the problem.

Using Studio, add a new DropDown field to the Leads module.
For this field, create a new drop down list and give it a few values.
Save the field so it's using your new drop down list.
Still using Studio, add this field to the QuickCreate layout.
Click the "Save & Deploy" button to publish your changes.
Now go to the detail view of a record in the Contacts module.
Down below the contact details, find the Leads subpanel and click the Create button.
Find your custom field on this form.
When you open the drop down list, the only item on the list is the drop down list name.
Actually, on occasion, the correct values will appear. This is rare and has to do with whether Sugar is pulling the data from its cache or not. I'll explain more on this below. If you do see the correct values, just click the Cancel button and then click Create again.
Note: this problem does not occur for out-of-the-box lists on quickcreates, nor does it happen with custom lists on normal edit views.

OK, after digging through the code for a few days I've discovered what the problem is, although I'm not sure of the best way to fix it. Hopefully there will be enough info here that one of the Sugar developers will know what to do.

Behind the scenes QuickCreates appear to use the "classic" view. The main problem has to do with the display function in the /include/MVC/View/views/view.classic.php file. This function calls the includeClassicFile function from the SugarView parent class. The SugarView's includeClassicFile function brings a whole bunch of global variables into its local scope, including the $app_list_strings variable where both built-in and custom drop-down list values are defined. At this point of execution, this variable correctly includes both sets of drop down values.

The last thing this function does is to call require_once on a passed-in file name. In this case the file is /modules/Home/SubpanelCreates.php. This is where it gets tricky. Through a series of nested "require_once" calls (see gory details below), the file /include/language/en_us.lang.php is included. This is the file that defines the built-in (English) drop down list values. The custom drop down list values are stored in /custom/include/language/en_us.lang.php.

Remember that the $app_list_strings variable was declared global inside the includeClassicFile function. By then including include/language/en_us.lang.php, the global $app_list_strings variable that contains both built-in and custom drop downs is overwritten by the $app_list_strings that contains only the built-in values.

The reason why the correct values do appear sometimes has to do with the fact that the /include/language/en_us.lang.php file is called with the require_once function. Generally Sugar pulls the drop down list values from the cache. When it does this, it doesn't need to include the /include/language/en_us.lang.php file, so when that file is require_once'ed indirectly via the includeClassicFile function, it's the first time it's called and so is loaded.

However, when Sugar doesn't load $app_list_strings from the cache, it has to include /include/language/en_us.lang.php. This means when includeClassicFile calls it via require_once it doesn't load it since it's already been loaded earlier. Since it doesn't load it, it doesn't overwrite the correct data in the $app_list_strings with the built-in-only data from include/language/en_us.lang.php.

Here's a kludgey change that fixes this specific problem. I don't know the Sugar code well enough to say whether or not it breaks something else though, so use it at your own risk:

Open /include/EditView/SubpanelQuickCreate.php.
Find the line near the top that says: require_once('include/EditView/EditView2.php');
Immediately after it, insert the following line:
PHP Code:

$app_list_strings = return_app_list_strings_language($current_language);
All we are doing is re-overwriting the $app_list_strings variable with the correct, full values.

If you really want gory details, here's the full chain of included files that derive from the display function defined within /include/MVC/View/views/view.classic.php:

/include/MVC/View/views/view.classic.php uses the includeClassicFile function defined in
/include/MVC/View/SugarView.php, which requires
/modules/Home/SubpanelCreates.php, which requires
/include/EditView/SubpanelQuickCreate.php, which requires
/include/EditView/EditView2.php, which requires
/include/SugarFields/Parsers/EditViewMetaParser.php, which requires
/include/language/en_us.lang.php

I hope this helps everyone out.

Thanks,
Greg Watson

P.S. Thank you for making Sugar open source. These are the kind of bugs that can drive an IT guy nuts with closed-source software. I love having the power to solve my own problems. Even if it does take a few days of pouring over code, it beats sitting on hold for an hour waiting for tech support.