Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same Taxonomies in different stores #12019

Closed
chuckyuee opened this issue Mar 27, 2024 · 10 comments · Fixed by #12040
Closed

Same Taxonomies in different stores #12019

chuckyuee opened this issue Mar 27, 2024 · 10 comments · Fixed by #12040

Comments

@chuckyuee
Copy link

Context

Same Taxonomies in different stores, rails raise an error:

ActiveRecord::RecordNotUnique (PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "unique_permalink_per_locale"
DETAIL: Key (locale, permalink)=(en, categories) already exists.
):

Default store has a taxonomy named 'Categories', change to other store again create a taxonomy named 'Categories', then raise an error like above. These store are same locale 'en' but different currency and VAT rules.

Expected Behavior

Different stores had same Taxonomies.

Actual Behavior

Server error 500

Possible Fix

Maybe taxonomies can apply to all stores.

Steps to Reproduce

  1. Create a taxonomy in default store named 'Categories'
  2. Change to other store, same locale different currency and VAT zone, like US and UK country
  3. Again Create a taxonomy in default store named 'Categories'

Your Environment

4.8.0.Beta

@damianlegawiec
Copy link
Member

Thanks for reporting, I see this DB migration is to blame:

add_index :spree_taxon_translations, [:locale, :permalink], unique: true, name: 'unique_permalink_per_locale', if_not_exists: true

this should be a combined index onpermalink, locale, parent_idandtaxonomy_id`

@pkatek
Copy link

pkatek commented Apr 8, 2024

We are creating a shop for a client and there is a big problem with taxonomies.
We have a product store and there are products intended for the Slovak market, others for the Czech market and still others for the German market, and there are common products. Now, if we want to separate products using stores, we must have separate taxa, although they are already assigned and I do not see the need to separate them, and if I change/add new ones or items only for the German language, the names of the taxa are not visible in the rest of the products and this can be standardized. Is it possible to quickly fix this error? I wouldn't want the client to change the platform or wonder why there is a loophole in this topic.

Do you have another idea to solve the problem mentioned in this thread?

@pkatek
Copy link

pkatek commented Apr 8, 2024

@damianlegawiec I am definitely in favor of taxonomies being applied to all stores. Then the products will not show errors or holes in their names after changing the store.

@chuckyuee
Copy link
Author

chuckyuee commented Apr 21, 2024

Thanks for reporting, I see this DB migration is to blame:

add_index :spree_taxon_translations, [:locale, :permalink], unique: true, name: 'unique_permalink_per_locale', if_not_exists: true

this should be a combined index onpermalink, locale, parent_idandtaxonomy_id`

@damianlegawiec and @rafalcymerys parent_id and taxonomy_id not in table spree_taxon_translations. This table only store for mobility's translate column content. Can I remove these unique constraint?

table: spree_product_translations

  • REMOVE unique_slug_per_locale

table: spree_taxon_translations

  • REMOVE unique_permalink_per_locale

table: spree_taxons

  • REMOVE index_spree_taxons_on_name_and_parent_id_and_taxonomy_id
  • REMOVE index_spree_taxons_on_permalink_and_parent_id_and_taxonomy_id

table: spree_products

  • REMOVE index_spree_products_on_slug

@pkatek
Copy link

pkatek commented Apr 21, 2024

Please, do it xD i need this for my Client.

@damianlegawiec damianlegawiec self-assigned this Apr 21, 2024
@pkatek
Copy link

pkatek commented Apr 22, 2024

@damianlegawiec What are the possibilities for a fix to be released soon?

@damianlegawiec
Copy link
Member

damianlegawiec commented Apr 22, 2024

@pkatek

@damianlegawiec What are the possibilities for a fix to be released soon?

we're planning to fix this with v4.8 releasing this week/early next week, we're also reviewing other translation migrations

@chuckyuee
Copy link
Author

@damianlegawiec Thanks

@pkatek
Copy link

pkatek commented May 10, 2024

Hello!

What are our chances of completing this task?

mad-eel added a commit that referenced this issue May 14, 2024
* Use original column for the translatable fields in the default locale
* Remove migrations for transferring and deleting translatable data
* Fixes #12019
damianlegawiec added a commit that referenced this issue May 16, 2024
…in original columns (#12040)

* Use column_fallback plugin from mobility:
* Use original column for the translatable fields in the default locale
* Remove migrations for transferring and deleting translatable data
* Fixes #12019

* fixed `Taxonomy#set_root_taxon_name`

* Fix translations for properties: remove name from being translated

* Update has_webhooks_spec.rb

* Fixed `Taxon#sync_taxonomy_name`

* Adjust what's being translated + correct product scopes

* added `Spree.use_translations?` and `Spree::Core::RuntimeConfig`

* Updae mailer specs

* * Fix `Spree::Products::Sort` to select translatable fields only when using translations
* Update API V2 Storefront Products specs

* Fix  and refactor collection sorters

* Update `Spree::Api::V2::ResourceController` specs

* Use directly the `Spree.use_translations?` in finders and sorters

---------

Co-authored-by: Damian Legawiec <damian@getvendo.com>
@chuckyuee
Copy link
Author

It's awesome! Has been successfully updated to the latest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants