Custom fields and more (was Re: 2.16.5/2.17.7 release prep)
suson at TuckerEnergy.com
Fri Feb 6 19:18:59 UTC 2004
See my comments interspersed with your message.
Again, many thanks,
Sean McAfee wrote:
>Steven Suson <suson at TuckerEnergy.com> wrote:
>>I'm VERY glad to hear that you are still working on Custom Fields! It's
>>unfortunate that you haven't been able to maintain the web interface for
>>field management, as I found it extremely easy to use.
>The main factors contributing to the obsolescence of that interface were
>a) the elimination of the field groups mechanism, and b) the elimination
>of field default values, which turned out not to be terribly useful.
>Anyway, if it's ever necessary to give a field a default value, it can
>be done programmatically.
>Incidentally, I created a module Bugzilla::Local as a repository for
>site-local code. In my last message I described how, when a new incident is
>created in a particular product, its "Incident Number" field is set to one
>higher than the current highest value of that field; the code that does this
>lives in Bugzilla::Local. What do folks think of this approach?
Anything that makes installation of your changes easier, is "A Good
>I'll try to get a basic patch out early next week. It's going to be
>quite a chore disentangling the basic implementation from the layers of
>functionality I've built on top of it, even with my efforts to keep things
>Oh, and here are a few more features I forgot to mention in my original
>message. Comments on their general usefulness or suitability are welcome.
>Fields may optionally have a brief textual description. For fields which do
>have such a description, a small icon appears next to the field's name in
>the web interface. If the mouse cursor is hovered over this icon, the
>description appears in a tooltip.
Enhances usability from the end-user point of view.
>A field may be made strictly read-only. Such a field may not be altered in
>any way via the web interface, but only programmatically. I use this
>feature to fix the alternate-bug-identification-number field I mentioned
>earlier, preventing users from altering it.
Since my company definitely has a use for the
alternate-bug-identification-number, I can see that this is entirely
>A long string field may be made "journaling", or append-only. Edits to this
>field are tagged with a standard prefix including the name of the user
>making the entry and the date and time.
An interesting feature.
>To view or change your list settings, click here:
More information about the developers