Dear support,
we met a problem with the field mapping of the gender attribute to Magento.
When a customer logs in, even if the values get correctly modified into Observer/DefaultCMSSyncFieldMapping.php ,
switch ($gigyaProfile->getGender()) {
case 'm':
$customer->setGender('1');
break;
case 'f':
$customer->setGender('2');
break;
default:
$customer->setGender('3');
}
the value that gets saved into Magento is 0.
I found out that in Model/MagentoCustomerFieldsUpdater.php the method setAccountValues(), even if the correct account with modified values gets passed as a parameter, in the following piece of code you take the value from Gigya account
foreach ($gigyaMapping as $gigyaName => $confs) {
/** @var \Gigya\GigyaIM\Helper\CmsStarterKit\fieldMapping\ConfItem $conf */
$value = parent::getValueFromGigyaAccount($gigyaName); // e.g: loginProvider = facebook
to set it later.
In the case of gender attribute this causes the 'm', 'f' or 'u' values to get set into Magento that do not recognize them and sets 0.
Dear support,
we met a problem with the field mapping of the gender attribute to Magento.
When a customer logs in, even if the values get correctly modified into Observer/DefaultCMSSyncFieldMapping.php ,
the value that gets saved into Magento is 0.
I found out that in Model/MagentoCustomerFieldsUpdater.php the method setAccountValues(), even if the correct account with modified values gets passed as a parameter, in the following piece of code you take the value from Gigya account
to set it later.
In the case of gender attribute this causes the 'm', 'f' or 'u' values to get set into Magento that do not recognize them and sets 0.