Problem saving data from custom fields

[saclaudio]

Hi,

I had created 6 customs fields in the ACCOUNT module. 5 fields are DROPDOWN and 1 field is DECIMAL.
The EDIT layout from ACCOUNT was changed with the insertion of the new customs fields.
In the ACCOUNT EDIT panel I have CUSTOMS and DEFAULT fields. When I make any change or crate a new account, only the DEFAULTS fields are changed. Then customs fields taht I create are not altered or remaing unchanged.

Can anybody help me?

Thanks,
Claudio

[andopes]

Hi Claudio

If you have access to the database and source code do the following:
1. Check if there are records into fields_meta_data table related to these fields;
2. Check if the fields had been created into accounts_cstm table;
3. Check if the fields had been added to the cache/modules/Accounts/Accountvardefs.php file
4. Debug the function save in the script modules/DynamicFields/DynamicField.php, print the sql for inserting or updating in the databse.

Attach in your next post the content of the file cache/modules/Accounts/Accountvardefs.php.

Cheers

[henkel]

Hello there!
It seems I have nearly or exactly the same problem as saclaudio.
For my accounts module I created some dropdowns,textfields and then a decimal field for annual revenue and an integer field with len=4 in order to save the year for the revenue. I placed the fields onto edit and detail view, then used Admin->Repair and made sure fields are shown and usable. When I filled in some testdata the fun began nothing was saved!
Following andopes´ instructions i had a look at the MySQL Database via phpMyAdmin.

If you have access to the database and source code do the following:
1. Check if there are records into fields_meta_data table related to these fields;
2. Check if the fields had been created into accounts_cstm table;
3. Check if the fields had been added to the cache/modules/Accounts/Accountvardefs.php file
4. Debug the function save in the script modules/DynamicFields/DynamicField.php, print the sql for inserting or updating in the databse.
Attach in your next post the content of the file cache/modules/Accounts/Accountvardefs.php.
Cheers

1 > records for all fields can be found in fields_meta_data
2 > the intger and decimals fields have NOT been created in the accounts_cstm
3 > all fields had been added to the cache/modules/Accounts/Accountvardefs.php file
4 > sorry, i don´t fully understand what you mean by this

Here is a section of the accountsvardef.php containing the definition for an integer field

'umjah_c' =>      array ( 
'required' => '0',   
'source' => 'custom_fields',       
'name' => 'umjah_c',
'vname' => 'LBL_UMJAH',       
'type' => 'int',       
'massupdate' => '0',       
'default' => NULL,       
'comments' => '',       
'help' => '',       
'duplicate_merge' => 'disabled',       
'duplicate_merge_dom_value' => '0',       
'audited' => 0,       
'reportable' => 0,       
'len' => '4',       
'disable_num_format' => '1',       
'id' => 'Accountsumjah_c',       
'custom_module' => 'Accounts',       
'default_value' => NULL,     
),

Can someone help me with this problem?
Thanks in advance for your efforts!

[bent]

If you have access to the database and source code do the following:
1. Check if there are records into fields_meta_data table related to these fields;
2. Check if the fields had been created into accounts_cstm table;
3. Check if the fields had been added to the cache/modules/Accounts/Accountvardefs.php file
4. Debug the function save in the script modules/DynamicFields/DynamicField.php, print the sql for inserting or updating in the databse.
Attach in your next post the content of the file cache/modules/Accounts/Accountvardefs.php.
Cheers

I have exactly the same problem, only with custom fields in the contact module. As henkel I verified that

- records for all fields can be found in fields_meta_data
- the intger and decimals fields have NOT been created in the contacts_cstm
- all fields had been added to the cache/modules/Contacts/contactsvardefs.php file


Also I noted that:
- converting from the lead module will create the (not modifiable however) custom data values in the contact module,
- custom data from records created a long time ago are even modifiable,


So may it be that there is some bug the Studio that somehow hinders the newly created data sets to be modified via the edit view?

[andopes]

Hi all

Claudio
The zip file you attached didn't help me properly.
You could send me an answer just like henkel and bent.

henkel and bent, let me know the fields which had not been created.

Best regards

[bent]

Hallo André - thanks for giving input on this. To clarify the issue maybe

FIELDS
- all fields are created and are shown on detail and custom views
- the data fields that I have added and that do not work are "letter_salutation_c", "sex_c", "program_role_c"

DATA
- input and update of all default fields works perfect for all data sets
- input and update of all custom fields only work for older data sets
- input and update of custom fields once did work smoothly for months


LEAD->CONTACT CONVERSION
- works perfect - also for the data of the mentioned custom fields, however
- they cannot be saved after edit in the contacts-edit view afterwards

So I assume that some faulty code resulting from an studio export has done it to the custom module and somehow blocks the modification of the custom fields for all newly created data sets...

