As said in http://drupal.org/node/488422#comment-3875846, that is about adding an api on attributes, which is great. But also the other thingies on: http://www.tsd.net.au/blog/understanding-ubercarts-attributes have some attention. The 4 thingies referred to on that page are important to make Ubercart the best eshop there is I think!

1. Form a User Interface (UI) perspective long and tedious. There is no interface for creating attribute options on mass.
==> http://www.ubercart.org/project/node_import_uc_product
==>related to attributes these threads are busy with this:
http://www.ubercart.org/project/node_import_uc_stock and
http://drupal.org/project/uc_feeds

2. Changes to the Product Class attribute/options doesn't reflext in existing instances of that class.
==>related to attributes this thread is busy with this:
http://drupal.org/node/298395

3. When new Attribute Options are added then the uc_product_adjustments table has to be flushed, losing all user input and recreated again (well it doesn't have to be but thats the laziest way to code it else you'd have to pull all the records out so you could unserialise the options just to see whats already there, one of the many disadvantages to not Normalising your DB schema.
==> May be the API added on can deal with this: http://drupal.org/node/488422

4. Mostly this not consistent with (A) in that the realisation that the SKU is the real Product identifier in that each SKU represents a model in the stock room, the physical product. The Product with attributes is an illustration presented to the customer to make navigating the long list of every product combination easier to understand. Its conceptual not actual. In order to keep with (A) one would have to then create a Node for each Attribute Option combination. This could be an option but then you'd have the replication of standard Node data like Title & Description for each, which would be a maintenance problem trying to keep them all in sync (and then translated!).
==> Having the attribute apart from product I think deals with this. Also this architecture is seen in other eshop products also.
Likewise these module has some options:
http://drupal.org/project/uc_subproduct or may be
http://drupal.org/project/uc_node_checkout

This is just a sort of collection of thingies done about the stuff explained on http://www.tsd.net.au/blog/understanding-ubercarts-attributes.
The 4th thingie I am not exactly sure what is meant by that.

greetings, Martijn

Comments

univate’s picture

univate commented
Title: Starting discussion about 4 important changes/thingies about Ubercart » Ideas for improvements to the attribute system
Category: support » feature

Just giving this a more meaningful title.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

I'll throw in a thing to consider. I would like the ability to define SKU's that are not simply a "one of each of every option combination available".

I'm using a highly modified version of uc_cano (http://www.ubercart.org/project/uc_cano), which allows for a product to only show certain attributes and options depending on previously selected attributes.

The use case is simple. Our store offers a subscription to their magazine, which it technically one product. However, the price on that product varies considerably depending on which country you are in, and how long you would like to subscribe for.

So we have 5 attributes assigned to the product: Country of origin(us, can, intl), US durations/prices, Canadian Durations/prices, and International durations/prices, and finally which issue the customer would like to start with.

The form and all of its requirements handling works wonderfully. Any customer only ever sees 3 of the attributes depending on what they select. The issue is we cannot assign a SKU for "US, 3yr" subscription because the sku system assumes that *every* attribute available for selection will have an option selected. In our case there will always be two attributes that never get selected, additionally we have one attribute that really has no bearing on our SKU's.

summit’s picture

summit commented

Hi, would love to see your highly modified uc_cano, would you consider attach it to a comment?
May be I can use it for my usecase, see: http://drupal.org/node/1011482?
May be the guys from Ubercart can do also something with it!

Wouldn't http://drupal.org/project/uc_attribute_cck be of help to your problem?

Happy New Year! greetings, Martijn

tr’s picture

tr commented
Status: Active » Postponed (maintainer needs more info)

A general catch-all issue is not going to be too useful. You should break this out into multiple feature requests.

Re:

1) Everything can be improved, of course. If you have some specific suggestions, please open a separate feature request and cite some use cases where the current system does not meet user needs. Note that the original blog post is NOT talking about node import issues, rather it's referring to the UI for creating attributes and options, so the URLs you cite are irrelevant.

2) This is by design, for some very good reasons. If you want to extend the capability here without losing this feature, please participate in #298395: Let admin push class attribute/option changes out to existing nodes - that other issue is the appropriate place to discuss this, and it will not be changed unless and until some members of the community review the proposed patches.

3) I have no idea what this means.

4) Describes an alternative architecture which introduces as many problems as it tries to solve. I don't see any valid argument for one being "better" than the other. Specifically, when the combinatorics get large (e.g. 10 attributes with 2 options each) you're proposing that the admin has to create more than 1000 nodes for each product. I don't see how that helps anything. Additionally, consider the problem of translating 1000+ nodes instead of just 1 ... I don't see any sense in having a general discussion about the attribute system unless you have a concrete proposal that significantly improves the capabilities - and even then this represents a major change that will not be made in Ubercart 2.x because it will break every contributed module.

tr’s picture

tr commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

No follow-up comments or discussion for three months? I'm going to close this issue - if someone wants to put forward specific proposals feel free to open a new issue.