UI module owner

[Frédéric Buclin]

> Exposing any new variable to the bugs templates requires changing the code.
> 
> Hiding a field that Bugzilla believes is required but is useless to your
> installation requires hacking up the edit script and the templates.
> 
> Adding any sort of validation routines for some of the more freeform
> fields requires hacking up post_bug.cgi, the templates, the error list,
> the xml importer, etc.


> As a side note, I've actually always been surprised that bugzilla has no
> transaction objects, considering that things either look really ugly, or
> are just broke, if the database is left half-modified. IE bugs with no
> initial comment, etc.  Why the process of modifying a bug in some
> manner, from beginning to end, for a single request that may change the
> bug, the duplicates list, and the comments, is not encapsulated in some
> transaction object is beyond me.

> Ideally, all the code *I* need to write to do what I want should be in
> separately source files that bugzilla loads and calls, and to be honest,
> for what i'm doing for GCC Bugzilla, I don't think this is unreasonable
> at all.

Related to what Daniel Berlin wrote about bug changes: several patches 
going in the direction you suggest are under review, see e.g. bug 
340278, bug 122922, bug 305136, bug 174988 and in a less direct manner 
bug 297791. They should make customization much easier. There is a good 
hope to see them fixed for Bugzilla 3.0.


LpSolit