6.0.0-git
2019-01-23

[#7586] Get rid of the "assigned" state_category, clean up other state categories
Summary Get rid of the "assigned" state_category, clean up other state categories
Queue Whups
Queue Version HEAD
Type Enhancement
State Assigned
Priority 1. Low
Owners chuck (at) horde (dot) org
Requester chuck (at) horde (dot) org
Created 2008-10-28 (3739 days ago)
Due
Updated 2008-10-29 (3738 days ago)
Assigned
Resolved
Milestone
Patch No

History
2008-10-29 03:39:56 Chuck Hagenbuch Comment #9 Reply to this comment
I still think it is useful to differentiate between open (there might
be a bug) and assigned (someone's actually working on it). And I'm
talking about visual difference here, since you mentioned that
earlier as valid use for state categories.
In any case we should ask the users before creating any facts.
Visual difference, sure. I don't see a need for this at a data level 
though, still. We have the assignment data separately, and we should 
consult it there, where it's accurate.
2008-10-28 18:01:34 Jan Schneider Comment #8 Reply to this comment
I still think it is useful to differentiate between open (there might 
be a bug) and assigned (someone's actually working on it). And I'm 
talking about visual difference here, since you mentioned that earlier 
as valid use for state categories.

In any case we should ask the users before creating any facts.
2008-10-28 17:36:48 Chuck Hagenbuch Comment #7 Reply to this comment
The 'assigned' category has a special meaning though, e.g. to
determine whether to send out reminders
That should be determined based on whether there are actually ticket
owners though, right?
But that would require another table lookup.
Why? Just because the category matches doesn't mean there's actually 
someone assigned, so we'd need another lookup anyways to do reasonable 
actions.
I can rather see the "new" category go away, since it doesn't serve 
any special purpose.
Convinced on that one now. So I'm still thinking just "open" and "closed".
2008-10-28 14:47:02 Jan Schneider Comment #6 Reply to this comment
The 'assigned' category has a special meaning though, e.g. to
determine whether to send out reminders
That should be determined based on whether there are actually ticket
owners though, right?
But that would require another table lookup. I can rather see the 
"new" category go away, since it doesn't serve any special purpose.
2008-10-28 13:49:39 Chuck Hagenbuch Comment #5 Reply to this comment
The 'assigned' category has a special meaning though, e.g. to
determine whether to send out reminders
That should be determined based on whether there are actually ticket 
owners though, right?
or whether to show another step when creating a new ticket.
That could be fixed by improving the ticket creation form.
2008-10-28 11:10:19 Jan Schneider Comment #4 Reply to this comment
'new' doesn't afaics.
2008-10-28 11:08:24 Jan Schneider Comment #3 Reply to this comment
The 'assigned' category has a special meaning though, e.g. to 
determine whether to send out reminders, or whether to show another 
step when creating a new ticket.
2008-10-28 06:56:48 Chuck Hagenbuch Comment #2 Reply to this comment
Do we even need "new"? I guess it might allow some automatic 
processing, but since we still want to let users define the actual 
states, these should be kept very basic.
2008-10-28 06:54:44 Chuck Hagenbuch Comment #1
Type ⇒ Enhancement
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ Get rid of the "assigned" state_category, clean up other state categories
Queue ⇒ Whups
Assigned to Chuck Hagenbuch
Milestone ⇒
Patch ⇒ No
Reply to this comment
Since this isn't associate with whether or not a ticket is actually 
assigned, it's pretty useless. Get rid of it. Just make sure removing 
it doesn't break existing data.



Looking at this more closely, right now we have:



unconfirmed

new

assigned

resolved



I'm going to simplify that to:

new

open

closed

Saved Queries