Hallo Community,
i am new with SuiteCRM.
We use Suite CRM 8.6.2 an facing exactly the Same Issue discused in this topic.
Two years later, this behavior still seems to be the reason for some issues reported, like:
opened 03:32PM - 25 Jul 24 UTC
Type: Bug
Priority:Critical
Area: Studio
Status: Team Investigating
Severity: Major
### Issue
Repair & Rebuild is not syncing vardefs with DB.
I exported cust… omizations form one install to another. Imported the changes. The vardefs/metadata and language files came over. In fact the front end editview/detail view came over. Upon further investigation the fields are not in studio and have not been created in the _cstm table for the module.
There are no obvious errors in the log or php log.
### Possible Fix
_No response_
### Steps to Reproduce the Issue
```bash
1.Add custom fields to one install of SuiteCRM 8
2.Export them from studio
3.Import them with module installer to a new SuiteCRM install
4.Do an R&R (confirm all vardefs sync'd with DB)
5. See no vardefs are sync'd with the DB.
...
```
### Context
In an immediate context, the export/import customizations feature in Studio does not work. However, in a larger context, R&R is not working as expected and not syncing vardefs with the DB.
So the vardefs are not being sync’d with the DB. So I don’t think its and angular thing.
The have been copied to:
…/public\legacy\custom\Extension\modules\Project\Ext\Vardefs\
I can also see them here:
…\public\legacy\custom\modules\Project\Ext\Vardefs\vardefs.ext.php
But not in DB, and not in Studio.
Leads me to believe the R&R is not working properly in SuiteCRM 8 to sync the vardefs with the DB.
### Version
8.6.1
### What browser are you currently using?
Chrome
### Browser Version
_No response_
### Environment Information
PHP 8.2
### Operating System and Version
Centos 7
and my: Extension Framework does not contain all changed Field Properties · Issue #565 · salesagility/SuiteCRM-Core · GitHub
So based on the Answer:
When you create a new field from the studio, the field definitions are stored in a database table called “fields_meta_data”.
What is the cause of this?
Why not writing all field Attributes to vardef File when fields created by Studio so they can be exported an loaded or managed by Git and addional write to Database (or in consequence of QR&R)
What negative consequences by changing this bahaviour?
Thanks.
pgr
10 November 2024 09:59
2
I think it’s just legacy behaviour that would be too much work to change. I say this in relation to the existence of the fields_meta_data
table, not to the bug you’re discussing - that one should be fixed, of course.
But that architecture has been there since the SugarCRM days and it’s would take some effort to refactor.
Thanks for reply!
I had not tested it yet, but writing out the Attributes seams to be easy as this:
https://github.com/salesagility/SuiteCRM-Core/blob/582636a2a77f2fe0241a69bd59f0daf11b139594/public/legacy/modules/DynamicFields/DynamicField.php#L681
foreach ($field->vardef_map as $property => $fmd_col) {
//Skip over attributes that are either the default or part of the normal attributes stored in the DB
if (!isset($field->$property)
/* || in_array($fmd_col, $column_fields) || in_array($property, $column_fields) */
|| $this->isDefaultValue($property, $field->$property, $base_field)
|| $property == 'action' || $property == 'label_value' || $property == 'label'
|| (substr((string) $property, 0, 3) == 'ext' && strlen((string) $property) == 4)
) {
continue;
}
$to_save[$property] =
is_string($field->$property) ? htmlspecialchars_decode($field->$property, ENT_QUOTES) : $field->$property;
}
Following the thread above this should have the result, what to do by hand.
@Ramblin
Studio is tool for current installation. If you want to use git I recommend creating file(s) in custom directory.
Create file in directory: custom/Extension/modules/<module_name>/Ext/Vardefs/<file_name>.php
– It works for all modules (system and custom).
– Several fileds can be in one file.
– You can redefine parameters of system modules fields.
Write description of field, for an example:
$dictionary["<modile_name>"]["fields"]["number"] = array (
'required' => true,
'name…
The only difference would have to be the file name. ( /override […].php)
What am I missing?
pgr
11 November 2024 10:12
5
That looks very similar to this fix I made recently
salesagility:hotfix
← pgorod:patch-studio-fix
opened 10:21AM - 04 Oct 24 UTC
## Description
Studio was not saving field properties correctly. This bug has b… een there for years...
## How To Test This
1. Enter Studio
1. Enter a module (such as `Cases`)
1. Click `Fields`
1. Enter a field (such as `Description`) to see its properties:

5. Change one of the properties,
6. Save
7. Exit that screen to the field list
8. Enter the same field again
9. Change a different property
10. Save
11. Exit and go back in
12. Both properties should be retained, instead of the first one you changed being reverted to a default.
The bug caused each subsequent save to throw away the previously saved non-default properties. I guess for a long time people work around this by just changing one property, or repeating the saves when they were mysteriously throw away...
During tests, it might be helpful to keep separate terminals watching these two files:
```bash
watch -n 1 cat custom/modules/Cases/Ext/Vardefs/vardefs.ext.php
watch -n 1 cat custom/Extension/modules/Cases/Ext/Vardefs/_override_sugarfield_description.php
```
Note that the `Save` action already includes a QR&R, so it is not necessary to do it separately. That's why the contents of those two files will appear in sync after each save.
There's a downside to this PR, although it is really not problematic. Some fields that were not changed, and still have their default values will be included in the saved files. This is because it is not trivial to know if a value is at its default - some of these things depend on configurable settings in other places in the system. So the conservative approach is taken: retain the values that were there when saved, even if it is not clear whether they are defaults and some redundancy occurs.
## Types of changes
- [-x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
### Final checklist
- [X] My code follows the code style of this project found [here](https://docs.suitecrm.com/community/contributing-code/coding-standards/).
- [ ] My change requires a change to the documentation.
- [X] I have read the [**How to Contribute**](https://docs.suitecrm.com/community/contributing-code/) guidelines.
Do you think they could be related?
I dont try it yet, but it seams you fix will writing out less Attributes to vardefs (no default values),
but what i want, is writing out more to vardef (all db-Attributes like “type” and “required”…) .
So basicly the same target (make vardefs better) but not similar effekt, i think.
pgr
11 November 2024 11:21
7
The conditions are complex and quite difficult to understand, but my change also makes SuiteCRM write more attributes to the vardefs.