When I am updating ‘Select One’ or ‘Select Multiple’ custom
fields on the bulk update form, if I leave a particular
custome field set at ‘(no value)’ any current selections
for each ticket are deleted.
Is this the desired/expected behavior?
Does there need to be another value that is “Don’t update” ?
-Todd
When I am updating ‘Select One’ or ‘Select Multiple’ custom
fields on the bulk update form, if I leave a particular
custome field set at ‘(no value)’ any current selections
for each ticket are deleted.
There’s an open ticket about it.
Is this the desired/expected behavior?
No.
Does there need to be another value that is “Don’t update” ?
Yeah. We traditionally use just a “-” in the field for that.
For multi-select we could be much fancier and offer add/remove/
don’t change options for each value. Would you like a patch for
that? I’m using 3.2 so that is what the patch would be against.
I’m guessing that 3.3 is quite a bit different.
-ToddOn Tue, Oct 12, 2004 at 12:47:27PM -0400, Jesse Vincent wrote:
On Tue, Oct 12, 2004 at 11:31:09AM -0400, Todd Chapman wrote:
When I am updating ‘Select One’ or ‘Select Multiple’ custom
fields on the bulk update form, if I leave a particular
custome field set at ‘(no value)’ any current selections
for each ticket are deleted.There’s an open ticket about it.
Is this the desired/expected behavior?
No.
Does there need to be another value that is “Don’t update” ?
Yeah. We traditionally use just a “-” in the field for that.
-Todd
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives–
For multi-select we could be much fancier and offer add/remove/
don’t change options for each value. Would you like a patch for
that? I’m using 3.2 so that is what the patch would be against.
I’m guessing that 3.3 is quite a bit different.
Indeed. A patch would be delightful.
A patch has been submitted if anyone is intestested in trying
it out.
http://rt3.fsck.com/Ticket/Display.html?id=6195
-ToddOn Tue, Oct 12, 2004 at 02:56:50PM -0400, Jesse Vincent wrote:
On Tue, Oct 12, 2004 at 02:10:00PM -0400, Todd Chapman wrote:
For multi-select we could be much fancier and offer add/remove/
don’t change options for each value. Would you like a patch for
that? I’m using 3.2 so that is what the patch would be against.
I’m guessing that 3.3 is quite a bit different.Indeed. A patch would be delightful.
A patch has been submitted if anyone is intestested in trying
it out.
Thanks!
What I’d love to see is something that uses the standard RT widgets.
I’m a bit worried that one select with both add and delete values will
end up being too confusing.
-j
I’m not sure what you mean. For MultiSelect CFs the radio
buttons seem very appropriate and work out nicely. It
doesn’t seem confusing to me. 
Anything simpler would
be less flexible. Is there a more appropriate widget that
I am not seeing?
-ToddOn Thu, Oct 14, 2004 at 04:00:06PM -0400, Jesse Vincent wrote:
On Thu, Oct 14, 2004 at 03:17:53PM -0400, Todd Chapman wrote:
A patch has been submitted if anyone is intestested in trying
it out.
Thanks!What I’d love to see is something that uses the standard RT widgets.
I’m a bit worried that one select with both add and delete values will
end up being too confusing.-j
http://rt3.fsck.com/Ticket/Display.html?id=6195
-Todd
On Tue, Oct 12, 2004 at 02:56:50PM -0400, Jesse Vincent wrote:
On Tue, Oct 12, 2004 at 02:10:00PM -0400, Todd Chapman wrote:
For multi-select we could be much fancier and offer add/remove/
don’t change options for each value. Would you like a patch for
that? I’m using 3.2 so that is what the patch would be against.
I’m guessing that 3.3 is quite a bit different.Indeed. A patch would be delightful.
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives–
I’m not sure what you mean. For MultiSelect CFs the radio
buttons seem very appropriate and work out nicely.
Sorry, I misread the patch. New concern: how radio buttons will render
with a 50 entry custom field.
It will render a lot faster than updating a large number
of tickets individually. Are you concerned about the
table based layout? It could probably be changed easily.
-ToddOn Thu, Oct 14, 2004 at 04:35:18PM -0400, Jesse Vincent wrote:
On Thu, Oct 14, 2004 at 03:42:47PM -0400, Todd Chapman wrote:
I’m not sure what you mean. For MultiSelect CFs the radio
buttons seem very appropriate and work out nicely.Sorry, I misread the patch. New concern: how radio buttons will render
with a 50 entry custom field.It doesn’t seem confusing to me.
be less flexible. Is there a more appropriate widget that
I am not seeing?-Todd
I’m actually concerned about how big the page would be with 50 or even
500 custom field values. Why not use SELECT MULTIPLE boxes like we do
throughout the rest of the UI?On Thu, Oct 14, 2004 at 04:20:27PM -0400, Todd Chapman wrote:
It will render a lot faster than updating a large number
of tickets individually.
table based layout? It could probably be changed easily.-Todd
On Thu, Oct 14, 2004 at 04:35:18PM -0400, Jesse Vincent wrote:
On Thu, Oct 14, 2004 at 03:42:47PM -0400, Todd Chapman wrote:
I’m not sure what you mean. For MultiSelect CFs the radio
buttons seem very appropriate and work out nicely.Sorry, I misread the patch. New concern: how radio buttons will render
with a 50 entry custom field.It doesn’t seem confusing to me.
be less flexible. Is there a more appropriate widget that
I am not seeing?-Todd
That could be done. Then we would need 3 SelectMultiple boxes:
one for values we want to add, one for values we want to remove
and one for values we don’t want to change. Then the user
has to now screw up by selecting the same value in more than
one box. And, since I want to default to a selection of “do
nothing” the user has to deselect a bunch of stuff.
This is why the radio buttons are much nicer.
We could switch from radio buttons to MS boxes for CFs with
more than X values, if you really, really want to.
We could make multiselect boxes work as nice as radio
buttons with the addition of some Javascript, but I don’t
think we want that.
-ToddOn Thu, Oct 14, 2004 at 05:08:25PM -0400, Jesse Vincent wrote:
I’m actually concerned about how big the page would be with 50 or even
500 custom field values. Why not use SELECT MULTIPLE boxes like we do
throughout the rest of the UI?On Thu, Oct 14, 2004 at 04:20:27PM -0400, Todd Chapman wrote:
It will render a lot faster than updating a large number
of tickets individually.
table based layout? It could probably be changed easily.-Todd
On Thu, Oct 14, 2004 at 04:35:18PM -0400, Jesse Vincent wrote:
On Thu, Oct 14, 2004 at 03:42:47PM -0400, Todd Chapman wrote:
I’m not sure what you mean. For MultiSelect CFs the radio
buttons seem very appropriate and work out nicely.Sorry, I misread the patch. New concern: how radio buttons will render
with a 50 entry custom field.It doesn’t seem confusing to me.
be less flexible. Is there a more appropriate widget that
I am not seeing?-Todd
–
That could be done. Then we would need 3 SelectMultiple boxes:
one for values we want to add, one for values we want to remove
and one for values we don’t want to change.
If the values aren’t in “add” or “delete”, they stay the same, no? I
think we only need two boxes per CF.
I’m not sure I understand the problem.
Jesse
That seems doable. If they are in “add” and “delete” then we
will just do nothing. I’ll resubmit the patch in the next day
or so.
-ToddOn Thu, Oct 14, 2004 at 05:18:57PM -0400, Jesse Vincent wrote:
On Thu, Oct 14, 2004 at 04:35:34PM -0400, Todd Chapman wrote:
That could be done. Then we would need 3 SelectMultiple boxes:
one for values we want to add, one for values we want to remove
and one for values we don’t want to change.If the values aren’t in “add” or “delete”, they stay the same, no? I
think we only need two boxes per CF.
I’m not sure I understand the problem.Jesse