bugreport at peshkin.net
Wed Oct 13 14:00:53 UTC 2004
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.
> I am thinking following the plan in comment #239:
> So, as a first step I would work on step 1 & 2. Any feedback is
> appreciated. Thanks,
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
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
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
More information about the developers