| View Issue Details [ Jump to Notes ] [ Wiki ] | | [ Issue History ] [ Print ] |
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0003794 | mantisbt | custom fields | public | 2004-04-29 17:51 | 2004-07-30 17:39 |
|
| Reporter | dfaught | |
| Assigned To | | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | acknowledged | Resolution | open | |
| Platform | | OS | | OS Version | |
| Product Version | 0.18.2 | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0003794: Fields can quietly take on unintended values after enumerations are modified |
| Description | 1) File a bug and set an enumeration type like Category or a custom enumeration field.
2) Remove that enumeration value under "Manage" as an admin. Now an invalid Category will display as blank when viewing the bug, but a custom field value will still show the old value.
3) Update the bug record, changing some other unrelated field.
The field that was modified by the admin now takes on the value of the first enumeration value available. The user is given no cues that the data in these fields that they might not have intended to change has been corrupted.
This problem could lead to subtle unintended changes to the bug database that are hard to trace. |
| Tags | No tags attached. |
|
| Attached Files | |
|
Relationships 
Relationships 