Some contributions

[Joel Peshkin]

Paulo Casanova wrote:

>
> Hi all,
>
> In my company we're using bugzilla and we need some extra features 
> some of which are bugs already reported in bugzilla.mozilla.org. We 
> have some effort to spend on fixing some things so I would like to 
> discuss whether it makes sense commiting those changes to the main BZ 
> dev trunk.
>
> 1. One simple feature we have already implemented (and I think it made 
> some sense commiting) is disable account creation. BZ now allows 
> disabling anonymous users so disabling account creation is a logical 
> step IMHO. Does it make sense? Should I post a bug with it and attach 
> a patch?
>
If you use a blank createemailregexp, then nobody (except an 
administrator) can create an account.  Does that do what you need?

> 2. Custom fields (bug #91047). Although some people disagree with the 
> need of custom fields, in IT we must do what we're paid for (I won't 
> argue about this). We're ready to start working on this one but I 
> would like some guidance.
>
s/91047/91037/

> I am thinking following the plan in comment #239:
> <snip>
>
> So, as a first step I would work on step 1 & 2. Any feedback is 
> appreciated. Thanks,
>
> Paulo
>
I think that both a valuable thing and a reasonable plan.  Actually 
getting Bugzilla contributions landed (merged) tends to be very 
difficult for new contributors and this feature is both very complex and 
has a history of being controversial so it is likely to take 3x-4x as 
much effort to get it landed as it would to make a patch for your own 
use against a specific version.

I suggest you work out a plan that permits sections of this to land even 
prior to exposing the feature to most sites and work with justdave to 
make sure that the plan has whatever type of pre-approval is appropriate 
so that you know from the outset that you are on the right track. 

You can usually find several of the right people (and a number of the 
wrong people) on irc://irc.mozilla.org/mozwebtools

With the plan in bug 91037, comment 239....  I would describe it as 
follows....

1) Get consensus on the way this interacts with the Bugzilla schema, 
Search, and Fielddefs.    When you do get to looking at fielddefs, I 
suspect you will find that you will want to propose some enhancements to 
Fielddefs first.  It would be a big help if fielddefs knew about more 
characteristics of a field than it currently does.  It is probably the 
most effective way for all of the rest of the code to become aware of 
any new fields and how they should be handled.

2) Implement the fielddefs changes. [probably land this change with no 
new feature]

3) Implement the code that handles administration of new fields.

4) Implement the code that works with the new fields in Bug.pm, 
Search.pm, and any cgis where the list of fields is currently 
hardcoded.  At this point, once someone who is willing to do their own 
template changes can use customfields, then land this.

5) Then, get fancy with templates that don't require hacking (but still 
permit it)

-Joel