Bugzilla enhancements

Wed Feb 2 15:32:58 UTC 2005

The custom bugs name can be done with the bug alias now.
The search at the bottom of the BZ page will take a bug id or an alias,
so your users can search by the old code.

We had a similar situation to yours with a legacy bug numbering scheme.
Bug numbers in our old database were made up of the 3 initials of the
person submitting the bug followed by a 4 digit number, where each user
had their own counter.  In the past, each user kept track of their own
counter on a PostIt note on their monitor or something. Bugs were written
up on paper (Using a template in Word for most testers), routed to the head
of programming who recorded them in a "database" (big flat text file edited
by hand in a text editor) and passed on to the assigned programmer.
We DID have a nice web interface that read the database and could generate
all sorts of reports.

To implement this in BZ I did the following...

1. Added a new table keyed off user_id which contained initials and
    the current bug number for that user.
2.  I don't remember if I had to tweak the new bug template to add
    the alias field .. I think I did.
3. Tweaked the cgi that presents the new bug form to read the user's
    record out of the new table and assemble their next bug id and
    put it in the alias field for them.
4. Tweaked the cgi that records the new bug to record the alias and
     increment the next bug id for the user.
5. Rewrote my old CGI report generator to read the fields out of BZ
   instead of having to parse the old text file.

And that was it.  Not too hard, but the changes to the customization
of the BZ code it will make updating BZ kind of annoying.

----- Original Message ----- 
From: "Max Kanat-Alexander" <mkanat at kerio.com>
To: <developers at bugzilla.org>
Sent: Tuesday, February 01, 2005 5:24 PM
Subject: Re: Bugzilla enhancements

> On Tue, 2005-02-01 at 17:31 -0500, Sean McAfee wrote:
>> process_query($sql, @bind [, $subref])
>
> Except for the subref part, that pretty much duplicates DBI's
> selectall_arrayref.
>
>> simple_query($sql, @bind)
>
> That actually duplicates DBI's selectcol_arrayref, pretty much.
>
>> single_row_query($sql, @bind)
>>
>> Prepares a statement handle from $sql, executes it with @bind as bind
>> variables, and returns the first returned row as a list.
>
> That's cool, but also pretty easy to handle with DBI.
>
>> ...all over the place, so these routines will accept arrayrefs as bind
>> variables as long as the corresponding placeholder is "???".  The 
>> routines
>> will expand the "???" to a comma-separated list of questions marks of the
>> appropriate length, and expand the corresponding array reference argument 
>> to a
>> list of the elements of the array before calling execute() on the 
>> statement
>> handle.
>
> That *is* pretty cool.
>
> The only thing I'd be nervous about is the fact that we ran into
> trouble when we hid the DBI interface in SendSQL, and now it's a huge
> effort to get rid of all that. I wouldn't want to hide it in some other
> way and then have similar problems.
>
> What *would* be nice is a function that just handles that ???
> situation, perhaps.
>
>> Auto Fields
>> -----------
>> [snip]
>
> Sure, definitely a cool addition to custom fields, that we could work
> on after the initial custom fields implementation (which, by the way,
> still needs to be split into separate patches so that I can start doing
> review on parts of it).
>
>> Bug Names
>> ---------
>> [snip]
>
> That's interesting, and people have asked for similar things in the
> past. It's not *so* different from aliases that it would be a high-
> priority addition, but it's still probably useful to a lot of people.
>
>> Links
>> -----
>> [snip]
>
> What sort of uses have you found for links above and beyond the
> dependency stuff?
>
>> Workflows
>> ---------
>> [snip]
>
> YES. This would be needed for any real "custom statuses" feature.
>
>> Transactions
>> ------------
>> [snip]
>
> Interesting. Sounds like basically just an addition of a table and a
> small modification to bugs_activity. Could be useful, maybe.
>
>> Journaling fields
>> -----------------
>
> Interesting. What use is there for this feature that gives users
> functionality that they don't have with comments?
>
>> Quick search
>> ------------
>> [snip]
>
> Interesting. It sounds like the primary use of this upstream would be
> as a sort of enhancement to what we have now for Saved Searches.
>
>
>> Custom query results
>> --------------------
>> [snip]
>
> If nothing else, this sounds like a much better solution for
> customizing columns than the one that we have.
>
>> Comments?
>
> Yeah. Submit patches. :-) File bugs, or pick some bugs that we already
> have for a few of those things.
>
> -Max
> -- 
> Max Kanat-Alexander
> Technical Support Manager, USA
> 2350 Mission College Blvd., Suite 400
> Santa Clara, CA 95054
> Phone: (408) 496-4500
> Fax: (408) 496-6902
> http://www.kerio.com/support.html
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dwilliss@microimages.com> 