Tickets :: [#7586] Get rid of the "assigned" state_category, clean up other state categories

6.0.0-alpha10

5/14/25

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	10/28/2008 (6042 days ago)
Due
Updated	10/29/2008 (6041 days ago)
Assigned
Resolved
Milestone
Patch	No

10/29/2008 03:39:56 AM	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.

10/28/2008 06:01:34 PM	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.

10/28/2008 05:36:48 PM	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".

10/28/2008 02:47:02 PM	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.

10/28/2008 01:49:39 PM	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.

10/28/2008 11:10:19 AM	Jan Schneider	Comment #4	Reply to this comment
'new' doesn't afaics.

10/28/2008 11:08:24 AM	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.

10/28/2008 06:56:48 AM	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.

10/28/2008 06:54:44 AM	Chuck Hagenbuch	Comment #1 Priority ⇒ 1. Low Type ⇒ Enhancement Summary ⇒ Get rid of the "assigned" state_category, clean up other state categories Queue ⇒ Whups Assigned to Chuck Hagenbuch Milestone ⇒ Patch ⇒ No State ⇒ Assigned	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