More custom field revisions

[Jon Wilmoth]

	-----Original Message----- 
	From: Sean McAfee [mailto:etzwane at schwag.org] 
	Sent: Mon 4/28/2003 5:48 PM 
	To: developers at bugzilla.org 
	Cc: 
	Subject: Re: More custom field revisions
	
	
	>And
	>naming them with a numeric ID is ugly, opaque, and inconsistent with the
	>other fields.
	
	Ugly and opaque, perhaps.  I wasn't so worried about inconsistency, since I
	had envisioned custom fields as a different kind of beast than the standard
	fields.
	

	I think it's important to realize that this custom field change has tremendous potential for refactoring the standard fields into an even stronger implementation.  As I've found, familiar termanology is key to software acceptance by a user community.  Being able to change the display name of fields (as done with the cf proposal) is very useful.  Other site based required fields are another key aspect that have cross over potential.  I know this has the potential of increasing the scope of this bug, but I'd like to do as much as possible to not prohibit a very flexible application wide field implementation.  

	At the very least, using numbers for form field names will also make it very difficult to debug.  All-in-all, it's not alot of work to allow users/developers refer to a human friendly field name.  There are some issues to deal with though:

	1) The name, being an identifier, shouldn't be modifiable.

	2) The name, being an identifier should be unique.

	
	>>>It's not an automatic given that the custom field will be needed on
	>>>enter_bug. In fact, an argument could be made for not including any of
	>>>them by default.
	
	>> This seems a bit counterintuitive to me.  What is the argument for not
	>> including any of them?
	
	>Our current enter_bug page (the normal one, not format=guided) doesn't
	>include several of the more advanced fields, on the basis that bug entry
	>should be a reasonably low barrier-to-entry process.
	
	That's probably true for most Bugzilla installations, but the one I intend
	to set up here will be strictly internal to the company and used only by
	people who are very familiar with the products they'll be using.
	
	Perhaps a sitewide parameter always_show_all_custom_fields or somesuch?
	

	I think UI simplification is important and could be accomplished by identifying a group that has access to this field.  The template could then wrap the fields in a "isUserInGroup" check.

	
	>>>Remember to display all possible custom fields if
	>>>no products are selected. :-)
	
	>> Why?
	
	>Because no products being selected means you are searching all products.
	>But this is the same discussion as the one above.
	
	It had never occurred to me that one might want to search all products
	at once.  A product represents one particular class of incidents, which
	doesn't necessarily have anything in common with any other class of
	incidents, right?  (Except, necessarily, the fixed, global fields.)

	I see this happening more in the reporting screens where executive level reports would be generated across products (i.e. a engineering mgr).
	
	>> We seem to have stumbled
	>> onto a fundamental difference in our two conceptions of how custom fields
	>> should work.  In my view, each product *contains* zero or more custom
	>> fields, which are not shared with any other product.  There's no concept
	>> of "hard linking" between products.  It may be that two different products
	>> both want a date field called (say) "Date Received", and they can have them,
	>> just as two distinct fields.
	
	>I see what you are saying. But this doesn't fit with the current model,
	>where if two products have a field Foo, it's the same field (admittedly,
	>all our fields are global, but the point remains.)
	
	>And, it makes querying much more of a pain. Imagine I had five products,
	>four of which were software and one was hardware. The software ones all
	>had a custom field for a particular purpose - frobinage level, or
	>something. In your scheme, you would have to create this custom field
	>four times, and the search page would have four different widgets for it
	>if you selected products A, B, C and D, because fields are not shared.
	
	>A better model, in my view, is allowing a custom field to belong to any
	>number of products between 1 and N, where an N-product field is a global
	>one. This makes the querying much more intuitive, because you can select
	>A, B, C and D products, and get a single widget for querying them all
	>for frobinage level.
	
	Imagine this scenario.  A company is ready to bring its new Bugzilla
	installation on-line.  Some group has come up with a list of ten products
	(call them "A" through "J") each of which will require ten custom fields
	("A1" through "A10", "B1" through "B10", etc).
	
	If custom fields are not shared, the administrator simply creates the
	required products, then creates the fields within those products, working
	down the list he was given.
	
	If custom fields ARE shared, the administrator must search the entire list
	of fields for common purpose.  For example, the set of fields { A1, B2,
	F7, G3 } might all logically refer to the same thing, and so be represented
	by a single custom field.  Other such sets might be { A10, B10, ..., G10 },
	{ E4, G5 }, etc.  Hopefully they were assigned the same or similar names
	to start with, but maybe not.
	
	Creating a single additional product with its own custom fields would
	require an intimate knowledge of every custom field in every product,
	so that the new custom fields can be merged with the existing set.

	First of all, I don't believe there will be a large volume of custom fields, so an "intimate knowledge" wouldn't be difficult, especially for someone in an admin role.  Perhaps the custom field could include a description which would aid in this.  Also, a view of what products a particular CF has been associated with would make this admin very easy.  The proposed schema already supports multiple projects sharing a single CF.  Without sharing fields, searching becomes MUCH less reliable.

	custom_fields
	-------------
	project tinytext primary key,
	field_id integer not null,
	field_index integer not null
	
	
	Also, perhaps "frobinage level" means different things in the context of
	products Foo and Bar.  If fields are shared, and names must be unique across
	the entire Bugzilla installation, one of them must be renamed.

	Agreed.  I believe the consistency of reporting acheived by sharing by in far outweighs this small inconvenience.

	
	>Rephrase: why do we need multiline custom fields? (I have a sense of
	>deja vu asking this question.)
	
	Imposing a limit of one line on custom string data seems quite arbitrary to
	me.
	
	
	...By the way, I hope I'm not coming across like some kind of know-it-all.
	My expectations for how custom fields should work is doubtlessly heavily
	influenced by my experience with my company's current solution (Team
	Track), which isn't really that bad, except for the speed.  (And the
	price...and the closed source...and the convoluted schema...everything
	except the user interface, really.)  I'm hoping to offer the users here
	as seamless a transition as possible, when it happens, but I'll try to
	keep an open mind about adapting to more traditional Bugzilla ways of doing
	things.
	
	That's the beauty of open source...software design influenced by multiple experiences!
	--
	Sean McAfee -- etzwane at schwag.org
	----
	To view or change your list settings, click here:
	<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth@starbucks.com>