Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Acts as List shuffling on zero item on Variants #7996
When reordering a list in spree backend, it uses a zero index as the position for items in the list. One example of this is on variants. This makes the list position indexes run from 0 to N-1.
If you later make ANY update to the item at the zero position (not just reordering), it is moved to 1 and the item at 1 is moved back to 0, swapping those two items.
The result is that we have items that inadvertently reorder.
This issue impacts stores that rely on a specific ordering of varaints (or other reorderable object) since the first and second items in that list can reorder.
The list order should remain accurate for the first two items even if a property on either of them is touched.
Item 0 and item 1 are flipped.
I think we have two options. One is to change the implementation of sortable in the JS to use a starting index of 1 instead of 0. The other is to update our use of
Here's a simple fix we could drop in the JS in backend/admin.js (just adding + 1 to the position)
A different solution which I like less is to update the ResourceController:
Steps to Reproduce
@damianlegawiec I'm curious for your take on the better approach to fix this when considering how to handle lists that could be in either a zero first or 1 first orientation now.
One thought is to go w/ 1 first (fix the JS) and then have a migration that does an update of all product variants where there is one in product's list that has a zero.
We could ignore the migration since some stores may have some assumption built into their store about the starting index (or a dependency on specific positions). In playing around with this, the JS fix will not successfully overwrite an existing 0 due to the way acts_as_list updates neighbors while updating via
I'd say let's fix the JS not the acts_as_list inclusion. Then, unless you tell me there are no backwards compatibility issues with updating list positions in the migration, leave the migration to the individual stores. Any new products will behave correctly, but stores would need to update their positions to start at zero with a bit of sql like: