Details
-
Bug
-
Resolution: Fixed
-
Critical
-
4.6.6
-
v5 LTS - Sprint 12
-
Ibexa Experience
Description
It is possible by completely legal content & data manipulation via admin UI to take the product categories to a unique constraint violation leading to some crashes and inconsistent DB state.
How to replicate:
[1] Create new category "Y" in eng-GB: name="Y EN", identifier="y_en".
The Y's identifier in ibexa_taxonomy_entries (in DB) is now "y_en".
[2] Create new category Y's translation in pol-PL: name="Y PL", identifier="y_pl".
The Y's identifier in ibexa_taxonomy_entries is still "y_en".
[3] Create new category "X" in pol-PL: name="Y PL", identifier="y_pl".
The X's identifier in ibexa_taxonomy_entries in DB is now "y_pl".
The taxonomy table looks now something like:
identifier | name | names y_en | Y EN | a:2:{s:6:"eng-GB";s:4:"Y EN";s:6:"pol-PL";s:4:"Y PL";} y_pl | Y PL | a:1:{s:6:"pol-PL";s:4:"Y PL";}
[4] Update Y's main language from eng-GB to pol-PL. There's no change to both ibexa_taxonomy_entries identifiers, all seems OK.
[5] Now remove Y's eng-GB translation (only the secondary translation, not entire category!).
[6] At this point, there will be a red notice about constraint violation. Working on those categories now will lead to system crash because DB taxonomy entries were left in an inconsistent state.
Additional info:
It may be easier to encounter this problem because of the issue IBX-8577.
However, it doesn't seem to be the core issue here. It seems that in case of tags, the taxonomies engine is capable of holding to a once-selected unique identifier even when it's translations get removed. I wasn't able to replicate the same problem for tags. In case of product categories, the logic of calculating/retaining the unique identifier seems a bit different to the one in the tags.