Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
| ID | ||||||||||||
| 0038397 | ||||||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
| feature request | [Modules] Advanced Warehouse Operations | major | always | 2018-04-17 18:25 | 2024-02-14 17:51 | |||||||
| Reporter | dmiguelez | View Status | public | |||||||||
| Assigned To | dmiguelez | |||||||||||
| Priority | high | 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 | |||||||||||
| Regression date | ||||||||||||
| Regression introduced by commit | ||||||||||||
| Regression level | ||||||||||||
| Review Assigned To | ||||||||||||
| Regression introduced in release | ||||||||||||
| Summary | 0038397: Improve management of Task with errors while confirming | |||||||||||
| Description | Actually, all the Tasks that have errors while confirming are stored into the "Errors while confirming Task" Table However, this is a problem in some scenarios. Example. There is a Task, and the user confirms the Task with 0 quantity and selects the option to do a Delta Different. If there is no Stock in the system, the Delta Task raises an exception and the original Task remains not confirmed. But, since it is included in the "Errors while confirming" Table, it is not shown to the user again, so the user can not perform further actions against this Task. To solve this problem, there should be a differentiation between errors that happens due to a software bug or an unexpected error and the controlled exceptions, like the inability to generate a Delta Task due to the lack of Stock If the error is raised due to a software bug or an unexpected situation, it should be managed as it is done now. A new entry in the "Errors while confirming Task" Table is created and the Task is no longer visible for the user. The manager should manage this situation afterwards. If the error is raised due to a controlled situation, what should happen is: - The error is not stored into the "Errors while confirming Task" Table - The error is stored in a new Tab under the Task Window that could be named "Warnings while processing" - This Tab will work as a log of all the errors that had happened while confirming, so information about user and time is a must - The Task should be shown to the user - It should be presented in a different color or with some icon for the user to understand that the Task have had errors while confirming - A message should be shown with the last error that has happened | |||||||||||
| Steps To Reproduce | Actually, all the Tasks that have errors while confirming are stored into the "Errors while confirming Task" Table However, this is a problem in some scenarios. Example. There is a Task, and the user confirms the Task with 0 quantity and selects the option to do a Delta Different. If there is no Stock in the system, the Delta Task raises an exception and the original Task remains not confirmed. But, since it is included in the "Errors while confirming" Table, it is not shown to the user again, so the user can not perform further actions against this Task. To solve this problem, there should be a differentiation between errors that happens due to a software bug or an unexpected error and the controlled exceptions, like the inability to generate a Delta Task due to the lack of Stock If the error is raised due to a software bug or an unexpected situation, it should be managed as it is done now. A new entry in the "Errors while confirming Task" Table is created and the Task is no longer visible for the user. The manager should manage this situation afterwards. If the error is raised due to a controlled situation, what should happen is: - The error is not stored into the "Errors while confirming Task" Table - The error is stored in a new Tab under the Task Window that could be named "Warnings while processing" - This Tab will work as a log of all the errors that had happened while confirming, so information about user and time is a must - The Task should be shown to the user - It should be presented in a different color or with some icon for the user to understand that the Task have had errors while confirming - A message should be shown with the last error that has happened | |||||||||||
| Tags | No tags attached. | |||||||||||
| Attached Files |  Icon suggestions to show on Task.png [^] (101,497 bytes) 2018-04-18 10:54
| |||||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0103964) maarten1962 (reporter) 2018-04-18 10:54 |
Hi David, a few amendments: 1. You write: "If the error is raised due to a software bug or an unexpected situation, it should be managed as it is done now. A new entry in the "Errors while confirming Task" Table is created and the Task is no longer visible for the user. The manager should manage this situation afterwards." -> I propose to SHOW the task, with a 'blocked' aspect, and inhabilitated. 2. You write: "The error is stored in a new Tab under the Task Window that could be named "Warnings while processing" -> I propose to name the subtab "Incidents", to leave 'space' for warnings, errors, notifications, ... 3. See attached suggestions for icon on the task, to indicate a STOP or a WARNING |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2018-04-17 18:25 | dmiguelez | New Issue | |
| 2018-04-17 18:25 | dmiguelez | Assigned To | => dmiguelez |
| 2018-04-18 10:54 | maarten1962 | Note Added: 0103964 | |
| 2018-04-18 10:54 | maarten1962 | File Added: Icon suggestions to show on Task.png | |
| 2022-09-06 17:18 | caristu | Category | Advance Warehouse Operations => Advanced Warehouse Operations |
| 2024-02-14 17:51 | eugeni | Issue Monitored: eugeni | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |