This one is a bit tricky to replicate, but it should be ok with the following instructions.

1. Create a new attribute "ordering_test" of display type "Radio buttons" (Checkboxes also shows the same problem, others I haven't tested)
2. Add 2 options: O1, O2 (in this order)
3. Add the attribute "ordering_test" to a (new or already existing) product
4. You can display the product node now and you will see the options appear with O1 first
5. Now swap the default ordering of the two options (admin/store/attributes/x/options) and save the change
6. You can display the product node again now and you will see the options appear still with O1 first
7. Now look at the options editor in the product node (node/x/edit/options) and you will see that they appear in reversed order with O2 first

behind the scenes:
in the database uc_product_options the ordering of the two options is not set resp. set to 0.

so the question is which one of the following is the intended behaviour?
when the ordering for an attribute was never set,
a) then the default ordering of the moment the attribute was added to a product applies
b) then the current default ordering applies

If we continue the experiment from above..
8. Add the attribute "ordering_test" to another product
Then you will see that now actually the ordering values in uc_product_options get set. Which means that some code has already decided for a).

Comments

TR’s picture

Status: Active » Closed (duplicate)

To answer your question, the intended behavior was "a)". Once attributes/options are set for a particular product, changing the default attribute/options is not supposed to change any individual products. The use case is, what if I have a "color" attribute with 30 different options. But each of my products is available in only a few of those 30 colors. I have to do a lot of work to customize the attribute/options combinations on each product, so I do NOT want changes to the default attribute/options to overwrite all my work! Now, I know there are some case where you DO want to push any default changes down to all your products, which is an open issue being discussed in #298395: Let admin push class attribute/option changes out to existing nodes. Please visit that issue and help out if you want to see this change implemented.

xibun’s picture

Title: Ordering of attribute options - default logic » Ordering of attribute options - not saved when added to product before forcing order
Version: 6.x-2.0-rc7 » 6.x-2.2
Status: Closed (duplicate) » Active

Hi TR,

missed your reply as I normally only look at "open issues"...

ok, so intended behavior is a) -> in that case I can define the bug more explicitly (it was only implicit in my initial post since I was missing this answer)

here we go:
in the moment we add the attribute to the product the order is O1, O2 (step 2 & 3). But when I go to the options editor in the product node (see my step 7.) then O2 is listed first!

solution: even for "new" attributes the ordering should be set when being added to a product. let me know when the bug is still not clear.

TR’s picture

Can you look at #640928: Inconsistent attribute ordering and see if that fixes it?

xibun’s picture

Tried the patch -> doesn't fix the problem described here.

Problem remains "in the database uc_product_options the ordering of the two options is not set resp. set to 0." when adding the attribute to a product before forcing an order.

One could say: "it's ok that options have no order set" - but then the logic on how to display such options should be consistent - right now it seems wrong in the options editor of the product node (node/x/edit/options) as it seems to depend on the *default* ordering of the product in such case.

sevenfish’s picture

same problem.

Is it fixed?

longwave’s picture

Status: Active » Closed (works as designed)

Not sure what the bug is/was here, and I can only reproduce the intended behaviour described by TR.