Summary | Attach checklist to tickets |
Queue | Whups |
Type | Enhancement |
State | Rejected |
Priority | 1. Low |
Owners | |
Requester | ben (at) |
Created | 09/08/2006 (6956 days ago) |
Due | |
Updated | 01/15/2007 (6827 days ago) |
Assigned | |
Resolved | 09/08/2006 (6956 days ago) |
Milestone | |
Patch | No |
future. If I don't get him wrong, he wants different sets of
checkboxes for different tickets. But this is really a task with
subtasks then, that should be covered by Nag not Whups.
to store the checklist and the state of each item on the list as
separate values.
list is really just a Horde_Form, then this should be easy to drop in
with the general solution you're describing Chuck.
future. If I don't get him wrong, he wants different sets of
checkboxes for different tickets. But this is really a task with
subtasks then, that should be covered by Nag not Whups.
store the checklist and the state of each item on the list as separate
values.
future. If I don't get him wrong, he wants different sets of
checkboxes for different tickets. But this is really a task with
subtasks then, that should be covered by Nag not Whups.
attributes to be any Horde_Form type eventually, and that means you
could write a plugin for these to handle anything - you could even map
them to nag tasks.
1. Granular tickets. Our enhancement-type tickets are granular enough
to speak about in conceptual terms, but when we turn these tickets
over to junior developers to implement, we find they miss certain
details that our architecture/senior developers would know to do.
Having a checklist would allow them to check off those parts of the
ticket they've accomplished and see their progress at a glance. A
workaround is to put one task in one comment, then have the developer
reply to each comment when complete. This works, but isn't ideal.
2. Task tickets. We use whups as a client portal as well as for bug
tracking, so we have a "task" type ticket, which refers to an (often
billable) action such as making a production system upgrade. The
client often inputs these tasks, so a checklist helps the client see
-- at a glance -- that each sub-task has been handled.
Attributes do not seem amenable to these use cases:
State ⇒ Rejected
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Attach checklist to tickets
Queue ⇒ Whups
State ⇒ New
of machines. It would be helpful to be able to have a checklist
attached to a ticket so I could check off the machines that have been
completed.