View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006853 | OXID ERP Interface | OXID ERP Interface - sub | public | 2018-07-09 11:28 | 2024-05-22 18:09 |
| Reporter | QA | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | 3.1.0 | ||||
| Summary | 0006853: OXERPSetArticleCategory and OXERPObject2Category overwrites OXTIME with value 0 | ||||
| Description | Normally the OXID ERP Interface only sets values for database table attributes, that are explicitly present in the request. All other values from an existing record won't be touched. Though the OXERPSetArticleCategory request inserts a timestamp for OXTIME while executing the request the first time, but overwrites the OXTIME attribute with 0, if the same request is sent again. If blDeleteOld parameter is set to true, the record will be deleted and reinserted. Because it is an insert, OXTIME will be set with a new timestamp. In short: insert -> OXTIME = timestamp update -> OXTIME = 0 The problem: If the request will be done two or more times, OXTIME is set to 0, which automatically defines this category a main category of the article. Unfortunately this leads to more than one main category, which isn't supposed to happen. edit: The OXERPObject2Category function, which also could be used to assign categories to articles, shows the same behavior. If request with same assignment is sent two or more times, OXTIME is set to 0. Parameter blDeleteOld isn't present there. Only way to avoid multi main categories is to manually set the OXTIME value > 0 for non-main categories. Luckily this is possible with OXERPObject2Category. [sp] | ||||
| Steps To Reproduce | 1) Configurate a OXERPSetArticleCategory request with blDeleteOld parameter set to false. 2) Send the request at least two times and check the database after and in between. | ||||
| Additional Information | In my opinion, there are two ways to more or less solve this issue: 1) Change the manner of this request to match the normal OXID ERP Interface behavior. Then it won't come to an issue. 2) Explicitly document this special behavior, including detailed information about the blDeleteOld parameter and how - and even more important - why to use it. edit: Since OXERPObject2Category shows the same behavior, solution 2 doesn't sound as effective as before. The behavior doesn't seem to be reasonable at all. | ||||
| Tags | Article, Category, ERP | ||||
