Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to Import Dropdown Attribute #64

Open
saurabhliv opened this issue Jun 26, 2014 · 10 comments
Open

Unable to Import Dropdown Attribute #64

saurabhliv opened this issue Jun 26, 2014 · 10 comments

Comments

@saurabhliv
Copy link

Hi,

I'm using uDropship Marketplace Extension from Unirgy. It created an attribute called "udropship_vendor" whose properties are http://gyazo.com/830306d45fed760d56a5f2157881f123 . Now, when I import values for this attribute using Magento Default Import, it works fine. However, when I perform the same using Magmi, it creates new values instead of selecting the existing ones. Sample CSV for reference : http://gyazo.com/e74557836234e41a73f0c2eb52ead890

Kindly suggest.

@ckressibucher
Copy link

Perhaps related to my problems at #62 and #63 ...

@saurabhliv
Copy link
Author

Did you get a solution to it ?

@saurabhliv
Copy link
Author

Dweeves, please address this issue.

@saurabhliv
Copy link
Author

@dweeves Please advice. I'm stuck due to this issue.

@Viveur
Copy link

Viveur commented Oct 3, 2014

Hi, from what i can tell i'm experiencing the same issue (or a very similar one!) to Saurabhliv.

I can also confirm that this is a different issue to that fixed by Ckressibucher in his patch.

A brief description of the issue is: Importing certain dropdown (ie: select - and thus likely also multiselect) fields does not work as expected. Magmi creates unnecessary extra databases rows. Then when querying that dropdown's field the newly created option_id is returned rather than the value specified in the CSV.

In my case I noticed this behaviour with an attribute that was added by the Mageworx Custom Price extension and theorize that the issue may be specific to attributes that use a source model.

I've now spent a good few hours digging into the issue and here's what i've found...

Within my CSV is a column called: 'custom_price_allow' with the names 'Use Config / Yes / No'. These map to the integer values '2 / 1 / 0'.

In my 'custom_price_allow' column for each product I enter an integer (ie: 1 to represent Yes).

After importing my CSV file I can see that Magmi has added new rows to the tables:

eav_attribute_option & mag_eav_attribute_option_value

However, as the names & values are already fetched via a source_model I am not certain that creating these rows is necessary.

The main meat of the problem though is that when fetching the value of 'custom_price_allow' Magento returns the value of option_id that Magmi just created in the 'mag_eav_attribute_option_value' table rather than the value given in the CSV file.

I have tried adding a built-in dropdown field (tax_class_id) as a column in my CSV and this is not subject to the same behaviour and is imported normally - and no superfluous database rows created.

This leads me to believe it may be an issue with third party module generated attributes. It's possible that these modules are somehow incorrectly configured however it seems perhaps more likely that this is a bug and that Magmi does not handle these attributes correctly.

Finally if I go into the database and change the type of the 'custom_price_allow' field from 'Select' to 'Text' and then import, everything works correctly and fetching the value of the 'custom_price_allow' works as expected.

Any more info i can provide just ask and will be happy to provide.

Also many thanks for creating Magmi - even for organisations like ours with only a few products it's still super useful :)

@tmotyl
Copy link
Collaborator

tmotyl commented Aug 20, 2015

@bit32 Thanks for your investigation. I took it a little bit forward.
Indeed, Magmi is handling tax_class_id attribute differently than other attributes with custom source_model.
The code is in https://github.com/dweeves/magmi-git/blob/master/magmi/plugins/inc/magmi_defaultattributehandler.php#L313
As you can see, Magento build in source models are handled in this method, but custom source models are triggering the "default" part of the swich thus, creating new attribute value in the db.

@LittleBigDev
Copy link

Hi everyone !
Any news about this problem ? How did you guys handle it ? I need at least a workaround to keep going on my project. I even threw a message in a bottle there if you prefer...

@dweeves any thought about it ?

@jardinec
Copy link

Hi,

Just wondering if anyone has a solution or workaround.

I am using a custom Brands extension, and the attribute is populated from a source_model

I've tried everything i can think of with Magmi and just cannot get the relationship to work. Pretty certain its the same problems as the others in this thread.

How did you resolve it, anyone?

This is the definition of the field in the extension...

$setup = new Mage_Eav_Model_Entity_Setup('core_setup');
$setup->addAttribute('catalog_product', 'vesbrand', array(
'label' => 'Product Brand',
'type' => 'int',
'input' => 'select',
'source' => 'ves_brand/system_config_source_ListBrand',
'visible' => true,
'required' => false,
'position' => 10,
));

@mobilizer
Copy link
Contributor

I added support for udropship_vendor attribute to magmi_defaultattributehandler.php.

See: mobilizer@e9a14fa

I haven't found a more generic way. (Generic mapper itemprocessor plugin is not enough, since Magmi always tries to add option values, for unknown values. And it does not find the values from the source_model.)

Feedback welcome!

@nmella
Copy link

nmella commented May 5, 2016

I added support for udropship_vendor attribute to magmi_defaultattributehandler.php.
See:
mobilizer/magmi-git@e9a14fa

Thanks ! It worked great !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants