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.
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.
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.
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.
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:
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.
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.