More custom field revisions

[Jake]

Sean McAfee wrote:

>*  Suppose the admin sets the Display Order for all of the fields to "1",
>   checks them all, and presses "Reorder Selected".  What should happen?
>*  How should Bugzilla treat fields whose Display Order has been changed,
>   but which are not checked?
>*  In order to move the first field to the end of the list, the admin would
>   need to reset the Display Order of every field in the project.  This
>   would be awkward for only a few fields, and downright onerous (not to
>   mention error-prone) if there were dozens.
>*  Actually, any kind of nontrivial field rearrangement is going to present
>   similar difficulties.
>  
>
My thought would be to change the "reorder selected" button to a normal 
submit or maybe even reorder and have a layout someting like:

+--------+------------+
| Order  | Field Name |
+--------+------------+
| [ 1 v] | Cust_A     |
| [ 2 v] | Cust_B     |
| [ 3 v] | Cust_C     |
| [ 4 v] | Cust_D     |
| [ 5 V] | Cust_E     |
+-| 1  |-+------------+
  | 1.5|
  | 2  |
  | 2.5|
  | 3  |
  | 3.5|
  | ...|
  +----+

When you get a form submitted w/the same value twice you can either try 
and be smart about which one goes first or return an error (I don't care 
which, others might). Then you simply renumber them to integers. So if I 
change Cust_E to 2.5 and submit it the new form would be:

+--------+------------+
| Order  | Field Name |
+--------+------------+
| [ 1 v] | Cust_A     |
| [ 2 v] | Cust_B     |
| [ 3 v] | Cust_E     |
| [ 4 v] | Cust_C     |
| [ 5 v] | Cust_D     |
+--------+------------+

This should make it obvious that it's possible to "insert" one field in 
front of the others without needing to change every sort field.