[Rt-devel] PATCH: Possible bug with bulk update of custom fields.

[Todd Chapman]

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

-Todd

On 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. :) Are you concerned about the
> > 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. :) Anything simpler would
> > > > be less flexible. Is there a more appropriate widget that
> > > > I am not seeing?
> > > > 
> > > > -Todd
> > 
> 
> --