[WIP] Restrict autolink to current file

[barryvdh]

I have a webshop with many products, and some have short sku's. When importing via Magmi, I use automatching of sku's with the same start.
Is it possible to match the sku's only in the current file?
I did some tweaks, to also keep track of the skuList for the 'auto' matchmode, and do a link like this, instead of autoLink.

This hasn't been thouroughly tested, but what do you think of the idea/implementation?

[barryvdh]

@dweeves Any feedback on this?

[dweeves]

Hi , i wanted to be sure it was "safe". so basically you will only use "simples" declared before the current configurable (not others). in that case it's ok for me but i cannot find the difference with "simples before configurable" case.

[barryvdh]

Does 'simples before configurable' also work when I have simple products that shouldn't be matched?
Ie.

• standalone simple product 1
• standalone simple product 2
• simple product for configurable 3, part 1
• simple product for configurable 3, part 2
• configurable product 3

Don't 1 and 2 also get connected to product 3?

[dweeves]

ah ok, so i begin to understand better.
Using "autolink" based on sku similarity + restricting it to "above simples" would give the expected result. Then comes the way to make this complex interaction understandable by the end user.

I'd rather expose it as a limitation of "simples before configurable" (i prefer this) since "simples before configurable" is an understable option that is already used by many user.
So i'd advocate for a new checkbox linked to "simples before configurable" one that would have "auto filter on configurable sku" or something like this.

Exposing it as "restict to simples of current import " is not clear in fact, since to work, your import mode needs simples before configurable structure as a prerequisite and don't perform matching over all file (hopefully ;) )

[barryvdh]

Yes indeed, it's just to restrict the configurables from matching all over the existing products, to only the current file.
I can see your confusion, but doesnt the auto matching also already require that it reads the simples before configurables, at least on the first run?

[dweeves]

no , "basic" automatching is input data independent more or less.
it would match all existing simples in magento DB matching configurable sku
known at the time the configurable is found in the input file.
if you have put some in your file after the configurable & they don't exist
yet in magento they won't be matched.
If skus are any place before the configurable in the file, or were imported
before then they will be matched.

2014-06-12 18:16 GMT+02:00 Barry vd. Heuvel [email protected]:

Yes indeed, it's just to restrict the configurables from matching all over
the existing products, to only the current file.
I can see your confusion, but doesnt the auto matching also already
require that it reads the simples before configurables, at least on the
first run?

—
Reply to this email directly or view it on GitHub
#36 (comment).

[barryvdh]

Yes okay. So how to proceed, should I change the naming of the checkbox/functions, or do you want me to change more?

[dweeves]

I was thinking about the case you wanted to resolve with the pull request and i'm quite convinced it's an invalid "generic" case.

Let me explain:

• automatch only will do the good associations for all simples based on configurable sku. limiting association to "above" is not recommended since it may miss some already existing items in magento DB.
• "simples before configurable" only needs to have a well formatted file which is not the case in your sample.
• nothing prevents doing 2 imports, one for configurable & associated simples, one for standalon simples only. or putting the standalone simples at the end of a mixed import file.

So my thought is your code modification is trying to find a workaround to a misusage.

[barryvdh]

I do agree that the problem could be solved by either:

• Use a good structure in your sku's, like for configurable, -blue-12p for simples, but there are some store with a lot of different (shorter) codes that can accidentally match.
  • Seperate the simples from configurables in different files (or the end), but in this case I had a store with many products/categories, and they grouped their import-files by category and sort based on some attributes, instead of thinking about how to import it (because that's easier to maintain).

But I do agree that in an optimal situation, this wouldn't bee needed.

[dweeves]

ok, so that's a very partcular setup constraint and i admit automatch may be too broad for overlapping configurable skus. since i can't find any simple way to pass trough such a constraint , here are the changes that would be necessary to make your feature understandable:

• make the extra combo box dependent of "simples before configurable" one. (should show up only if "simples before configurable" is set.
• find a proper label like "filter simples based on configurable sku"

that should be sufficient for me to accept the pull. sorry for being that long to accept it but i really had to understand & discuss why it was necessary.

[barryvdh]

OKay no problem :)

I'll look into it as soon I have some free time. It isn't a problem directly because I just use this already, but it would be nice to be able to do this to keep up with new changes etc.

[barryvdh]

Instead of creating a new option, I made this a sub-option of the 'simples before configurables', as suggested. Continued in #170