Create a Response Status field separate from Incident Types #205
Comments
|
Programmer-speak overview here: There are various pages where, if you close an incident as "No response needed" or "Invalid", the incident type gets displayed as that from then on -- instead of as, you know, an actual incident type, like "Fire" or "Flood" or whatever. That's a bizarre category mixing. We don't know how deep this problem goes. Heck, I don't even quite understand how it's possible to get those inappropriate values into those fields. I mean, aren't these essentially enum types under the hood somewhere? Please? Anyway, we'll figure it out. This note is just to confirm to whoever looks at this next that, yes, the problem really is as weird as it sounds. Ask @OhMcGoo to demonstrate it. |
|
The way the code works in general is that the status should be either Open, Closed, or Invalid. In the case of the latter, I'll add a new DB column "reason_marked_invalid" and then when displaying the status on the incident page, it will say something like "Invalid - Duplicate" or "Invalid - No response needed" |
|
One last question is where to put this information? |
|
@frankduncan: So, let me simply confirm . . . We now have five possible statuses:
|
|
There's also "Invalid - " which displays as "Invalid" and "Invalid - Invalid" which displays as "Invalid" |
|
@frankduncan: OK, let me give this some thought. I want to finish reviewing the staging site and then I'll return my attention to this issue. |
Before, the reason an incident was marked invalid was stored in the incident_type field, which resulted in losing the original incident type (fire, or vacate, or whatever). This caused issues when the incident was reopened, or for reporting. Instead, we want to have a separate field for the invalid reason that we display and search on when the incident status is 'invalid' Issue #205: Create a Response Status field separate from Incident Types
|
@frankduncan: How about something like this where "Response" is also added as a Status qualifier:
|
|
Response is not a currently tracked status, so when does it get that status? And that might be a bigger change than what we've been talking about because it gets into the workflow. But as for putting the status under the Response table, that's easy enough. |
|
@frankduncan: Any incident that's NOT Invalid counts as a Response. |
|
@OhMcGoo So we want "Response - Open" and "Response - Closed" vs "Invalid - Duplicate"? |
Before, the reason an incident was marked invalid was stored in the incident_type field, which resulted in losing the original incident type (fire, or vacate, or whatever). This caused issues when the incident was reopened, or for reporting. Instead, we want to have a separate field for the invalid reason that we display and search on when the incident status is 'invalid' Issue #205: Create a Response Status field separate from Incident Types
Before, the reason an incident was marked invalid was stored in the incident_type field, which resulted in losing the original incident type (fire, or vacate, or whatever). This caused issues when the incident was reopened, or for reporting. Instead, we want to have a separate field for the invalid reason that we display and search on when the incident status is 'invalid' Issue #205: Create a Response Status field separate from Incident Types
Fix #205: Add reason_marked_invalid to incident
Incident Types:
Response Status:
The text was updated successfully, but these errors were encountered: