View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002237 | OXID eShop (all versions) | 1.01. Products (product, categories, manufacturer, promotions etc.) | public | 2010-12-06 13:09 | 2012-12-07 14:13 |
| Reporter | thorsten_albrecht | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.4.4 revision 30554 | ||||
| Fixed in Version | 4.5.2 revision 38481 | ||||
| Summary | 0002237: Recognizing assigned main category of a product with oxtime=0 in oxobject2category | ||||
| Description | The problem concerns the column oxtime in table oxobject2category which is used to recognize the assigned main category of a product. If one assigns more than one category to a product and the button "set as main category" is pressed, oxtime will be set to 0, and the other categories will be numbered by 10,20, etc. This is a good method because one can easily recognize the main category in the database. The problem arises when the button is _not_ pressed. In this case oxtime holds only timestamp values when one or more categories are assigned to a product. But nevertheless also in this case the main category is (implicitely) defined in the shop: 1. If one assigns only one category this category is the main category. 2. If one assigns more than one category to a product none of these other categories are defined as a main category. Only the first assigned category is defined as main category. In both cases (1.,2.) oxtime of the main category is not set to 0. Only a timestamp is used. For the other categories oxtime holds also timestamps. This is an inconsistent use of the column oxtime in oxobject2category: Sometimes timestamps are used, sometimes values like 0,10,20,etc. are used. I suggest that only one method will be used. In my opinion values like 0,10,20,etc. is an easy and understandable method. BTW Why do I need this? I need to identify the main category for export routines and I would prefer an easy method to identify the main category of a product. Thorsten | ||||
| Tags | Category | ||||
| Theme | |||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
Reminder sent to: thorsten_albrecht Hi, It works like that: when few categories are assigned to the product (without setting the Main Category) - all entries have the same oxtime value in oxobject2category. In this case (as Main category is not selected), it is interpreted, that Main category is the First one, which is returned after request from DB. Later, if any of these categories is set as Main - the oxtime for this category is set to 0 (all other oxtime values remains the same). From now - this category is returned first (as oxtime=0) and threated as Main. Later - if any other category will be marked as Main, then previous category getc increased oxtime (i.e. 10), and oxtime=0 goes to newly marked Category. So now oxtime=0 is returned first (as Main Category), then oxtime=10, then others... In eShop it works quite well with such simple logic. So from our side - it's not a bug and we're not sure if we need an improvement here. The case here is closed. If you still have some arguments to implement improvement in future versions - please write feature request to http://oxid.uservoice.com/forums/31940-feature-requests with details. Thank you. |
|
|
Hi Dainius, >"Main category is the First one, which is returned after request from DB." This is not a very good method. It's inconsistant to the '0' method which you use in later stages and it is not exact. Why don't you assign a 0 to the main category immediately, and everything works fine? This would be a very clean method. Thorsten |
|
|
Reminder sent to: thorsten_albrecht That would be one more additional not really necessary action. I mean - you can know anyway, that first of returned categories is the Main. So setting 0 to it additionally - looks like redundant action. Or do you have some cases, when this would really help? Please tell us. |
|
|
Hi, my real world problem is: I am traversing the whole category tree and I am exporting the articles which are assigned to each category. But: I would like to export only those articles which are assigned to a main category. So a statement like this would work: SELECT * FROM oxobject2category as art2cat WHERE art2cat.OXCATNID = '$category_oxid' AND art2cat.OXTIME = '0' But as you mentioned: Before pressing the button, there is no oxtime=0, so this won't work. Your method to take only the first record works only if I know the article oxid before. But in my case I do not know it because I am currently retrieving it from oxobject2category. I would have to skip articles when fetching the records. I hope you understand my problem and I am not missing anything. BTW To have access on every article data I extended the call above to: SELECT * FROM oxobject2category as art2cat LEFT JOIN oxarticles as art ON art2cat.OXOBJECTID = art.OXID WHERE art2cat.OXCATNID = '$category_oxid' AND art2cat.OXTIME = '0' AND art.OXACTIVE = '1' ORDER by art.OXTITLE ...which would work perfectly if I could assure that all maincategories of an article are correctly shown with oxtime=0. But this is not the case at the moment. I do not think that it would be too much programming effort to store oxtime=0 when assigning the first categories. If one presses the button, you have to assign it anyway. Because of this the right code exists in the system. My proposal: Just delete the code which is responsible for the timestamps and use immediately the code for the button. BTW The column name "oxtime" is IMO completely meaningless because the timestamps which are assigned first are overridden later on. Why don't you introdruce a real meaningful column like 'oxmaincategory'? (oxmaincategory=1: this is the main category, default=0). Thorsten |
|
|
Reminder sent to: thorsten_albrecht Hi, Having these cases looks like these improvements would be really useful. So we will consider how to solve this in best case and improve this place in future releases. But for sure this issue is not a High priority, so it will take some time until will be implemented. Thank you for your feedback. Best regards, |
|
|
Is there any chance of solving this issue now (6 months later)? Thorsten |