I just do not know where I can look for a solution...

[henkel]

henkel and bent, let me know the fields which had not been created.

Thanks so far for your help andopes, i really appreciate it.

Following are the definitions for the fields from accountsvardefs.php. I created these fields in studio and entries in accountsvardefs.php were created by Sugar.
The fields are:
- jmzah_c > a field contaning the number of employees
- jmjah_c > the year in which the mentioned employees were employed
- umsa_c > a field for annual revenue
- umjah_c > the year of the mentioned annual revenue
In Detail/ Edit View it looks like this:
Employees: xxxxxx in year: 2007
Annual Revenue: xxxxxxx.yy in year: 2007

@andopes: I hope this is the information you asked for : )

'jmzah_c' => 
    array (
      'required' => '0',
      'source' => 'custom_fields',
      'name' => 'jmzah_c',
      'vname' => 'LBL_JMZAH',
      'type' => 'int',
      'massupdate' => '0',
      'default' => NULL,
      'comments' => '',
      'help' => '',
      'duplicate_merge' => 'disabled',
      'duplicate_merge_dom_value' => '0',
      'audited' => 0,
      'reportable' => 0,
      'len' => '6',
      'disable_num_format' => NULL,
      'id' => 'Accountsjmzah_c',
      'custom_module' => 'Accounts',
      'default_value' => NULL,
    ),

'jmjah_c' => 
    array (
      'required' => '0',
      'source' => 'custom_fields',
      'name' => 'jmjah_c',
      'vname' => 'LBL_JMJAH',
      'type' => 'int',
      'massupdate' => '0',
      'default' => NULL,
      'comments' => '',
      'help' => '',
      'duplicate_merge' => 'disabled',
      'duplicate_merge_dom_value' => '0',
      'audited' => 0,
      'reportable' => 0,
      'len' => '4',
      'disable_num_format' => '1',
      'id' => 'Accountsjmjah_c',
      'custom_module' => 'Accounts',
      'default_value' => NULL,
    ),

'umsa1_c' => // 15 digits in total of which 2 are meant to be decimal digits
    array (
      'required' => '0',
      'source' => 'custom_fields',
      'name' => 'umsa1_c',
      'vname' => 'LBL_UMSA1',
      'type' => 'decimal',
      'massupdate' => '0',
      'default' => NULL,
      'comments' => '',
      'help' => '',
      'duplicate_merge' => 'disabled',
      'duplicate_merge_dom_value' => '0',
      'audited' => 0,
      'reportable' => 0,
      'len' => '16',
      'id' => 'Accountsumsa1_c',
      'custom_module' => 'Accounts',
      'default_value' => NULL,
    ),

'umjah_c' => 
    array (
      'required' => '0',
      'source' => 'custom_fields',
      'name' => 'umjah_c',
      'vname' => 'LBL_UMJAH',
      'type' => 'int',
      'massupdate' => '0',
      'default' => NULL,
      'comments' => '',
      'help' => '',
      'duplicate_merge' => 'disabled',
      'duplicate_merge_dom_value' => '0',
      'audited' => 0,
      'reportable' => 0,
      'len' => '4',
      'disable_num_format' => '1',
      'id' => 'Accountsumjah_c',
      'custom_module' => 'Accounts',
      'default_value' => NULL,
    ),

[Markus85]

Hello People,

I'm facing a problem with my contact person input,
When I'm creating a new contact person all the custom fields appear and can be filled in, but when i'm saving all the data, just a few inputs are saved. Does anyone know what my problem can be?

thanks!

Grts

[kuske]

It is a very simple issue.
If you create a new custom field of data type Decimal or Integer and if you do not set a Default value, a statement like that.

ALTER TABLE bugs_cstm ADD indicator_c FLOAT(18,2) DEFAULT ''

is used to add your custom field in the database.
THAT DOES NOT WORK!

If you set the Default value to a numeric value like 0 the statement will be:

ALTER TABLE bugs_cstm ADD indicator_c FLOAT(18,2) DEFAULT '0'
THIS WORKS.

I found the bug in 4.5.1 and 5.0.0, 5.1 I did not test yet.

[soedesve]

It is a very simple issue.
If you create a new custom field of data type Decimal or Integer and if you do not set a Default value, a statement like that.

ALTER TABLE bugs_cstm ADD indicator_c FLOAT(18,2) DEFAULT ''

is used to add your custom field in the database.
THAT DOES NOT WORK!

exactly that´s the problem ...

If you set the Default value to a numeric value like 0 the statement will be:

exactly that´s the solution ...

I found the bug in 4.5.1 and 5.0.0, 5.1 I did not test yet.

in 5.0.0g it still exists ...
I posted this Case and they created bug# 24141 on 2008-08-26, Targeted Release: 5.0.0h (I didn´t test it)