Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0054673 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
defect | [POS2] Core | minor | always | 2024-02-14 14:09 | 2024-05-13 10:42 | |||||||
Reporter | NaroaIriarte | View Status | public | |||||||||
Assigned To | Triage Platform Base | |||||||||||
Priority | normal | Resolution | open | Fixed in Version | ||||||||
Status | new | Fix in branch | Fixed in SCM revision | |||||||||
Projection | none | ETA | none | Target Version | ||||||||
OS | Any | Database | Any | Java version | ||||||||
OS Version | Database version | Ant version | ||||||||||
Product Version | SCM revision | |||||||||||
Review Assigned To | ||||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0054673: The exceptions handled in the backoffice should be managed per each developer and not in a general way | |||||||||||
Description | Currently, the exceptions generated in the backoffice are handled and this leads to some issues when the developers need to handle themselves in other code parts. This exception handling mechanism should be controlled or erased and let the developers that implement new code handle their exceptions. Here is an example of the issue: We are trying to show an error on a dialog but we always get the general popup error too. (image attached) | |||||||||||
Steps To Reproduce | - | |||||||||||
Proposed Solution | Erase the code that shows the popup error and let the developers handle their errors or add a parameter that can be set to true if error handling is needed, for example. | |||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | doubleError.png [^] (64,698 bytes) 2024-02-14 14:09
| |||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||||||||||||||||
|
Notes | |
(0164120) caristu (manager) 2024-05-06 17:47 |
The logic that handles the display of those messages is centralized here[1]. If it is finally decided to show no message at all in an automatic way, the fix is just a matter of removing the "handleErrorInSuccessfulResponse" function and its usage. Note that this can cause potential regressions on the code that is currently delegating to this function the display of the error messages. In such cases, the user would stop seeing the errors. [1] https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/blob/master/web-jspack/org.openbravo.core2/src/core/network/RequestListener.js#L41 [^] |
(0164479) ucarrion (developer) 2024-05-13 10:42 |
Putting this issue as 'Gold' because is blocking a fix for ToysRUs. See the related Mantis https://issues.openbravo.com/view.php?id=55361 [^] |
Issue History | |||
Date Modified | Username | Field | Change |
2024-02-14 14:09 | NaroaIriarte | New Issue | |
2024-02-14 14:09 | NaroaIriarte | Assigned To | => Triage Platform Base |
2024-02-14 14:09 | NaroaIriarte | File Added: doubleError.png | |
2024-02-14 14:09 | NaroaIriarte | Triggers an Emergency Pack | => No |
2024-02-14 16:46 | NaroaIriarte | Relationship added | related to 0054436 |
2024-05-06 17:47 | caristu | Note Added: 0164120 | |
2024-05-06 17:49 | caristu | Relationship added | related to 0052342 |
2024-05-08 17:29 | guilleaer | Relationship added | blocks 0055361 |
2024-05-08 17:34 | guilleaer | Relationship added | blocks 0055330 |
2024-05-08 17:39 | guilleaer | Relationship deleted | blocks 0055330 |
2024-05-08 17:39 | guilleaer | Relationship deleted | blocks 0055361 |
2024-05-09 12:43 | guilleaer | Relationship added | blocks 0055361 |
2024-05-13 10:42 | ucarrion | Note Added: 0164479 |
Copyright © 2000 - 2009 MantisBT Group |