More custom field revisions

[Jon Wilmoth]

I agree the format does introduce the requirement for additional
validation logic.  My impression is that Administrators will appreciate
the "compact"ness of this design over the cost of having to make
corrections to their form values.  Below are proposed
validations/recourse.

-----Original Message-----
From: Sean McAfee [mailto:etzwane at schwag.org] 
Sent: Monday, April 21, 2003 5:00 PM
To: developers at bugzilla.org
Subject: Re: More custom field revisions

"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?
Display Order must be unique within the product.  The cgi script would
have to return an error indicating the display order couldn't be the
same for all entries.

*  How should Bugzilla treat fields whose Display Order has been
changed,
   but which are not checked?

It's a web based application.  The simple less-user friendly answer is:
there are certain concessions made in the web world, loss of data input
into forms is one.  We don't prompt the user to save bug modification
(if any) when they navigate away from the page.  I say this is the same.
Alternatively, effort could be spent to "protect" the user from
themselves with javascript.

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

This is a much more severe problem.  If there are any more than 5
fields, I'd get annoyed at trying to rearrange them.  Attached is a
variation of the previous admin screen to 

*  Actually, any kind of nontrivial field rearrangement is going to
present
   similar difficulties.

AGREED.  Please see new version.

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:

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

I think this will be an important addition for transitioning to a
generic field validation model for all fields (stock and custom).

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

Sounds good.

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

The name is a admin/developer friendly identifier.  The display label is
what would be displayed to the user.

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

Perhaps it's just my experience, but I've never seen domain values
stored as user friendly strings.  Typically there's been a code and a
decode value.  The distinction simply follows this model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030422/ff7ff5e0/attachment.html>