How do you hide a stock field from studio

Bungle · 9 October 2015 10:27

Hi,

I’m trying to avoid confusion when working in studio by hiding some stock fields, by setting ‘studio’=false in custom/Extension/Modules/Leads/Vardefs/vardefs.etc.php :

The field is being hidden from the ‘fields’ list correctly but it still appears in the edt/detail Layouts.

How can i completely hide the field from studio?

Thanks
Bungle

Bungle · 9 October 2015 20:17

I decided to choose my battles and edited the label of the unused fields with a prefix of ‘x_’ .

Visually that helped to order the list of fields in studio.

Not exactly the best workaround i know.

sinergiacrm · 15 June 2020 11:11

Hi,

Is there any update on this? We want to hide some stock fields (annual_revenue and industry) from the Accounts module, they don’t appear in the field list but they keep appearing in the EditView/DetailView from Studio:

This is the code we are applying for the fields extension vardefs (it’s working for other stock fields):
$dictionary[‘Account’][‘fields’][‘annual_revenue’][‘studio’] = false;

blqt · 15 June 2020 13:10

Hi,

You should try:

$dictionary['Account']['fields']['annual_revenue']['studio'] =array(
				'visible' => false, 
				'listview' => true,
);

sinergiacrm · 15 June 2020 15:06

This isn’t what we are trying to accomplish. Probably I didn’t explain myself properly, apologies.

The result we want to achieve is that those stock Account fields don’t appear at all in the Studio, nor in the field list, nor the EditView/ListView editions.

Using the code I posted above we can hide almost ANY stock or custom field from the studio. But the fields “annual_revenue” or “industry” aren’t fully hiding.

I believe they have a “special” behaviour, cause they appear in many different files of the core. Therefore probably the studio property don’t work on the same way.

Not sure yet if this should be an issue for the github flow.

Thanks in advance

samus-aran · 15 June 2020 15:21

Hey @sinergiacrm I think this is a core issue but I’m trying to confirm this since it would’ve been there since the initial commit.

I’ve narrowed it down to an area but I don’t propose it as a fix since I don’t know what implications it may have.

I would recommend raising this as a GitHub issue to help us track it.

github.com

salesagility/SuiteCRM/blob/706fd7b7a87cdcaa5f2114028f9e5dc2b243f65b/modules/ModuleBuilder/parsers/views/GridLayoutMetaDataParser.php#L259




/**
 * @return array
 */
public function getAvailableFields()
{


    // Obtain the full list of valid fields in this module
    $availableFields = array();
    foreach ($this->_fielddefs as $key => $def) {
        if (GridLayoutMetaDataParser::validField($def, $this->_view) || isset($this->_originalViewDef[$key])) {
            //If the field original label existing, we should use the original label instead the label in its fielddefs.
            if (isset($this->_originalViewDef[$key]) && is_array($this->_originalViewDef[$key]) && isset($this->_originalViewDef[$key]['label'])) {
                $availableFields [$key] = array('name' => $key, 'label' => $this->_originalViewDef[$key]['label']);
            } else {
                $availableFields [$key] = array(
                    'name' => $key,
                    'label' => isset($def ['label']) ? $def ['label'] : $def['vname']
                ); // layouts use 'label' not 'vname' for the label entry
            }

I believe that when the Studio loads up the layout view it gets validFields (these are fields that are studio !== false) which you would think would stop the field in question from appearing. However it’s that secondary logical operater isset($this->_orginalVieDef[$key]) which allowing that field to pass through and thus appear when it shouldn’t.

Now going into a deeper dive this _originalViewDef actually is created here:

github.com

salesagility/SuiteCRM/blob/706fd7b7a87cdcaa5f2114028f9e5dc2b243f65b/modules/ModuleBuilder/parsers/views/DeployedMetaDataImplementation.php#L234


    }
    if ($loaded === null) {
        throw new Exception(get_class($this) . ": view definitions for View $this->_view and Module $this->_moduleName are missing");
    }
}


$this->_viewdefs = $loaded;
// Set the original Viewdefs - required to ensure we don't lose fields from the base layout
// Check the base location first, then if nothing is there (which for example, will be the case for some QuickCreates, and some mobile layouts - see above)
// we need to check the custom location where the derived layouts will be
foreach (array(MB_BASEMETADATALOCATION, MB_CUSTOMMETADATALOCATION) as $type) {
    $sourceFilename = $this->getFileName($view, $moduleName, null, $type);
    if ($view == MB_POPUPSEARCH || $view == MB_POPUPLIST) {
        global $current_language;
        $mod = return_module_language($current_language, $moduleName);
        $layout = $this->_loadFromPopupFile($sourceFilename, $mod, $view);
    } else {
        $layout = $this->_loadFromFile($sourceFilename);
    }
    if (null !== ($layout)) {
        $this->_originalViewdefs = $layout;

It seems that studio ALWAYS look to the original view defs which are in modules/Accounts/metadata etc etc then breaks… surely you would think it should look at custom first? However I still don’t think this will solve everything.

But definitely not able to resolve this as expected.