More custom field revisions

[Sean McAfee]

"Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
>I've attached example of the admin screen in an attempt to "simplify"
>what was already there and also adds a couple of things present in the
>spec that weren't present on the ui.

The new page looks cleaner in some ways, and I originally envisioned
the page looking something like that.  However, this format presents
several opportunities for the administrator to enter incorrect or
irrelevant data.

*  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 proposed page layout eliminates the ambiguities and additional error
handling introduced by the first two items, and avoids the burden imposed
on the administrator by the last two.

>On the db structure:
>
>1)Shouldn't custom_fields.project be an integer foreign key?  

Yes.  I didn't think to check whether projects had integer indices defined
in some other table.

Oops...This reopens the question of how to designate the global scope.
A project of NULL is the obvious choice, but project's primary-key-ness
disallows that approach.  Maybe project should be a key, but not a primary
key.

Incidentally, I left foreign key constraints out of the schema, since it was
my understanding that MySQL doesn't enforce them.  Is this true?  Is there
any value in including them anyway?

>2)Wouldn't the custom_fields.field_id be the PK?

Possibly, but I expected that the custom_fields table would most often be
used to get a complete field list:

SELECT field_id FROM custom_fields WHERE project = ?

Probably this would be better:

custom_fields
-------------
field_id integer primary key,
project smallint,
display_index integer not null,
index (project)

But wait, if field_id is now going to be the primary key of custom_fields
AND custom_field_defs, then there doesn't seem to be any more reason to have
two separate tables.  So then:

custom_fields
-------------
field_id integer primary key,
project smallint,
display_index integer not null,
field_name tinytext not null,
field_type char not null,
required bool not null,
extended bool not null,
selection_id integer,
index (project)

>3)Shouldn't custom_field_defs have a "required" Boolean column?

It can.  There wasn't much discussion of it, but I'll add it provisionally
(see above).

>4)Perhaps renaming custom_fields.field_index to
>custom_fields.display_order to be more intention revealing.

I don't usually think of a single number as being an "order", but how about
"display_index" instead?  (Again, see above.)

>5)Perhaps rename custom_field_defs.field_name to
>custom_field_defs.ui_label to be more intention revealing.

Your modified cfadmin.html page appears to draw a distinction between a
field's "name" and its "display label".  Why are two identifiers necessary?
I envisioned that a single string would serve as both.

Similarly, why draw a distinction between a selection field's "true" value
(eg, "foo", "bar") and its UI value ("Foo Choice", "Bar Choice")?

>Perhaps a validation table as well?  If so, the "edit" section of the
>admin screen I've attached would have to be dynamic according to the
>field type.

I'd rather leave this as a separate enhancement to be addressed after the
basic custom field functionality is in place.  Does anyone else feel
differently?


-- 
Sean McAfee -- etzwane at schwag.org