Ok, so I've commented and posted over the last few posts about some "ideas" that could be implemented. Here is what I understand and then from there, you may need to adjust, choose or otherwise revise how things are done.
First of all, back in post #4 I described how the information needs to be listed within v_categories_name_1 to place a product in a sub-category of a category...
Having a v_categories_mame_1 field populated as described there for a product row will place in (if a new product) or link to (if already in the database) that category path.
Now with that information/knowledge, if the vendor provides a product/product update and assigns it to category "Foo", then when it is first added to the database it will only exist in category "Foo". But, if the product has been stored in category "Foo" and also has been linked to category "Wid^gets^Many", then whatever information has been updated about the product will be seen everywhere that it is linked including in "Wid^gets^Many". Now, you say, but I don't want the category "Foo", so disable that category (but keep the product active) and when the customer will in a round about way be able to find the product only in "Wid^gets^Many". But... There is one other thing about that situation... If the customer is not really supposed to know about the category "Foo", then the master_categories_id needs to be updated to a category to which they are to readily have access.... This can be done by having the product listed two times in a file where the first time reassigns the v_master_categories_id to the "Wid^gets^Many" category (v_status of 7 with v_categories_name_1 of "Wid^gets^Many") and the second time to "add" the product to its vendor supplied category (v_categories_name_1 of "Foo").
The importance of this last action is so that the canonical URL (Single address to uniquely get to this one product no matter in how many categories it is linked) will be in a category that is customer accessible.
As far as the database, a category has a parent category. If that parent category is 0, then the category is located immediately off the top of the category list. Further, there is an expectation that any category looking at its parent and its parent's parent, etc... doesn't end up in a loop. (e.g. would be bad if category 3's parent is 2, whose parent is 1, whose parent is 3) That is an unnatural condition, but when people meddle with the database they could cause that sort of condition.
So, there are options... You could link all of your product to the desired category(ies), by uploading a "modified" file of what the vendor has provided where the only information in the file is the unique key (v_products_model in a default install) and the v_categories_name_1 field (if that's all you want to modify), I say that, but I think there has been comment that the v_status column may need to also be included which is something I have for the next version to address along with the products_type (sorry I digress), anyways, with the unique key and the field(s) to change or retain, that file will perform the action(s) of linking the product to the category(ies) desired. If in that file all of the status for a unique product is set to 7 then that category will become the master category. Suggestion would then to be again upload the vendor provided file and the product would be linked to the vendor defined category(ies). Disable the vendor provided categories that are not to be shown to the customer. Now when updates to those existing product are made, the update(s) will be shown to the customer. If a new product is provided, well, it will appear in the vendor provided category (visible from the admin), but not be linked to a desired category and that new product would need to be "reassigned" in a similar way as above.
There are other methods of doing this though I can't think of any single solitary silver bullet, but a lot of it depends on what you have accessible from the vendor's site, how you manage obtaining new files to update the product, how many such vendors are used, the possibility of additional unique code, categories to be used and how to assign product to them, etc... Need to really really really sit down and plan on what you have on the one side, what you want to have on the other side and how much work can be automated between the two... The more time you spend on doing "routine" tasks, the less time you have to really run your store...
Bookmarks