Allow a meaningful business attribute to be used to uniquely identify categories

[apiuser]

Feature request from joshdifabio, posted on GitHub Apr 11, 2016

Products can be uniquely identified by their SKUs, which have meaning to a business, but for categories there is no such business attribute in Magento; categories can only be identified by their integer ID, which has no business meaning. In Magento 1, this poses issues when attempting to integrate Magento categories with other platforms, for example Akeneo, because there is no way of relating the Magento category with the category in the other platform.

From what I can see, this is still the case in Magento 2.

So, I guess my question is this: Given a third party system which maintains category data in a format something like [code, name, parent_code, ...], how can we use the Magento 2 API to create and later update and delete categories using the provided code as a unique identifier?

If this isn't possible, then I think it needs to be. Most medium to large retailers have business identifiers for customers, categories, orders and many other things, not just products.

[apiuser]

Comment from convenient, posted on GitHub Apr 11, 2016

I've been bit by this problem quite a few times. Even attempted to solve it in M1.

Would love to see a proper solution baked into the core for M2.

[apiuser]

Comment from paales, posted on GitHub Apr 13, 2016

We've run into this problem multiple times when importing categories with AvS_FastSimpleImport. Some sort of external_reference, external_identifier or identifier would be nice.

[apiuser]

Comment from Vinai, posted on GitHub Apr 15, 2016

Adding a custom attribute is the usual way to solve the issue in Magento 1. Custom attributes and extension attributes work okay over the API for products. I haven't tried them with Categories, but I would think they should work, too. If they don't, it is probably more due to a bug rather then by design. Did anybody on this thread try category custom or extension attributes over the api?

[apiuser]

Comment from joshdifabio, posted on GitHub Apr 15, 2016

Adding a custom attribute is the usual way to solve the issue in Magento 1. Custom attributes and extension attributes work okay over the API for products. I haven't tried them with Categories, but I would think they should work, too. If they don't, it is probably more due to a bug rather then by design.

To be clear, this is about identifying categories by an attribute other than entity_id, not simply accessing and updating a custom attribute.

We are saying that it should be possible to perform category updates, deletes, etc., without knowing the entity_id of a category, instead using a business attribute to identify the category.

Are you saying that you think this is already possible?

[apiuser]

Comment from pboisvert, posted on GitHub May 03, 2016

@antboiko please capture improvement for 2.x backlog if not already done

[apiuser]

Comment from antboiko, posted on GitHub May 04, 2016

Hi @joshdifabio , thanks for your inquiry. I've created internal ticket MAGETWO-52491 for this improvement and added it to the backlog.

Best, Anton.

[apiuser]

Comment from joshdifabio, posted on GitHub May 04, 2016

Thank you. Please also consider the implications for other API actions which reference category ID's, such as updating product-category associations via the product API. When third party platforms, such as Akeneo, tell us which categories a product is associated to we currently have to map each of the business category identifiers to a Magento category ID before we can update the product via the API. In this case, Magento is not doing a good job at reflecting the way businesses manage their data.

It's worth remembering as well that this issue is not isolated to category ID's. Consider product attribute options: in Magento 1, for some attributes we have to specify option ID's when updating products via the API, which are integer values which have no meaning outside of Magento. It would be better if these values were instead strings which are provided explicitly. For example, instead of setting colour = 1, where 1 is the option ID relating to the colour red, it would be far better if we were able to set colour = red, where red is the option code relating to the colour red, and the locale-specific labels for the red colour are specified in the admin panel, as they are now, but with the current auto-increment integer option ID's replaced with string codes.

I realise this is potentially a large, sprawling issue, as Magento uses auto-increments all over the place, but I think addressing these issues represents an important step in improving Magento.