6.0.0-beta1
9/24/25

[#4400] Attach checklist to tickets
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

History
01/15/2007 12:34:19 AM php (at) ideacode (dot) com Comment #7 Reply to this comment
I don't think what he wants can be implemented with attributes in the
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.
If it was really a custom attribute, it could do whatever it needed
to store the checklist and the state of each item on the list as
separate values.
Ideally, we'd not want to re-invent the wheel, so assuming a nag-type 
list is really just a Horde_Form, then this should be easy to drop in 
with the general solution you're describing Chuck.
01/08/2007 06:10:26 PM Chuck Hagenbuch Comment #6 Reply to this comment
I don't think what he wants can be implemented with attributes in the
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.
If it was really a custom attribute, it could do whatever it needed to 
store the checklist and the state of each item on the list as separate 
values.
01/08/2007 11:31:47 AM Jan Schneider Comment #5 Reply to this comment
I don't think what he wants can be implemented with attributes in the 
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.
01/08/2007 04:31:44 AM Chuck Hagenbuch Comment #4 Reply to this comment
Attributes do not seem amenable to these use cases:
As they're currently implemented, no. But the plan is to allow 
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.
01/08/2007 04:00:54 AM bishop (at) ideacode (dot) com Comment #3 Reply to this comment
This kind of thing should _definitely_ be a custom attribute. :)
Our use of Whups would benefit from checklists in two ways:



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:
09/08/2006 11:35:48 PM Chuck Hagenbuch Comment #2
State ⇒ Rejected
Reply to this comment
This kind of thing should _definitely_ be a custom attribute. :)
09/08/2006 11:22:28 PM ben Comment #1
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Attach checklist to tickets
Queue ⇒ Whups
State ⇒ New
Reply to this comment
Often times I get a ticket that requires the same action on a number 
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.

Saved Queries