Extension Framework does not contain all changed Field Properties

[hiesscher]

Issue

On Adding a custom Field on a Module, like Accounts, not all Properties of the Field are written at
\custom\Extension\modules\Accounts\Ext\Vardefs

On Adding Field "KundenNr" on Accounts Module, the File "suitecrm_data/public/legacy/custom/Extension/modules/Accounts/Ext/Vardefs/_override_sugarfield_kundennr_c.php" looks like:

<?php
 // created: 2024-11-04 10:26:17
$dictionary['Account']['fields']['kundennr_c']['required']=true;
$dictionary['Account']['fields']['kundennr_c']['merge_filter']='disabled';

 ?>
```

### Possible Fix

_No response_

### Steps to Reproduce the Issue

```bash
1. Add a Field on Accounts Modul
2. View the Extansion File at: \custom\Extension\modules\Account\Ext\Vardefs
3.
...
```


### Context

On Exporting changes on Studio an Importing on another Installation the Fields are not added on Targetsystem like reported her: https://github.com/salesagility/SuiteCRM-Core/issues/532
 

### Version

8.6.2

### What browser are you currently using?

Chrome

### Browser Version

Version 130.0.6723.69 (Offizieller Build) (64-Bit)

### Environment Information

MariaDB, PHP 8,2

### Operating System and Version

Windows 10

[pgorod]

Do you your logs show any relevant messages during the export process?

[hiesscher]

Log not contains anything on export-Process.
If I understand concept of Export, the Process just Zip the Content of "custom"-Folder.
So I think, the Issue is at Extension-Framework, while Add/Modify Fields.
It just not write all Field-Properties to custom Folder.

[pgorod]

Do you think your bug could be the same as this one?

salesagility/SuiteCRM#10538

Maybe try applying that fix and testing again

[hiesscher]

I think it's even worse than that.

I have now done the following test:

this file
public/legacy/custom/Extension/modules/Accounts/Ext/Vardefs/_override_sugarfield_application_c.php

has this content:

$dictionary['Account']['fields']['application_c']['inline_edit']='1';
$dictionary['Account']['fields']['application_c']['labelValue']='Application';
$dictionary['Account']['fields']['application_c']['len']= 255;
$dictionary['Account']['fields']['application_c']['source']= 'custom_fields';
$dictionary['Account']['fields']['application_c']['name']= 'application_c';
$dictionary['Account']['fields']['application_c']['vname']= 'LBL_APPLICATION';
$dictionary['Account']['fields']['application_c']['type']= 'varchar';
$dictionary['Account']['fields']['application_c']['massupdate']= '0';
$dictionary['Account']['fields']['application_c']['default']= '';
$dictionary['Account']['fields']['application_c']['audited']= false;
$dictionary['Account']['fields']['application_c']['unified_search']= false;
$dictionary['Account']['fields']['application_c']['len']= 255;

After changing a property in the Studio, e.g. required, the field DISAPPEARS in the Studio and from the View.

The file looks like this after saving:

<?php
 // created: 2024-11-08 10:38:56
$dictionary['Account']['fields']['application_c']['required']=true;
$dictionary['Account']['fields']['application_c']['merge_filter']='disabled';

 ?>

After restoring the file and QR&R, the field is visible again.
--> You cannot edit any fields via the studio that were transported into the system by Module Loader

[pgorod]

Do any of these behaviors change after applying my fix?

[hiesscher]

After applying the Fix the File looks like this:

<?php
 // created: 2024-11-08 12:00:47
$dictionary['Account']['fields']['anwendung_c']['name']='anwendung_c';
$dictionary['Account']['fields']['anwendung_c']['required']=true;
$dictionary['Account']['fields']['anwendung_c']['inline_edit']=true;
$dictionary['Account']['fields']['anwendung_c']['merge_filter']='disabled';

 ?>

But the behaviour still is the Same, Field Disappears from Studio.

[pgorod]

I didn't test that fix with custom modules, maybe there's still something to be improved in those conditions.

My approach there was "first, do no harm", meaning: what I changed improves some cases, and doesn't add any risks that I can think of. But I did not check every other possible case because that is complex code...

[hiesscher]

Yes, thanks for trying to help.

Maybe there is someone who can reproduce the behavior to show whether the installation is ok.