Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0054673 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
feature request | [POS2] Core | minor | always | 2024-02-14 14:09 | 2024-07-30 13:27 | |||||||
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: Errors in successful responses generate a notification even if the code that issued the request handles the error. | |||||||||||
Description | When a successful response contains an error message, the error is handled on a function listener here [1] and a notification is displayed on the lower part of the screen (see attached image). Sometimes the code that issued the request is the one that is going to address the error (see same attached image), so the notification displayed by the RequestListener would not be needed, as it is redundant. [1] https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/blob/master/web-jspack/org.openbravo.core2/src/core/network/RequestListener.js#L42 [^] | |||||||||||
Steps To Reproduce | In org.openbravo.pos2/src/org/openbravo/pos2/process/StoreStock.java add throw exception --- a/src/org/openbravo/pos2/process/StoreStock.java +++ b/src/org/openbravo/pos2/process/StoreStock.java @@ -22,6 +22,7 @@ import javax.inject.Inject; import org.apache.commons.lang.StringUtils; import org.codehaus.jettison.json.JSONException; import org.codehaus.jettison.json.JSONObject; +import org.openbravo.base.exception.OBException; import org.openbravo.client.kernel.ComponentProvider.Qualifier; import org.openbravo.dal.core.OBContext; import org.openbravo.erpCommon.utility.OBMessageUtils; @@ -62,6 +63,9 @@ public class StoreStock extends ProcessHQLQuery { @Override protected Map<String, Object> getParameterValues(JSONObject jsonsent) throws JSONException { + if (1 == 1) { + throw new OBException("My managed error"); + } try { OBContext.setAdminMode(true); final Map<String, Object> parameters = new HashMap<>(); In /home/openbravo/workspaces/pos2/openbravo/modules/org.openbravo.pos2/web-jspack/org.openbravo.pos2/src/components/ProductButton/StoreStockPopup/StoreStockDataSource.js add a console log to simulate that I want to manage my exception --- a/web-jspack/org.openbravo.pos2/src/components/ProductButton/StoreStockPopup/StoreStockDataSource.js +++ b/web-jspack/org.openbravo.pos2/src/components/ProductButton/StoreStockPopup/StoreStockDataSource.js @@ -29,6 +29,8 @@ export default class StoreStockDataSource extends RemoteDataSource { productId }); + console.error('My Own error'); + Login into POS Add a product to the order -> Avalanche transceiver click on the line recently added -> It executes to call to check stock 1. Error with my exception is shown as an error 2. my log is shown in the console Platform should allow developers to manage exceptions without showing errors | |||||||||||
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 [^] |
(0166927) AugustoMauch (administrator) 2024-07-12 09:32 |
Hello Naroa, We need steps to reproduce, please. |
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 | |
2024-07-12 09:32 | AugustoMauch | Note Added: 0166927 | |
2024-07-12 09:32 | AugustoMauch | Assigned To | Triage Platform Base => NaroaIriarte |
2024-07-12 09:32 | AugustoMauch | Status | new => feedback |
2024-07-12 13:47 | guilleaer | Steps to Reproduce Updated | View Revisions |
2024-07-12 14:02 | AugustoMauch | Summary | The exceptions handled in the backoffice should be managed per each developer and not in a general way => Errors in successful responses generate a notification even if the code that issued the request handles the error. |
2024-07-12 14:02 | AugustoMauch | Description Updated | View Revisions |
2024-07-15 09:24 | guillermogil | Assigned To | NaroaIriarte => guillermogil |
2024-07-15 09:25 | guillermogil | Assigned To | guillermogil => Triage Platform Base |
2024-07-15 09:25 | guillermogil | Status | feedback => new |
2024-07-30 13:27 | AugustoMauch | Type | defect => feature request |
Copyright © 2000 - 2009 MantisBT Group |