View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006500 | OXID eShop (all versions) | 2.4. Administer products | public | 2016-09-07 12:10 | 2016-09-19 12:25 |
| Reporter | Paulius.Kupetis | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.9.5 / 5.2.5 | ||||
| Summary | 0006500: Wrong category parent is shown on cateogry list | ||||
| Description | In category list wrong category was selected. Why this happens in example: This was because parent category ID was '003' and other category ID was '03'. And then '==' comparison tries to compare these strings, it interprets them like a numbers. | ||||
| Tags | No tags attached. | ||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | 5.6 | ||||
| Database Version | Not defined | ||||
|
|
Thank you for submitting this entry! Unfortunately I can't reproduce this issue. Please provide a more detailed list of steps how to reproduce it. |
|
|
This fault was on shop backend: "Administer products"->"Categories"->"Main" And "Subcategory of" was selected wrong. This was an issue because category parent ID was '003' and other random category ID in list was '03' and then searching for parent, other category (not true parent of category) with ID '03' was selected. You can try to reproduce this by creating categories with ID '03', name 'good Parent' and '003' wtih name 'bad category parent' Select any category and assign parent category with ID '03', then try to look for error. If it still don't show up this may be because category with ID '03' is in front of list, before category with ID '003' and check passes. Fault is in \oxAdminDetails::_getCategoryTree line : "if ($oCategory->getId() == $sSelectedCatId) {" This line interprets '003' and '03' as same, and check passes although it should not. |
|
|
The shop works with strings as unique IDs. This can be seen in the method \oxUtilsObject::generateUId where the "oxids" are generated. You will get anytime a hash of 32 chars. Using integers as oxids is not supported inherently. So if its the requirement in the project to use integers as value for the column oxid, the shop framework needs to be adapted project specifically. |
|
|
IMHO this is a bug, as the two OXIDs in the example are definitely strings and unique IDs. In the comparison in the code the two strings are treated as integers and thus they are considered as equal, when they are actually not equal. This code is fixed in pull request https://github.com/OXID-eSales/oxideshop_ce/pull/482 |
