Bugzilla enhancements

[Gervase Markham]

Sean McAfee wrote:
> Database utility routines
> -------------------------
> 
> These are already present in my last custom fields patch, but they're so
> useful it might be appropriate to put them in Bugzilla.pm or Bugzilla/DB.pm or
> wherever.

As I think someone else said, last time we wrapped the database routines 
(SendSQL()), we regretted it, and we've been undoing it ever since... I 
don't know if this is different.

> Auto Fields
> -----------

This seems somewhat specialist. I don't think we want to be encouraging 
people (for practical and social reasons, discussed in the past) to 
number bugs per-product. But maybe it'll fall out of the custom fields work.

> Bug Names
> ---------

I'd expect anyone who wanted this these days to co-opt the aliases 
mechanism. I'd be wary about implementing another thing very similar to 
aliases.

An enhancement to allow multiple aliases per bug (only one of which 
would be editable via the UI) might be good. That would enable easy 
support of this sort of thing while keeping the user-alias feature.

> Links
> -----
> 
> Links are arbitrary connections between bugs.

This is a good idea, and I think there's already a bug on it. (My idea 
was to have the "related" bugs as a tabbed row across the top.)

> The schema supporting links is very simple, consisting of a single table,
> LINKS, with two columns, BUG_FROM and BUG_TO.  

If you add a third column, RELATIONSHIP, you can subsume dependencies 
and even duplicates and have various other relationships (caused by, 
similar) as well.

> Workflows
> ---------
> 
> A workflow is a way of structuring the way a bug is worked by users.  

We do need to make the workflow customisable; there are bugs open on 
customised resolutions and customised statuses. I presume that one or 
both of these will give us a big checkbox matrix allowing us to define 
which states can be converted to which other states.

> Transactions
> ------------
> 
> All changes to custom fields, and a few standard fields, are logged with the
> date/time and identity of the user making the change.

Do we currently not do that (for standard fields) in the bugs_activity 
table?

> Journaling fields
> -----------------
> 
> Another Teamshare feature.  Long string fields may be tagged as "journaling".
> Such fields are append-only. 

Ick. We have this in the bug system at work. It's a really, really 
inferior system to discrete comments. Let's not inflict it on the rest 
of the world.

> Quick search
> ------------
> 
> This is a means of letting users avoid going through query.cgi by putting
> common searches in the page footer.

This is very swish, but is there much advantage to it over just hacking 
the templates to add the UI? Did you do an admin UI as well?

> Custom query results
> --------------------
> 
> The list displayed by buglist.cgi is grouped by product. 

Grouping (or sub-sorting, or both) would be cool.

Gerv