Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 2.2.5
-
Fix Version/s: 2.2.6
-
Component/s: None
-
Labels:None
Description
Per IRC session with dlobo:
Symptoms:
1. Export of any custom data field would give "custom_xx" as the column header, where xx is the field id, and no data in the column
Additional Info:
1. If the "exportableFields All" cache key was reset by adding/deleting a custom field, the export would work as expected
2. The "exportableFields All" cache key would then be truncated to a shorter array of data by any contact edit operation, and the export column would be erroneous
Fix steps:
1. CRM/Contact/BAO/Contact.php patch by dlobo (patched copy of Contact.php from 2.2.5 release attached)
2. Alter table civicrm_cache to make `data` field longtext (allowing for more cached data for lots and lots and lots of custom fields)
Symptoms:
1. Export of any custom data field would give "custom_xx" as the column header, where xx is the field id, and no data in the column
Additional Info:
1. If the "exportableFields All" cache key was reset by adding/deleting a custom field, the export would work as expected
2. The "exportableFields All" cache key would then be truncated to a shorter array of data by any contact edit operation, and the export column would be erroneous
Fix steps:
1. CRM/Contact/BAO/Contact.php patch by dlobo (patched copy of Contact.php from 2.2.5 release attached)
2. Alter table civicrm_cache to make `data` field longtext (allowing for more cached data for lots and lots and lots of custom fields)
two issues:
1. the data field in civicrm_cache was not big enough to hold all the custom data of the install (11 groups, 171 fields)
2. the exportableFields function had a few minor bugs (which i dont think are related to issue but was good to clean up)