The Road to 2.18 - Customfields
stu at asyn.com
Fri Mar 12 05:20:48 UTC 2004
This is a great start at getting a set of requirements identified.
I think we should prioritize the requirements. What is mandatory, and
what would be nice to have. Mandatory means that a solution MUST meat
that requirement. The nice to haves, are things that could be done by a
solution, but are not required right now. These might also be debatable
as to their need, or how to do it.
Some of the things Joel mentions I think fit the later category...
Joel Peshkin wrote:
> Steven Suson wrote:
>> I too perhaps should've posted my two cents worth earlier. There are
>> just two things that I wanted to say. One, that when discussing the
>> design issues, waiting, etc., that "best is the enemy of good
>> enough." And the other, that my company has been waiting
>> approximately a year for an extension of functionality to bugzilla,
>> which is FULLY provided by custom fields. I pity our poor secretary
>> who is forced to supplement our use of bugzilla, using paper and PDF
>> forms. Therefore, I heartily support Sean in his efforts.
>> Steven Suson
> Unfortunately, none of the patches seen to date is "good enough" at
> all. The team cannot just merge in a patch that is not written in a
> manner that will permit smooth upgrades from version to version, etc..
> I agree that we should not require the first customfields patch to do
> everything imaginable. There are a base set of design decisions that
> need to be agreed to and then a patch, consistent with the standards
> of the overall project, can be written an landed. The problem is that
> nobody has done that.
> I suggest that the following requirements be accepted.....
> 1) Schema changes must be made by checksetup in the standard way
> 2) Creation of new fields can be done either using the web (preferred)
> or localconfig/checksetup
Someone recently posted a concern about using a web interface to create
custom fields. I share the concern that a web interface makes it too
easy to add custom fields, and may encourage bad use of bugzilla. I
think it would make much more sense to be implemented via
localconfig/checksetup such that it forces a little more forethought
into the process. Furthermore, I suspect a localconfig/checksetup
solution would reduce the complexity of the implementation.
A requirement for a web interface for the setup should be postponed.
Although if we want the option of a web interface, then we should state
that the entire custom fields definition must be represented in the
database, rather than in code loaded in localconfig.
> 3) All activity log functions must still work with customfields. If
> this means that the activity log mechansim needs to be replaced, the
> old log information must be ported by the upgrade.
> 4) GUI forms must include custom fields and work, but need not be pretty
> 5) Possibly in a subsequent release, custom templates should be able
> to "hook" custom fields and handle them, overriding the builtin GUI
> generation that may be ugly or insufficiently localized.
> 6) Customfields that are missing from a bug form should never cause an
> error or deletion of a customfield when a bug edit is processed.
> 7) Email notification of customfield changes should work and be
> 8) If customfields are product-specific, no information should be lost
> on product change, even if the bug is changed to a product that does
> not use that field and back again.
> 9) No really bad SQL should be used. Multiple choices must be handled
> by one-to-many relations in the database, not by concatenating
> multiple items in strings.
> Notice that I didn't even say if I care if the patch supports multiple
> datatypes, etc... so long as the schema doesn't preclude adding
> additional types later.
> Now, if someone writes a real proposal, we can get consensus on it and
> go forward. Someone could also skip that step, spend months writing
> code, and then get frustrated when the code cannot land.
> -Joel [not on anything, especially software]
> To view or change your list settings, click here:
More information about the developers