91037 - (bz-customfields) A generic implementation for custom fields

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Tony Tyson]

This enhancements allows users to add custom fields to bugzilla. This is 
accomplished through 3 new tables on the database side. Enclosed is the current 
version (perl patch/schema/setup). Buglist (querying) and processmail still 
need to be updated. A nicer front end for adding the custom fields would be 
nice too.

Comment 1

[Tony Tyson]

Attachment: patch for perl changes against 2.12

Comment 2

[Tony Tyson]

Attachment: schema updates

Comment 3

[Tony Tyson]

Quick setup:
#
# Create a few new fields (valexp is a | delimited list of valid values)
#
mysql> insert into customfields (name,type,valexp) values 
('CF1', 'single', 'a|b|c');
mysql> insert into customfields (name,type,valexp) values 
('CF2', 'single', '1|2|3');
mysql> insert into customfields (name,type,valexp) values 
('CF3', 'single', 'a|b|c|1|2|3');

#
# Associate the new fields with a product
#
mysql> insert into products_customfields (product,cf_id)
    ->   select 'TestProduct' product, id cf_id from customfields
    ->     where name='CF1' or name='CF2' or name='CF3';

#
# Go ahead and update fields
#
mysql> insert into fielddefs (name, description, sortkey)
    ->   values( 'CF1', 'CF1', 42);
mysql> insert into fielddefs (name, description, sortkey)
    ->   values( 'CF2', 'CF2', 43);
mysql> insert into fielddefs (name, description, sortkey)
    ->   values( 'CF3', 'CF3', 44);

delete your versioncache and your off ...

Still needs some work. I'll contribute more soon.

Comment 4

[Tony Tyson]

Attachment: patch against buglist.cgi (2.12) to add query support for custom fields

Comment 5

[Tony Tyson]

I went ahead and implemented the ability to query on the custom fields. There 
is some reasonably complex stuff going on in buglist.cgi. I recommend anyone 
attempting schema changes to bugzilla to get a handle on that code first 
(unlike myself :)

So with this patch you can use the advanced query to search based on the value 
of custom fields like "Customer=TheFlintstones" or "Reproducibility>5".

Now you can create per product custom fields by inserting some values into the 
database. The resulting fields can be entered, changed, queried, and tracked 
via the activity table.

On the down side, doing queries with multiple custom fields results in several 
joins (potentially poor performance).

Comment 6

[Maciej Maczynski]

Attachment: Front end for custom fields

Comment 7

[Maciej Maczynski]

Attachment: CGI.pl patch (2.12) - add link to editcustomfields.cgi to standard bugzilla footer

Comment 8

[Roni Abusch]

I'm kind of confused - can you please write what steps I have to do in order to 
put new fields? I've tried to run the editcustomfields.cgi that you've attached 
and got a server error...

Comment 9

[Roni Abusch]

Sorry, I've meant a software error. The full error is this:
Software error:
select id, c.name, f.description, type, valexp from customfields c, fielddefs f 
WHERE f.name = c.name ORDER BY id: Table 'bugs.customfields' doesn't exist at 
globals.pl line 173. 

Comment 10

[Maciej Maczynski]

It looks like you miss "customfields" table.
Are you sure you've applied all changes described by Tony Tyson (first two 
attachements for this bug)?

editcustomfields.cgi is _just_ front end for database changes done by Tony.

Comment 11

[Roni Abusch]

So in general, to add new fields all I have to do is to create three new tables 
as described in attachment 2 [details] [diff] [review] of Tony, add code as described in attachments 1 
and 3 of Tony, and add editcustomfields.cgi?

Comment 12

[Maciej Maczynski]

Exactly.  You should also apply patch from attachment 5 [details] to make 
editcustomfields script available from standard bugzilla footer.  
Alternatively, you can add hyperlink to it on bugzilla main page or wherever 
you want.

Comment 13

[Roni Abusch]

As far as I understand, in the "Value expression" field I should enter the 
values that will show in the list. But I succedded to write there only one 
value. How can I have several values?

Comment 14

[Maciej Maczynski]

You must separate values with "|" character (you can find it in Tony's example 
above) e.g.: "one|two|three".
Maybe I will add some GUI for adding multiple values in more civilized way.
Or at least some help text.

Comment 15

[Roni Abusch]

Ok, now I've got it. Thanks, now I have my new fields working. I think it will 
be a great idea to enter this feature into the next formal version.

Comment 16

[Andreas Franke (gone)]

-> Bugzilla product, General component, reassigning.

Comment 17

[Maciej Maczynski]

Here are the results of my e-mail discussion with Tony and other usenet 
suggestions.  I put it here not to be forgotten in case someone wish to 
implement it (in Bugzilla 2.16?):

Generally, it seems that customfield needs some additional attributes to
be even cooler:

description (mediumtext) - Description of the field. On "new bug"/"query" pages 
field name can be hyperlink which displays this text.

default (mediumtext)     - Optional default value of a field. For fields of 
type "any" this may be regular expression that can match more than one 
selection.

mandatory (integer)      - boolean flag indicating if the field is mandatory 
for a new bug.  The user would not be allowed to enter a bug without mandatory 
customfield.

valid_exp (mediumtext)   - Perl regular expression to validate input. You could 
specify the field to be e.g. decimal number, string or whatever.

There should be the possibility to control customfields layout on "query bug" 
page. 

It should be considered how all this stuff affects performance (great number of 
bugs and customfield values).  

Comment 18

[Dave Miller [:justdave]]

Since we appear to be headed towards a template-based bugzilla, I would suggest
the following additional information should be stored about each field as well:

1) a flag that indicates whather the field will be dynamically inserted in the
"custom fields" area of the default template or not.  Reasoning for this is if
you want to put the new field somewhere specific on the layout, you would want
to turn this off, and manually place it in your custom copy of the template.

2) a flag to indicate whether the field should be included on the new bug entry
screen.  This might be able to be combined with the "required" flag, that is,
make the field "required", "optional", or "not needed".  required and optional
would both show up on the new bug entry page, and not needed would only show up
on the bug change form.

Comment 19

[Maciej Maczynski]

Attachment: Patch for editcustomfields.cgi

Comment 20

[Maciej Maczynski]

I've attached a patch for editcustomfields.cgi.
This prevents "zombie" customfields values to stay in bugs_customfields table, 
when customfields itselt is being deleted.
I think it is reasonable to delete values of customfiled when the filed is 
deleted...

Comment 21

[Maciej Maczynski]

Attachment: Support for customfields of type "any" and "multi"

Comment 22

[Maciej Maczynski]

I've attached a patch for full (I hope) support for customfields of 
type "multi" and "any".  This is obvious but - please backup your files before 
you apply it!  I had a little problem to stay in-sych with all those patches-to-
patches... 
The patch itself should be applied after all previous patches attached this bug.

Comment 23

[Maciej Maczynski]

Ooops... One more thing about 'Support for customfields of type "any" 
and "multi"' patch - you have to delete your data/versioncache file to make it 
work!

Comment 24

[Nicole Sweeney]

For future modifications to this entry, I'd like to contribute our situation... 
The issue for us is that we have a ton of products. They kind of break down 
into four categories, "client", "server", "requirements", and "other". Each of 
these categories will have different requirements on which custom fields are 
used. i.e the client products will need fields like "client os".

The issue is that it is difficult to pick and choose all of these products out 
of the list of hundreds for each custom field added. It is especially difficult 
because when new products are added, we have to remember to add the correct 
custom fields to it. What I'd like to be able to do is select a group and have 
it select those products for me... It could also extend to other areas, i.e. 
querying on number of bugs per group, etc.

Comment 25

[Martin Ellison]

Attachment: Puts table definitions (with indexes) into checksetup.pl

Comment 26

[Martin Ellison]

Attachment: Prints custom fields in 'long list' (formatted for print)

Comment 27

[Martin Ellison]

Also please note:

1. The field names in the bugs activity table have changed. Fix this by: 
diff -u -r1.5 process_bug.cgi
--- process_bug.cgi     11 Oct 2001 09:00:03 -0000      1.5
+++ process_bug.cgi     11 Oct 2001 23:28:55 -0000
@@ -1471,7 +1472,7 @@
              SendSQL($qstr);
          
          my $fid = GetFieldID($_);
-         $qstr = "insert into bugs_activity 
(bug_id,who,bug_when,fieldid,oldvalue,newvalue)" .
+         $qstr = "insert into bugs_activity 
(bug_id,who,bug_when,fieldid,removed,added)" .
              " values 
($bugid,$whoid,'$timestamp',$fid,'$cfbug{$_}[0]','$::FORM{$_}')";
          #print "<pre>$qstr</pre>\n";
          SendSQL($qstr);

2. The current implementation only works if the field name is a valid 
identifier. There needs to be something like $name =~ s|[^A-Za-z0-9]+|_|g in 
appropriate places.

Comment 28

[Maciej Maczynski]

You mean bugs_activity table definition changed from bugzilla 2.12 -> 2.14?
Does it mean that you were able to add custom fields to 2.14?
Actually, custom fields stuff is the only reason why I did not upgrade to 2.14 
so far.  I even did not try...

Comment 29

[Martin Ellison]

What is the status of this ticket v-s-a-vis 2.16?

Comment 30

[Matthew Tuck [:CodeMachine]]

There is no traction here wrt to 2.16, it is alongside many other useful patches
we would like to look at.

Comment 31

[Martin Ellison]

So what do we have to do to get it in?

Comment 32

[Matthew Tuck [:CodeMachine]]

For 2.16, there is little that can be done.  I don't see any way this is going
to make it.  But we're now trying for shorter release cycles, so this isn't such
a tragedy.

For getting this in faster, there are various things you can do.  You can
volunteer someone else as a reviewer (I've asked louie to take a look at this).

In terms of getting the code ready:

We want all MySQLisms removed so Bugzilla can be cross database compatible. 
This means (at least) no enumeration types, instead they should be converted to
IDs or plain integers.  Also mediumint will probably be deprecated in favour of
int as that is ANSI SQL.

We want all CGIs templatised and running in taint mode.  We're heading there at
the moment.  In particular, this work is going to clash with that, so I don't
see us getting far until that is no longer so.

See bug #86168 regarding templates.  Also regarding the edit*.cgi files, see in
particular bug #97706.  The initial work for this is currently housed on the
CUST_RES_BRANCH, which is bug #94534 among some others.  In particular I want
most edit*.cgi to use admineditor.pl on this branch.  This will give you easy
templatisation and taint mode.

I had thought this stored it's values in localconfig, apparently it doesn't
maybe I saw an older version, this is good.

An overview of how this currently works would be good too.

Comment 33

[Maciej Maczynski]

Attachment: Bugfix - "Change several bugs at once" with customfields

"Change several bugs at once" did not work with customfields -
customfields-handling code was outside the bug-processing loop.  This patch
puts it inside.

Comment 34

[Gervase Markham [:gerv]]

Not on the 2.16 train at the moment.

Gerv

Comment 35

[Nyles Harris]

I have applied all the changes for buglist.cgi that enable the long listing
for the custom fields but have noticed that the custom fields cannot be 
selected for 'custom column' arrangements.

Can someone suggest a fix for this?  I am attempting to create a simple
patch but would welcome some help from people stronger in mysql programming.

Comment 36

[jbishop]

Greetings,
i've patched added the tables to my mysql database and i've used the patches 
above but when i got to about patch number 5 (support for 'any' and 'multi' i 
noticed that bugzilla wasn't updating the new tables in the mysql database with 
the new custom fields when i commit the bug.  is this due to a patch i missed? 
any info would be helpful.

thanks.

Comment 37

[Maciej Maczynski]

You mean, you cannot see custom fields values, you've entered on "show bug" 
page?  Or you don't see these values in "bugs" table?  If it is "bugs" table 
which bothers you, then don't bother - custom fields are stored in separate 
table (bugs_customfields) which refers to "bugs" through bug_id field.

Comment 38

[jbishop]

No, I mean the custom field shows up in bugzilla, but when i alter the custom 
field and commit the bug, then go back and look the bug up again, it's always 
the default value.  When i look up my custom field in the Mysql DB it's empty.

Comment 39

[jbishop]

OK, i did all this last Friday so i've forgotten some info here.
I'm trying to get these patches to work in solaris 5.8...
the patches themselves didn't go through for most hunks, (I'm using the latest 
version of patch).  In order to get things off the ground i edited the files 
manually and added/deleted lines like the patches would have if patch was 
working.  this got me to the point were everything was working but the afore 
mentioned problem of the custom field not being updated in the database when the 
bug was commited.  Any more info on making the patches work themselves or 
the DB update issue would help out alot :)

Thanks.

Comment 40

[jbishop]

ok and it's bugs_customfields->values thats not getting updated.  bug_id and 
cf_id work fine.

Comment 41

[Maciej Maczynski]

First of all - it's pretty strange that you were not able to make the patches.
I've checked all my patches before sending it here (SuSE Linux)

Maybe you tried to patch 2.14?  The patches here are for 2.12, but some people 
claimed they were able to hack 2.14 too.

Second - providing you can see your desired customfields on enter_bug page,
there is only one place where its values goes into bugs_customfields table:
one "for" statement at the very end of post_bug.cgi, right before "Bug $id 
posted" printout.  As you say, you were editing the files manulay, maybe you've 
missed something in post_bug.cgi?

Comment 42

[jbishop]

Heh i figured it out afew days ago. this was rather stupid...
No we're using 2.12 here but someone created a values name in custom_fields 
with a space in it.  And thats all that it was.  :)

as for the patches... i still don't know why they don't work... :|

Thanks for your help though.

Comment 43

[David McCormack]

Does anyone have a jumbo patch for this against 2.15?

Comment 44

[Maciej Maczynski]

Attachment: Custom fields support for contrib/bug_emapl.pl

This adds support for custom fields for bug_email.pl (inserting bugs to
Bugzilla through e-mail). This patch is against Bugzilla 2.12!!!

You specify customfields in the mail body just like other fields (no spaces in
customfield name!), e.g.:
@DatabaseType = Oracle

The patch contains some other things as well:
- support form attachments of typy "inline"
- "qa_contact" is required only if useqacontact parameter is on.

Comment 45

[Nyles Harris]

Can anyone suggest a patch for "Change Columns" on the query page that will
select/deselect customfields?

I updated colchange.cgi to something like the following:

my @masterlist = ("opendate", "source", "contact", "company", .....

where "company" is a customfield.  Apparently this data is fed back into
buglist.cgi and that's where the actual change needs to be. 

I started to modify buglist.cgi to something like the following:

my @legal_fields = ("product", "version", "company", ..... but then realized
that customfields has its' own table and this approach won't work.

Can anyone give suggestions on how to get buglist.cgi to recognize the
different customfield selections from colchange.cgi?  I'm trying to get one
(or more) customfields printed in the issue list query output.

Comment 46

[Martin Ellison]

I'm coding a fix to include custom columns in 'change columns' in the query 
results. Changes to buglist.cgi, colchange.cgi and globals.pl.

Sorting by custom columns would require a major rewrite of buglist.cgi.

Comment 47

[Martin Ellison]

Attachment: Revised patch against 2.14.1 (alpha) part 1

Revised custom fields patch against 2.14.1 -- very experimental, please read,
discuss, test and correct. Doesn't include editcustomfields.cgi (see the next
attachment).

Comment 48

[Martin Ellison]

Attachment: Revised editcustomfields.cgi (part 2)

This goes with the previous attachment to this ticket. It is a revised version
of the custom fields definition editor. Again, very experimental, uploaded so
you can read, review, test etc.

Comment 49

[Martin Ellison]

Arguably there should be three attributes of a custom field:
- an identifier for use in HTML name attributes (e.g. 'EffortDays' or 
maybe 'customfield01')
- a name to be displayed next to the field value (e.g. 'Effort (Days)') and
- a description (e.g. "Estimated/actual effort in days").

We only have two of these at the moment. Does anyone have any preferences/ideas?

Also there is a bug in my revised patch (you get the wrong columns if you 
select "change several bugs at once" and also display a custom field). When you 
find some more bugs I may issue a revised^2 patch.

You may also notice that, if you display more than one custom field in the 
buglist, you can't sort by any of them. This is a feature.

Comment 50

[Andreas Franke (gone)]

Dave, since there is such a lot of interest in this patch, any chance of
reconsidering it for 2.16? Maybe "ifdef'ed" using Param('usecustomfields')?
This would make a lot of people happy. Would anyone of those who have worked on
this be willing to redo it when all templatization patches have been checked in?
Or maybe this can get in as the first thing after 2.16, followed by a 2.16.1
release for just this feature? This way, people using this can skip 2.16 and
directly upgrade to 2.16.1...

Comment 51

[Dave Miller [:justdave]]

considering we really did make it to "freeze mode" for 2.16, I think 2.17.1
sounds like a good plan.  Won't be long now.

Comment 52

[Luis Villa]

I just want to say that I strongly support Andreas' comment. Having this patch
in would make transitioning to 2.16 or 2.16.1 sooooooo much easier for me,
Ximian, and GNOME.

Comment 53

[Martin Ellison]

What would have to be done to get this into 2.16.1?

Comment 54

[Dave Miller [:justdave]]

hopefully there won't be a 2.16.1.  Even number minor revision numbers are for
the stable releases and security fixes to those releases.  2.17.1 would be the
next incremental feature release (and 2.18 would be the next stable release)

Comment 55

[Maciej Maczynski]

A'propos comment #49:
This seems OK. "description" could be accessible by clicking on custom field 
name on show_bug page.

An identifier for use in HTML name attributes seems OK - this will prevent 
syntax problems.  But maybe we could use custom field id for this? E.g. 
"cfield$id".  This way:
1. we would have HTML-correct and unique name
2. we don't have to introduce another identifier.
I don't think it will complicate the code.

Besides the issues mentioned in my comment #17, it would be good it there 
is a way to specify order of custom fields on "bug_form.pl" form. 
Maybe we need separate table (customfields_layout?), which would specify 
layout for each product. Layout could be an expression, like: "9,5|11", where 
the numbers are field identifiers and "|" is "line-break".  It seems like 
defining customfields set for product twice... Maybe someone have better idea?

BTW: does anybody have some experience how much customfields stuff affects 
performance? I mean really big database.  My bug-set (few hundreds bugs) seems 
too small to judge.




 

Comment 56

[Tony Tyson]

As far as performance, the bug database I'm using is up to 3,100 issues. We 
have 8 custom fields defined which results in about 24K rows in the 
bugs_customfields table. That table would be the most significant factor in 
performance issues. With about 50 or so active users, I would say that we 
really have not observed any performance issues.

Looking back at the schema, it would probably make sense to put a multi-column 
index on the bug_id and cf_id fields in the bugs_customfields table. Another 
option may be to make the value field a varchar(255) instead of mediumtext. 
That would restrict the max size of any value, including "or'ed" multi-values, 
to 255 characters.

Oh, and I'll be very happy if this enhancement gets into the final product :)

Comment 57

[Maciej Maczynski]

Yes, I think it is a good idea to make customfield value varchar rather then
mediumtext. From my experience it seems that customfields are rather used for 
storing short "tags" rather then long texts.
This limitation would probably hit "multi" fields first...
But - I think it can be an installation option: varchar(255) default.
You can start with varchar and optionally convert the column to mediumtext - it 
s is legal im mysql.

Comment 58

[Marc Hughes]

Attachment: Revised patch against 2.14.1 (alpha) part 1 - Patch Version 2

There was a bug in the previous "Revised patch against 2.14.1 (alpha) part 1". 
When you only had a multi-select custom field, it wouldn't appear on the new
bug form.  I changed line 583 of the patch from:
if (%customfield_popups || %customfield_text) {
To:
if (%customfield_multi || %customfield_popups || %customfield_text) {

Otherwise, I've been rather happy with the patch!

Comment 59

[Martin Ellison]

Could someone obsolete my "Puts table definitions (with indexes) into
checksetup.pl", "Prints custom fields in 'long list' (formatted for print)" and
"Revised patch against 2.14.1 (alpha) part 1" patches please? I don't have
permission.

Why do you want to restrict field values to 255 characters? Sometimes we want to
be able to write more e.g. a "testing performed" field.

I was considering an alternative implementation in which some custom fields were
stored on the bugs table instead. This would complicate the custom fields code
but the SQL would run faster. This would also allow a choice of datatypes for
fields.

Comment 60

[Maciej Maczynski]

About VARCHAR - it seems that I have rather wrong idea that this will give
better performance then mediumtext.  I've read a bit of mysql docs and it does 
not seem so. Some database expert should answer this question.

From my point of view, customfields are used to store some short tags, which I 
can query.  I use status whiteboard and attachments for long texts.
But, of course, if varchar has no better performance then mediumtext - why no 
use it.

Comment 61

[Jacob Steenhagen]

I'm not a database expert, but I can tell you that VARCHAR is cross-db complient
whereas MEDIUMTEXT isn't.  I believe VARCHAR is also more space conservative as
MEDIUMTEXT is quite large (see bug 96431).

Comment 62

[Martin Ellison]

In MySQL:

MEDIUMTEXT is 3 bytes + the text (not in SQL92), also TINYTEXT (1+) and TEXT 
(2+).
VARCHAR(n < 256) is 1 byte + the text (in SQL92).

So you are looking at an extra 2 bytes per custom field if you use MEDIUMTEXT.

PostgreSQL has TEXT and VARCHAR(n < 2^32) which are both 4 bytes + the text.
Sybase 12.5 has TEXT and VARCHAR(n < 256).

Text fields typically cannot be used in joins, or in where, order by, compute, 
group by, or union clauses.

Comment 63

[Martin Ellison]

There is a bug in editcustomfields.cgi -- if you have a custom field of 
type 'single' and a valid value includes a space, *sometimes* all the valid 
value text after the space is lost. 

I've looked through the code and I can't see any obvious cause for this 
behaviour.

Comment 64

[Luis Villa]

Question: is this version of the patch going to be The Answer for custom fields
post-2.16? Or at least something reasonably compatible at the DB and
configuration levels? It would be really nice to be able to have some assurance
that if I drop this on top of a 2.16 install when I upgrade to 2.18 I won't have
to redo all my custom fields Yet Again.

BTW, I'd strongly recommend taking a look at Scarab's custom field
implementation- I don't know how configuration is implemented in this patch (if
at all) but one of Scarab's strongest points (IMHO) is the extremely well
thought out web UI for adding custom fields. It's per product, which I think is
really overkill and uneeded by bugzilla, but otherwise is very slick.

Comment 65

[Martin Ellison]

No guarantees at all -- the contributors to the patch are all outside the 
Mozilla organisation. The Bugzilla support team are yet to look at it, as far 
as I know. They may well make changes, including changes to the underlying 
schema (changes to the user interface are less of a problem).

Comment 66

[Luis Villa]

>The Bugzilla support team are yet to look at it, as far 
>as I know.

That isn't strictly true; Dave and Matt both have and they are pretty core. But
yeah, Matt asked me to look at it... and that happened exactly never :/

Comment 67

[Martin Ellison]

The contributors to the patch would be interested in the fruits of your 
deliberations. 

In particular, is the major table (bugs_customfields) likely to change? 

(The other tables just contain the metadata describing the custom fields, and 
so anyone who implemented the current patch and then upgrded to 2.18 could 
manually reenter the metadata information if they needed to, but upgrading the 
bugs/customfields data itself is a bit more difficult and risky).

Comment 68

[Maciej Maczynski]

I think that even bugs_customfields can be changed if it only improves the 
whole stuff.  But in such case there should be a conversion script, which
take care of database update.
This sounds pretty obvious but can easily be forgotten...

Comment 69

[Martin Ellison]

Things to do for 2.16:

1. 'custom fields' needs sometimes to appear in the footer (template changes).
2. buglist.cgi -- merge in (nasty) code to display custom fields and (even 
nastier) code to sort on them; make these write to template variables.
3. enter_bug.cgi sets up template fields for each field; need to add a new 
template variable that is a hash (or an array?); need to modify template to 
display these.
4. long_list.cgi needs to pass the values of the custom fields to the template, 
which needs to be able to pick them up.
5. post_bug.pl needs to pass custom field values to the template; the code to 
analyse and action custom field parameters needs to be merged in.
6. There's a lot more that merges in nicely like process_bug.pl.
7. There is also the editcustomfields.cgi script, which should be templatised.

Comment 70

[Martin Ellison]

The next question is which variables should the *.cgi pass to the *.html.tmpl? 

bug_form.pl has a $bug variable -- perhaps we should add 
$bug.customvalues.$cf_id to it. or do we just use $bug.$cf_id?

bug_list.cgi has @bugs -- similarly for each item in this.

enter_bug.cgi (new bugs) passes various descriptors of possible field values -- 
either we set up an @custom_fields variable or maybe @custom_popups, 
@custom_text,...

long_list.cgi just needs the values really, so add to $bug the same as for 
bug_form.pl.

Any ideas on how to do this?

Comment 71

[Andreas Franke (gone)]

Martin, can you give short summary of the overall design from a birds eye
perspective (or some pointers to some existing docs, as long as they are still
up-to-date)? Is attachment 42496 [details] still valid? Do you think the new fields can be
used (or even should be used) for existing fields like OS or Platform, too? If
they are not specific to custom fields, maybe it's better to choose a more
general name like "generic_fields" or something? Is it worth to have the
reusable backend logic in a perl module like GenericFields.pm (or
SimpleFields.pm) or something? (The idea being that the cgi scripts only new a
few additional lines of code which call the backend routines in the perl module
with the actual parameters.) If this is possible, what would be the interface of
such a module?

Comment 72

[Martin Ellison]

The database schema in the 'schema updates' attachment is still in place 
(although the revised patch migrates this to checksetup.pl and makes minor 
changes). The custom field data is stored in a bugs_customfields table that has 
one row for each (bug, field) pair. The customfields table contains the 
description of each field and the products_customfields table controls which 
products (and so which bugs) have which custom fields.

An alternative solution would have been to add the custom fields to the bugs 
table, which would have been riskier and harder to administer but would provide 
faster performance.

The transition to 2.16 does not give any reason to change the database schema.

The transition to 2.16 is about 'templatising' the existing patch. Let me 
suggest (further to what I wrote yesterday) that (i) custom fields be 
named 'cf' . $cf_id i.e. 'cf1', 'cf2' etc so their values are passed to the 
template as $bug{'cf' . $cf_id} (or $bugs[$n]->{'cf' . $cf_id} for a buglist)
and (ii) we need a template variable $custom_fields{'cf' . $cf_id} that 
essentially is an image of the customfields table. 

Comment 73

[Shobhit Kanaujia]

Was this incorporated into 2.16? I am using 2.16rc and did not see 'customised 
field' feature in it. 

Comment 74

[Andreas Franke (gone)]

No, this is not in 2.16rc1 and will not be in 2.16. See comment 50 to 54 above.

Comment 75

[Matthieu Montagne]

I have applied all the patches from this page and adapted them to v2.16r1 but
attachment 57458 [details] [diff] [review] from comment 33 seems weird to me. I can't find from which
version it was created. I think a part of the patch is missing.
Actually it does not correspond to the previous attachment 42495 [details] [diff] [review].
I might be wrong because i'm not an expert hacker, but i think it's worth noticing.

Comment 76

[Maciej Maczynski]

Well, as far as I remember, it was a patch for attachment 49739 [details] [diff] [review].

Anyway - it seems to me, that all patches except the last one ("Revised patch 
against 2.14.1 ...") should be obsoleted - it seems like attachment 68323 [details] [diff] [review] 
contains everything necessary (except contrib/bug_email stuff, which is in 
attachment 64119 [details] [diff] [review])

Comment 77

[Matthieu Montagne]

Sorry, you're right.I didn't check the right patches.
So I'm working on a patch for version 2.16.But there's a problem with the new
sub-function is_tainted() in global.pl. I get this error :

Attempted to send tainted string 'update bugs_customfields set value='yes' where
cf_id=19 and bug_id=1' to the database at globals.pl line 250.

which comes from process_bug.cgi : (part of attachment 68323 [details] [diff] [review]) 

my $qstr = "UPDATE bugs_customfields SET value = '$new_value' WHERE
cf_id=$cfbug{$_}[1] and bug_id=$id";
SendSQL($qstr);

The comment for sub is_tainted() is "# Don't ask me how it works..." so it
doesn't really help me.
So if anyone knows what this function is for and what is wrong with the SQL
statement I would appreciate.

Comment 78

[Jouni Heikniemi]

I haven't looked at your code so I can't give you precise pointers, but shortly
and generally:

Running the perl code in taint mode means that you will have to validate all the
input coming from an untrustworthy source (such as HTML forms). Until an input
value is checked properly, it is "tainted" - and if you try to use a tainted
value in something critical (system() call, db access and so on), Perl will stop
you. This is a safety measure.

For more info on taint mode, please use Google. For this specific instance,
check out what the Bugzilla developer's guide says and examine the code,
particularly subs detaint_natural and SqlQuote. Probably you're just forgetting
to check the format of a certain value input from the form.

Comment 79

[Maciej Maczynski]

The statement itself seems pretty correct to me.
Maybe you should try: "update bugs_customfields set value=".SqlQuote("yes")." 
where cf_id=19 and bug_id=1" ?

Comment 80

[Fawad Khan]

Does attachment id 64119(This adds support for custom fields for bug_email.pl) 
work for version 2.14.1 also?

Comment 81

[Matthieu Montagne]

Attachment: Patch against 2.16rc1

Patch for customfields of type "multi" and "single" (what is "any" for?).
Includes the contrib/bug_email.pl patch against version 2.16rc1
Requires editcustomfields.cgi from attachment 49739 [details] [diff] [review]. (no templates for this
part)

I've been learning perl for just 3 weeks and this is the first patch of my
life, so be careful with it. But it works for me.

Comment 82

[Maciej Maczynski]

"any" allows you to put arbitrary text into customfield. It is presented as 
text input field on bug's pages. Very important (at least for me).

Comment 83

[Matthieu Montagne]

Ok I've added the "any" support. What I am supposed to do? Submit a new complete
patch, because I didn't keep the version without "any"...

Comment 84

[Maciej Maczynski]

I think it would be best to obsolete the attachment 86395 [details] [diff] [review] and add the new one.

Comment 85

[Matthieu Montagne]

Attachment: Patch for type "any" support against 2.16rc1

To be applied after the previous patch (attachment 86395 [details] [diff] [review]) against 2.16rc1

Comment 86

[Dirk Meissner]

I'm using BugZilla 2.14.1 with the "Revised patch against 2.14.1 (alpha) part 
1 - Patch Version 2" and the editcustomfields.cgi file. I have a couple of 
issues and would like to know if these are known issues. 
- The "Change several bugs at once" page is not supporting the custom fields. 
- Opening a specific bug, the custom fields only show up when the state is 
NEW, not if the state is ASSIGNED. It doesn't matter if I'm the reporter or 
assignee. 
- The Long Format List of Bugs will not show the custom fields. 
- Adding a custom field via colchange.cgi as an additional column will show up 
the column correctly in the bug list, but if you open the "Change several bugs 
at once" page the heading of the column is correct, but the content is from a 
different field. 

Comment 87

[Maciej Maczynski]

Unfortunately, the only answer I can give you is The Most Annoying Answer of A 
Developer: "it works fine on my site" :)
Maybe the author of attachment 68323 [details] [diff] [review] can give you the answer if attachment 
57458 [details] [diff] [review] was included there. I guess it was.

This patch lives for pretty long time (since 2.12). There is no single person, 
which manages all the changes, patches, patches to patches etc. We all are 
waiting for a day when it is included in Bugzilla main trunk. 

Comment 88

[Matthieu Montagne]

Attachment: Templatisation for editcustomfields.cgi

This attachment includes the templates for editcustomfields.cgi and the new
version of editcustomfields.cgi to use these templates. 
There still are several problems if someone wants to have a look at them : 
-The mandatory field doesn't appear after editing a custom field
-The javascript to check the fields of a new custom field is very simple. It
needs to be upgraded.
Any comments wellcome.

Comment 89

[davef]

for those of you trying to use the patch against 2.16, there's a fun off-by-one
bug leaves out the last bug in any search... Debugging this stuff is a pain in
the ass. My lame solution is to add:

if ($previousID) {
    push @bugs, $bug;
}

after the 
while (my @row = FetchSQLData()) {

block, around line 1510. So, it looks like:

while (my @row = FetchSQLData()) {
     ....
}

if ($previousID) {
    push @bugs, $bug;
}

------

hope this helps. email me if you need more explanation on what to fix.

Comment 90

[Matthieu Montagne]

You're right this part of the patch is awful (the bug is in bugform.pl).
Actually the problem is to try to query for all values within only one query.
The solution is maybe to add another query especially for custom fields, that
would make everything easier.

Comment 91

[Dave Miller [:justdave]]

bumping priority just to get it up in the queue a bit...  this has sat around
too long.

Comment 92

[Bradley Baetz (:bbaetz)]

The checksetup.pl changes look wrong - they only run if the table exists??

IS it posible to get a newer patch, against the trunk?

Comment 93

[Matthieu Montagne]

I said something wrong, comment 89 deals with buglist.cgi.
Anyway, I think that the detabase schema is not the right one, especially
bugs_customfields table. I've been thinking about it for days but haven't found
another schema. But IMO if this has to be into the future releases this should
be completely changed to make it really easier to query for bugs. At the moment
buglist.cgi has too many awful fixes, and very bad performance.
A sql specialist should have a look at it.

Comment 94

[Maciej Maczynski]

I'm not sure you can figure out anything different than Tony did.
We have two tables: bugs and customfields. Assuming we don't want to touch bugs 
table, the only thing to do is to introduce third table: bugs_customfields 
which will link together those two entities.

But - maybe a proper VIEW on database will do the job??? Unfortunately mysql 
does not support views (however it is on TODO list). 

Maybe totally different approach should be considered here (I was taking about 
it with Tony some time ago):
forget this patch and implement it as dynamic changes on bugs table 
(add/remove columns)? 

Maybe this would result in cleaner approach?

Comment 95

[Matthieu Montagne]

I can't tell if this would help getting better performance, but this would
obviously allow to treat every field as a custom field, and every custom field
as a normal one. It would make it much more easier to query the database.
Templatisation would be easier as well. It would be done once for all.
Can anyone tell if dynamical changes are possible regarding performance and
stability?
Anyway, I plan to have a second view on buglist.cgi to see if it's possible to
improve it.

Comment 96

[Maciej Maczynski]

That's the point! There should be no difference in handling of
"normal" and "custom" bug's attributes. Only such approach can be
"The Right Thing".

But - this would require great changes at the roots of Bugzilla, I guess. 
I don't think we should expect Mozilla to do so (I'm not sure if I would
like it either...) This sounds like breaking up a stable product.

I think this patch is a great _patch_.  I'm not sure how to do it
better.

I've been developing a system which was designed to allow user to
self-define own attributes of some entity (custom fields - that's
it). We solved it by making _all_ attributes except identifier
optional (custom). We implemented it as "third table" (actually 
set of tables)- somewhat similar to this patch but more complicated 
("custom fields" could be grouped, had their hierarchy, could be inherited 
etc.). The product were installed with set of predefined "fields".

The results were:
1. The system was really flexible. You could define almost anything
with no changes in the code.
2. The parameters-handling code was more complicated, but uniform - all 
parameters were "custom"
3. Performance was not very good, but fortunately acceptable.

That's my $0.25

Comment 97

[Bradley Baetz (:bbaetz)]

The schema looks fine - one more join on the bug_id should be quick.

Is it possible to get one single combined patch for all this against current
tip, preferably one without lots of needless whitespace changes everywhere?

I think that custom fields should be either 'freeform' (eg status whiteboard) or
'constrained' (eg platform, os). Constrained types could then be single or
multiple. This appears to be what you have here (with attachment 86582 [details] [diff] [review] included)
- is that correct?

Instead of using an enum (which isn't portable between databases), use a
constant defined in an appropriate file, and an int-type in the schema

The value for the custom field should not be a mediumtext (which allows 16 megs
worth of data). Maybe the table for custom fields should have an option for the
max length, otherwise a tinytext (255 characters) should be enough, shouldn't it?

make_popup and make_selection_widget should go away, and become part of a template.

multi-entry fields should be stored as multiple entries in the bug/cust_field
table, rather than | separated strings.

multi-entry fields should maybe have the option of being restricted to a certain
set of values; maybe you already do that.

You CAN NOT remove the -T option from the cgi files. Taint mode is required for
bugzilla scripts.

Thats a general overview; I haven't looked at specifics, though.

Comment 98

[Bradley Baetz (:bbaetz)]

Re comment #96, I (personally) would like to use this for replacing stuff like
hte status whiteboard, which is currently a param.

Lets do this in stages, though - first add this, then swap over.

Comment 99

[Bradley Baetz (:bbaetz)]

Oh, and perf is _definately_ an issue with bugzilla. That would need to be
looked at before doing what I said in comment #98.

For queries, this would involve one more join per searched attribute, which
hopefully shouldn't be too painful. It would, however, need to be measured.

Comment 100

[Martin Ellison]

What the current schema does give you is the ability to add custom fields on the
fly. You don't need to be a superuser, you just need the right group.

If you want to modify the bugs table, this is going to take a bit more
management.  You will need to have major permissions and it will take your
Bugzilla off the air for a while.

Other than that, it is arguably a good idea to put the custom fields into the
bugs table.

Comment 101

[Maciej Maczynski]

One should not forget another good thing about keeping custom fields
away from "bugs" table: you define custom fields for project, not for
entire Bugzilla. First, I considered this more bug than feature, but
now I'm sure it is OK.

Comment 102

[Luis Villa]

The lack of ability to make a custom field global is most definitely a bug and a
showstopper for us (bugzilla.gnome.org and bugzilla.ximian.com).  Recreating the
same custom field over and over again for 90+ products is just not an option for
us. I believe that Dave Fallon has patches to make this Do The Right Thing; I've
been urging him to comment on this bug for a while.

Comment 103

[Maciej Maczynski]

Well - there should definitely be an option to make custom field
global. But there should also be an option to make selected field
project-specific.  Maybe most projects share the same set of custom
fields, but some do not.  E.g. I don't like to see "Database Type"
field for a product which has nothing to do with databases.

Thus, "the lack of ability to make a custom field global" sounds like
GUI rather, then database-structure problem to me.

Comment 104

[Bradley Baetz (:bbaetz)]

I tihnk you missed the point - having these on the bugs table is definately not
the way to go.

I was talking about the possibilily of moving stuff which is currently there off.

Pretend I didn't say that bit for now :)

Comment 105

[Ludovic Dubost]

I would like to comment about the ability to make a custom field global:

- currently you can make a custom field apply to multiple products (at least
this seems possible in our installation).. So if you select all it will apply it
to all products.. of course this means that if a new products comes up you need
to update the custom field.

In addition to the suggestion to propose a 'global' assignement, I would like to
suggest the ability to make custom fields specific to components. In some cases
the way our products/components are organised this made a lot of sense.. If we
have time we will work on a patch.. if there are any suggestions about this they
are welcome..

Comment 106

[Bradley Baetz (:bbaetz)]

Don't use a global component, just store NULL in the product column in the map
table.

Comment 107

[Matthieu Montagne]

About make_popup and make_selection_widget mentionned in comment 97 they were 
in the patch against 2.16rc1 because of editcustomfields.cgi, but since I 
provided a "basic" patch to templatize editcustomfields.cgi they are no longer 
required (as far as I remember).
I say "basic" because as I mentionned earlier many javascript verifications 
were still required (they were in the initial editcustomfields.cgi), and the 
mandatory checkbox did not work. I don't have much time to have a look a all 
this.
I should mention as well that the templates for enter_bug.cgi were very simple 
and did not take positions into account. This should be improved too at least 
to prevent 3 listboxes to be in the same row (this was in patch against 2.14.1 
I guess), but it is not very complicated I think.
I will try to do a single patch for all this against 2.16rc2, but I do not know 
anything about how does checksteup.pl work (because Bradley said that something 
was wrong)

Comment 108

[Martin Ellison]

The present implementation allows you to attach a custom field to all *existing*
products -- you just select all products when you create the field definition.

But when you create additional products, they don't get the custom field. You
can go back and add the products to the all custom fields using the GUI (a real
pain, by the way, especially if you have lots of products).

Using NULL to mean 'all products' is likely to cause all sorts of problems in
your SQL code -- at the moment the SQL does joins on the product_customfields
table and those won't work if you have NULLs.

Comment 109

[davef]

Martin's comment #108 is exactly the issue we face with b.g.o and ximian's
bugzill a - we need custom fields to apply across the board, no questions asked.
Going and applying to every custom field each time a new field is added would be
a nightmare. So, I will happily volunteer to get a unified patch against CVS
since I've made this work for b.g.o already, but I have a few questions first
that we should work out so I'm not going in the wrong direction...

1. How are we going to deal with global custom fields, database-wise? My
preference is having custom fields default to global, with the presence of
entries in products_customfields defining if they only apply to a subset of the
products. This requires some code changes, since the current setup validates
against an associative array to see if a field is legal - we'd have to have
entries for every product x every global custom field, which would get
prohibitively rediculous. So, I think this should be changed to a function that
 deals with it more appropriately, returning all the fields limited to a given
product + all the global fields.

2. Is it realistic to move all the current bug fields to "custom" fields? If so,
we should think about changing some of the naming conventions so it makes more
sense. I think it's well worth doing, since it simplifies the template stuff,
and continues bugzilla down the flexibility path, but it's obviously not my call.

3. Custom templates and custom fields don't play well together - it's more
difficult than it should be to say "custom field X goes over here, Y over
there". Is there a way to deal with in the templates, by saying "iterate through
the custom fields, displaying all the ones that haven't been otherwise dealt
with" - I guess so, now that I think about it, but it means the iteration needs
to happen after the custom fields with fixed positions are displayed.

So, given this stuff, I'll start working on a patch - feedback would be greatly
appreciated, of course.

Comment 110

[Bradley Baetz (:bbaetz)]

1) Yeah,. thats the way to go (and is the way groups are moving, too)

2) Lets postpone that discussion. If we decide to do that, it won't be part of
the patches here anyway.

3) Yeah, in the edit.html.tmpl template, have the BLOCK which does the field
printing set [% $foo.displayed = 1 %] and then have the bit which iterates over
the custom fields only PROCESS the BLOCK [% IF NOT $foo.displayed %]

Comment 111

[davef]

Okay, cool, I'll generate a patch then, plus a bunch of bug fixes I've found.

Comment 112

[Martin Ellison]

We have half a dozen teams with a dozen or so products per team. The custom
fields apply at the team level (not globally) so we would like some way to set
this (preferably without updating each product). We don't have many custom
fields (about ten) so we could put them in the bugs table without any problems.

Many of the fields in the bugs table are referenced in the code by name, so you
couldn't treat them as custom fields. Custom fields (by definition) should not
have any specific code behind them.

I don't see any problem with referring to custom fields in local templates. 

Comment 113

[davef]

To make sure I understand, you want to say a given custom field applies to a
"team"? You can already say a given field only applies to X, Y, and Z products.
I presume you want, when adding a new product to a "team", have the custom field
automatically show up for that product (i.e., have the cfs associated with
"teams", not products necessarily). This seems reasonable, but I have no idea
what  you're using to represent teams. If it's groups, you'll probably need to
file a separate bug that this one blocks, as that's outside the scope of what
I've done/trying to do.

Comment 114

[Matthieu Montagne]

I've made a patch to change the way buglist.cgi queries for customfields.
Instead of the old method which joined less tables (just one), but got more rows
datas than necessary, this version uses more join tables (exactly as many as
custom fields that are to be displyed) but got exactly the datas required. I
can't tell wich one is faster, if someone can tell me what's best. Or if someone
can try on a huge database.
If it occurs that this method is the right one I will submit the patch.

I also tried "patch against 2.16rc1", it works fine against 2.16rc2.

Comment 115

[Matthieu Montagne]

Attachment: Templates for editcustomfields

A template was missing. The mandatory field now works.

Comment 116

[Bradley Baetz (:bbaetz)]

I'd need to see the code, but one join per custom field is probably better.

Comment 117

[Matthieu Montagne]

Eventually this kind of query is not a good idea because if a custom field is
created after the creation of a project, the bugs already in this project will
not be listed in longlist because they are not in bugs_customfields. A solution
would be to create a entry in bugs_customfields (with the default value) for
each bug already in a project when a new custom field is added. But that seems
pretty ugly. 

Comment 118

[Bradley Baetz (:bbaetz)]

When adding a mandatory field, then you will have to set the defaults for all
bugs. (or, if there isn't a default, then ask what to use for the addition)

Also, you could use a LEFT JOIN, and convert empty stings to mean no entry, or
something, but I do think that you are going to require an entry to be in the
custom fields table for every field for every bug.

Comment 119

[Thomas Stromberg]

Just in case someone is trying to port this to 2.17, I've got a somewhat working
patch against today's -HEAD. There are some outstanding bugs right now so I'm
not putting up the patch: buglist.cgi only sees X-1 tickets (a query that
matches 5 tickets only shows 4 found). The create.html.tmpl javascript for
popping up on mandatory fields may be broken as well. 

Comment 120

[Thomas Stromberg]

Attachment: customfields patch against HEAD (includes any)

Here's my first attempt at bringing this patch up to HEAD. I tried to change as
little as possible from the original, so don't yell at me too much for how
things are laid out. Since I've never seen the original in action, it's tough
for me to judge what worked and how it worked, but this at least seems to get
something started.

Comment 121

[Thomas Stromberg]

Attachment: Templates and CGI for editcustomfields (tarball)

A few updates to make this work properly in my installation (HEAD). In the CGI
I had to move confirm_login to after ConnectToDatabase, and exported the "type"
$vars for the template. When editing your customfields, you no longer have to
keep reselecting the "type" (it was defaulting to any).

Comment 122

[Matthieu Montagne]

The problem with n-1 bugs has been solved (see comment 89), the
editcustomfields.cgi problems with mandatory field has been solved (comment
115). make_selection_widget and make_popup are no longer required since you
provided a patch for templates for editcustomfields. A template was missing as
well as mentionned in comment 115.

Comment 123

[Thomas Stromberg]

Missed the n-1 comment, I (wrongly) presumed those comments talked about issues
resolved in the latest patchset. The updated patch & templates I posted should
have the fixes in comment 89 and comment 115 integrated - let me know if I
caused any regressions. 

Comment 124

[Thomas Stromberg]

I managed to find two bugs in the last patchset/templates:

When viewing a ticket that has a "single" customfield, it shows the first choice
as being selected (due to how dropdowns work). If we put a <option value=""> as
the first option for single's, this problem no longer occurs (haven't seen any
side effects yet).

customfields with spaces (such as "Build ID") in their names cannot be selected
as custom columns via colchange.cgi. This is due to the COLUMNLIST cookie being
stored as a space seperated list of values. This can be fixed trivially by
changing the join in colchange.cgi and the split in buglist.cgi to something
else (:: for instance), but has the side affect of forcing anyone who's got a
custom query column listing to go back to colchange.cgi and re-sumbit to get the
new fixed cookie. 

The other workaround for this issue would be forcing customfield names to not
allow spaces in them. This would be somewhat annoying, but less invasive. I'm
open for ideas here (sorry for barging in on the patches for this ticket, btw..
 I'm just prepping for a production instance here at work). 

Comment 125

[Thomas Stromberg]

Attachment: customfields patch against HEAD

New patch generated off of todays HEAD. Now urlencode/decode's the fielnd names
so that buglist.cgi & colchange.cgi don't have issues with customfields with
spaces in them. Thanks to justdave for the solution idea.

patch no longer includes make_selection_widget or make_popup, as they are no
longer used due to the new templates system.

Fixes all the bugs I know about.

Comment 126

[Bradley Baetz (:bbaetz)]

Comment on attachment 94340 [details] [diff] [review]
customfields patch against HEAD 

>Index: buglist.cgi

>+# Completely stupid : we get a complete record for each customfield 
>+# required in the list (2 customfields = 2 complete records taken from the base)
>+# The SQL request should be improved to change that.

So add a DISTINCT into the sql query.


>Index: checksetup.pl
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v
>retrieving revision 1.166
>diff -u -b -B -r1.166 checksetup.pl
>--- checksetup.pl	30 Jul 2002 14:05:20 -0000	1.166
>+++ checksetup.pl	7 Aug 2002 16:33:21 -0000
>@@ -1584,6 +1584,42 @@
>      userid mediumint not null default 0, 
>      quip text not null';
> 
>+# Table that defines custom fields
>+#
>+$table{'customfields'} =
>+  "id mediumint(9) default '0' not null auto_increment,

PRIMARY KEY this one, and remove the default.

>+  name varchar(64) default '' not null,

no default.

>+  type enum('any','single','multi'),

enums are Bad. Use a number instead, and add |use constant| into globals.pl

>+  valid_exp mediumtext not null default '',
>+  default_value mediumtext not null default '',

ditto, no default here/

>+  mandatory tinyint not null default 0,
>+  KEY id (id),

use PRIMARY KEY above, and then don't do it here.

>+  index(name)";

unique(name)

>+
>+#
>+# Product to CustomField join
>+#
>+$table{'products_customfields'} =
>+  "product varchar(64) default '' not null,
>+  cf_id mediumint(9) default '0' not null,
>+
>+  index(product),

instead, unique(product, cf_id), which allows product to be used here.

However, if you want this part, then you need to wait for bug 43600 to land,
which does this as an id, and will make the code a lot simpler.

>+  index(cf_id)";
>+
>+
>+#
>+# Bug to CustomField join
>+#
>+$table{'bugs_customfields'} = 
>+  "bug_id mediumint(9) default '0' not null,
>+  cf_id mediumint(9) default '0' not null,

lose the defauls; 0 isn't valid anyway

>+  value mediumtext,
>+
>+  index(bug_id, cf_id),
>+  index(cf_id, bug_id)";

You definately don't need both of these

unique(bug_id, cf_id)
index (cf_id)

should do

>@@ -2953,6 +2990,13 @@
> # Add a field for the attachment ID to the bugs_activity table, so installations
> # using the attachment manager can record changes to attachments.
> AddField("bugs_activity", "attach_id", "mediumint null");
>+
>+if (&TableExists('customfields')) {
>+     RenameField ('customfields', 'valexp', 'valid_exp');
>+     AddField('customfields', 'default_value', "mediumtext not null default ''");
>+     AddField('customfields', 'mandatory', 'tinyint not null default 0');
>+}
>+

Move this to be the last entry, and ad teh date/comment/bug # that all the
others have.

> 
> # 2002-02-04 [e-mail] bug 95732
> # Remove logincookies.cryptpassword, and delete entries which become

>Index: colchange.cgi

>@@ -71,7 +76,8 @@
>     } else {
>         foreach my $i (@masterlist) {
>             if (defined $::FORM{"column_$i"}) {
>-                push @collist, $i;
>+                # this allows spaces in customfields for the space-delimited COLUMNLIST cookie.
>+                push @collist, url_quote($i);

Yeah, thats fine. When we move the use CGI.pm then it will do the encoding for
us.

>Index: long_list.cgi
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/long_list.cgi,v
>retrieving revision 1.27
>diff -u -b -B -r1.27 long_list.cgi
>--- long_list.cgi	26 Jul 2002 18:16:39 -0000	1.27
>+++ long_list.cgi	7 Aug 2002 16:33:21 -0000


>Index: post_bug.cgi
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v
>retrieving revision 1.58
>diff -u -b -B -r1.58 post_bug.cgi
>--- post_bug.cgi	31 Jul 2002 12:46:02 -0000	1.58
>+++ post_bug.cgi	7 Aug 2002 16:33:21 -0000
>@@ -1,4 +1,4 @@
>-#!/usr/bonsaitools/bin/perl -wT
>+#!/usr/bonsaitools/bin/perl -w

Absolutely not!

> 
>+for my $cfname (@{$::customfields{$::FORM{'product'}}}) {
>+    my ($type, $valid_exp, $id, $mandatory, $default_value) = 
>+        @{$::legal_customfields{$cfname}};
>+}
>+

Wouldn't an sql query be easier? The versioncache is overused as is, and I
wonder if this just makes it more complicated.

>+
>+
> # Lock tables before inserting records for the new bug into the database
> # if we are using a shadow database to prevent shadow database corruption
> # when two bugs get created at the same time.

You'll need to read lock the custom field table too.


<skiped looking at of proces/post bug>

>Index: enter_bug.cgi
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v
>retrieving revision 1.69
>diff -u -b -B -r1.69 enter_bug.cgi
>--- enter_bug.cgi	11 Jun 2002 13:32:01 -0000	1.69
>+++ enter_bug.cgi	7 Aug 2002 16:33:21 -0000
>@@ -1,4 +1,4 @@
>-#!/usr/bonsaitools/bin/perl -wT
>+#!/usr/bonsaitools/bin/perl -w
> # -*- Mode: perl; indent-tabs-mode: nil -*-
> #

No.


>+#To use default values. Uncomment the following lines to use this feature.

eww...



>Index: defparams.pl
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/defparams.pl,v
>retrieving revision 1.81
>diff -u -b -B -r1.81 defparams.pl
>--- defparams.pl	31 Jul 2002 10:15:54 -0000	1.81
>+++ defparams.pl	7 Aug 2002 16:33:22 -0000
>@@ -155,6 +155,18 @@
>          "b",
>          0); 
> 
>+DefParam("preferlists",
>+        "If this is on, Bugzilla will display most selection options as selection lists. If this is off, Bugzilla will use radio buttons and checkboxes instead.",
>+        "b",
>+        1);
>+

You're merging other stuff here.

The creation code for custom fields also needs to ensure that you don't call a
custom field 'bug_id', or something like that.

Comment 127

[Dave Miller [:justdave]]

*** Bug 95966 has been marked as a duplicate of this bug. ***

Comment 128

[Jonathan Schatz]

ok, it looks like attachment 94340 [details] [diff] [review] is not the correct way to patch a current
(2.16) bugzilla installation with custom fields. is the current "reccomended"
way to use the 2.14 patches against 2.14.3 ? or is there an effort to port the
patches forward? (i'd hate to duplicate any work)

Comment 129

[Martin Ellison]

*is* anyone working on the 2.16 patch?

Comment 130

[Stuart Marshall]

has anyone got this working with 2.16? i'm thinking of trying to get it working
but it'd be good to know if anyone else has before i start.

Comment 131

[Stuart Marshall]

Attachment: customfields patch aganst 2.16

Seems to work ok although i haven't given it a huge amount of testing yet.
Tried it on a fresh install of 2.16 and all the patches were applied
successfully and it seems possible to add, edit, delete customfields, create
new bugs with them and query them - so I guess that's what matters.

Comment 132

[Arne Schirmacher]

The file editcustomfields.cgi appears to be missing in the patch file. Do I need
to download anything else?

Comment 133

[Stuart Marshall]

you'll need "Templates and CGI for editcustomfields (tarball)" (attachment
94231 [details]) as well as the patch. i didn't bother including editcustomfields.cgi in
the patch seeing as it's already in the tarball along with the templates.

put editcustomfields.cgi in your top-level bugzilla dir along with all your
other .cgis and put the templates in a customfields dir in your default
templates dir (bugzilla/template/en/default/customfields for me).

Comment 134

[Thomas Stromberg]

Attachment: Customfields patch against HEAD

Glad to see Stuart picking up the slack on this ticket. This is a patch against
HEAD that I've been sitting on for a bit, not based on Stuart's patch. This one
is against HEAD as of a few minutes ago, and appears to work in light testing. 


Currently, you cannot search customfields via this patch through the "Bug
Changes" area in query.cgi, which sucks. I'm not entirely happy with my
buglist.cgi hack is pretty bad too (second query), but gets the job done.

I don't plan on updating this patch again, but if I do, it may be using
Stuart's   updated patch.

Comment 135

[Stuart Marshall]

i think i've found a bug in edit.html.tmpl & create.html.tmpl when displaying
custom fields of type "single". it doesn't seem to show which item has been
selected. here's the patches that fix it:

--- create.html.tmpl.old	Fri Sep 27 16:10:45 2002
+++ create.html.tmpl	Fri Sep 27 15:46:02 2002
@@ -116,7 +116,9 @@
       <select name="[% c.name %]" >  
       [%- FOREACH d=c.values %]       
          <option value="[% d  FILTER html %]"
-           [% " selected" IF d == c.selectedvalue %] 
+ 	   [% FOREACH e = c.selectedvalues %]
+             [% " selected" IF d == e %]
+           [% END %]
            >[% d FILTER html -%]
         </option>
       [%- END %]

--- edit.html.tmpl	Fri Sep 27 15:37:49 2002
+++ edit.html.tmpl.old	Fri Sep 27 16:05:10 2002
@@ -178,9 +178,7 @@
       <select name="[% c.name %]">  
       [%- FOREACH d=c.values %]       
          <option value="[% d  FILTER html %]"
-           [% FOREACH e = c.selectedvalues %]
-             [% " selected" IF d == e %]
-           [% END %]
+           [% " selected" IF d == c.selectedvalue %] 
           >[% d FILTER html -%]
         </option>
       [%- END %]

Comment 136

[Saqib Rasul]

Stuart's latest patch for edit.html.tmpl disn't work for me and i think it 
should be left as it. Ofcourse i applied his patch over the patch against 
2.16 for the custom feilds.

also in the edit.html.tmpl, i noticed that for a "single" type when i was 
editing a bug, there was a empty-line entry and i removed this by adding 
the follwoing to bug_form.pl

    for (@{$::customfields{$bug{'product'}}}) {
  #  print STDERR "*** '$_'"; print STDERR " value: $bug{$_} *** \n";
  #  print STDERR "bug id: $id value : $bug{$_}  <br>";
    
    my %cbug;
   
    $cbug{'name'} = $_;
    $cbug{'type'} = $::legal_customfields{$_}[0];
    $cbug{'default'} = $::legal_customfields{$_}[4];
+    $cbug{'mandatory'} = $::legal_customfields{$_}[3];


and also changed edit.html.tmpl to

[%- FOREACH c = customfield %]
     [% IF c.type == "single" %]
       <td align="right" valign = "top">
         <b>[% c.name FILTER html %]:</b></td>
         <td align="left" valign = "top">
            <select name="[% c.name %]">
-              <option value=\"\">
+              [% "<option value=\"\">" IF c.mandatory == 0 %]
              [% FOREACH d = c.values %]
                <option [% "selected" IF d == c.selectedvalues %] value="[% 
d FILTER html %]">[% d FILTER html %]
              [% END %]
            </select>
         </td>
       <td>&nbsp;</td>

hope this helps ya'all...

thanks,

saqib

Comment 137

[Stuart Marshall]

sorry about that - i got the files the wrong way around when doing the diff for
edit.html.tmpl. i've modified my templates quite a lot so couldn't do a diff on
the actual files.

it's easy enough to do manually though - just replace 
           [% " selected" IF d == c.selectedvalue %] 
with
           [% FOREACH e = c.selectedvalues %]
             [% " selected" IF d == e %]
           [% END %]
in the bit for custom fields of type "single".

while i'm here, has anyone modified long_list.cgi & show-multiple.html.tmpl to
work properly with customfields? there is a bit in long_list.cgi and a reference
to look at show-multiple.html.tmpl but there doesn't appear to be anything there.

Comment 138

[Matthieu Montagne]

Well once more it's my fault, I forgot on part of the patch I presume. Here's
what you must insert into bug/show-multiple.html.tmpl on line 77 : 
<tr>
      [% FOREACH c= bug.customfield %]
       [% PROCESS cell attr = { description => c,
                             name => c } %]
      [% END %]
</tr> 
and that should work fine.
Anyway I intend to submit a new patch against 2.16.1 with every corrections
proposed by Bradley Baetz. It will propose as well a simple way to place the
custom fields on the report page and minor changes.
Bradley : you said : "enums are Bad. Use a number instead, and add |use
constant| into globals.pl". Ok to use a number, but I don't understand what I am
supposed to do with globals.pl (how can i put the correspondance between number
and text in global.pl?)

Comment 139

[Saqib Rasul]

I've noticed that the mandatory field of a custom field doesn't seem to have 
any effect. this is especially the case with an Any Field type which you can 
leave empty and commit changes to a bug. i am no expert at perl, but i am 
trying to fix this. will let you know how it goes...

Comment 140

[Stuart Marshall]

Attachment: patch against buglist.cgi

Found a bug in buglist.cgi: If you change your columns so that the buglist
includes customfields, only the customfield with the lowest ID will be
displayed alongside the correct bug. All the rest will be displayed alongside
the next bug in the list. 

Modified it so that the record is only added once all the customfields have
been processed for that bug.

Comment 141

[Saqib Rasul]

Also noted that when adding a custom field, it should't have any special 
chars like a '-' because the custom field's mandatory validation is done with 
javascript and it doesn't like field names with these special chars. There is 
also a bug in that when you go to edit a custom field, it doesn't show the 
name of the field. Also a bug in that when you delete a custom field, it 
still appears when you click on "New Bug". It doesn't go away till an hour 
later because it reads it from the data/versioncache and this only gets 
updated every hour.

Comment 142

[Stuart Marshall]

Just noticed that the patch against buglist.cgi (101701) I posted isn't perfect.
If you change your columns to include customfields then the buglist doesn't show
any bugs from before the customfields were added (or something like that - not
quite sure about it's behaviour). Although if you view a bug then it does
appear. Also it always reports one bug even when there are zarro bugs. Anyway,
don't have to time to fix it now but just though I warn anyone who has applied it.

Comment 143

[Christopher Heiny]

At our site, we are implementing a hack to support a "date" type in addition to
the "any", "single" and "multi".  The data is simply stored as plain text,
rather than taking advantage of MySQLs DATE datatype.  When a custom field of
type "date" is changed during bug submission or editing, it is stomped into a
uniform YYYY-MM-DD format, with invalid dates generating an error screen via
ThrowUserError.  Acceptable inputs are anything that Date::Manip will accept.

Is there interest in picking up this hack as a general addition to the custom
fields?  If so, I'll work on creating a patch against 2.16 for it once we're
confident in its stability.

Comment 144

[Bradley Baetz (:bbaetz)]

A proper patch for this bug should be extendable to almost any type. But yeah,
storing in text is really the only possible way. That will cause problems for
queries though, since we couldn't index on the date value. Hmm.

Comment 145

[Martin Ellison]

If you store dates as yyyy-mm-dd it will sort correctly. 

Comment 146

[Bradley Baetz (:bbaetz)]

Oh,  good point, and the indexing for < vs > would work too. Forgot about that

Comment 147

[Stuart Marshall]

I got around this problem by using a javascript popup datepicker with an icon
beside the relevant fields to bring it up. Obviously the user can still type in
an invalid date themselves but if they use the datepicker then it will always
insert a valid date in YYYY-MM-DD format which works for sorting and querying.
It also saves the user having to deal with YYYY-MM-DD format (at least when
entering and editing bugs - haven't modified the query page).

Christopher - I would be interested in your patch as some kind of validation
would be good.

Comment 148

[Christopher Heiny]

OK, I'll try to construct the patch later this week, after we've done some more internal testing.

The patch permits the user to enter dates in any format.  It converts valid dates to YYYY-MM-DD before storing them, and rejects invalid dates without storing them.

Comment 149

[Stuart Marshall]

Re: Comment 142-

Fixed problem with zero bugs not being reported:
--- buglist.cgi.old     Thu Oct 17 17:02:33 2002
+++ buglist.cgi Thu Oct 17 11:33:01 2002
@@ -1549,8 +1549,10 @@
 }
 
 # Add the final record to the list
-$bug->{'id'} = $previousID;
-push @bugs, $bug;
+if ($previousID > 0) {
+    $bug->{'id'} = $previousID;
+    push @bugs, $bug;
+}
 
 # Switch back from the shadow database to the regular database so PutFooter()
 # can determine the current user even if the "logincookies" table is corrupted


The other problem (where the buglist doesn't include bugs which were last viewed
before the customfields were added) wasn't really a fault in buglist.cgi. I just
ran a script to get each bug using wget which consequently populated the
bug_customfields table and now its ok. Definetly are neater ways to do it but
this seemed the easiest.

Comment 150

[Nyles Harris]

Has anyone produced a patch for processmail to show the new customfields?
That would be a nice addition to the features.

Comment 151

[Christopher Heiny]

I was trying to ensure that all my patches are up to date before submitting
the date patch, and am having trouble with Stuart's patch against his
buglist.cgi patch (see Comment 142 and Comment 149).  Patch 142 went in against
my version of buglist.cgi just fine, but the micro-patch in 142 doesn't.  The
comment "# Add the final record to the list" isn't in my version of buglist.cgi.
 Was this patch against HEAD or against 2.16?  Or am I out of synch somewhere?

Comment 152

[Stuart Marshall]

The comment "# Add the final record to the list" is from my original buglist.cgi
patch (attachment 101701 [details] [diff] [review]). Apologies if it's all got a bit messy & confusing
patching against patches. 
Basically all the patch in Comment 149 does is wraps 
    $bug->{'id'} = $previousID;
    push @bugs, $bug; 
in a conditional (if ($previousID > 0)) so that it doen't report 1 bug when
there are 0.
If you are unsure where in the code this is, it's just above
 "# Switch back from the shadow database to the regular database so PutFooter()"

Oh and it's all against 2.16.

Comment 153

[Christopher Heiny]

Aha!  Found it.  Thanks for the pointer.

Comment 154

[Matthieu Montagne]

Attachment: Patch against 2.16.1 with position support

This patch tries to apply every remarks made by Bradley Baetz (except getting
rid of enum. If someone wants to give me a hint on how to do that i'm ok).
Major changes :
-buglist.cgi rewrite: Now it is possible to use the "sort order determination"
even with customfields (which was not possible before). If you intend to order
a longlist by a custom field, and then remove this custom field from the list
of displayed columns, buglist.cgi deletes the custom order (which is not the
case for common fields)
		      The query is quite different from that in the other
patches (slower?, faster?). But the previous query did not allow to order
determination.
-When a custom field is created for a given product, every bug in this product
has an entry created in bugs_customfields set to the default value given.I
think this has to be done to keep a unified set of bugs.
-editposition.cgi is a easy and simple way to order customfields in the
templates. Positions are defined like that for example on the bug_entry form:
pos #1		   pos #2
pos #3		   pos #4,  etc...
A default position is given when a custom field is created (=max_position+1)
Maybe this is not interesting for anyone but who knows? A method will have to
be found not matter what, so why not give it a try.

Comment 155

[Joel Peshkin]

The trick for getting rid of enums is to either define another table going from
your values to text (probably overkill in your case) or to define constants in
the code.  The first known case of doing the latter of these is in bug 147275,
where there is now a Constants.pm

I am suprised to see the patches against 2.16.1  I think you are making life
unecessarily complicated for yourself.  If you do this against 2.17, then it may
actually get landed in the main product.  On 2.16.1, it would not.

Comment 156

[Matthieu Montagne]

Actually major changes are done in new files, that's why, for the most part, it
is not dependant on the version. I had a look at 2.17 and there will be just a
few changes for this patch.
I get the point on how to use constant instead of enum. Next patch will include
this and will be against 2.17.

Comment 157

[Jonathan Schatz]

ok, the last comment w/r/t the 2.17 branch was made more than a month ago. I've
started porting the 2.16.1 patch to the 2.17 branch. Is anyone else doing this?
Once again, I don't want to duplicate effort (I'm doing enough internal
customization on bugzilla that I don't need any _more_ work).

Comment 158

[Gervase Markham [:gerv]]

There is actually an open debate as to whether this is a good idea or not. This
discussion was inspired by a Joel on Software article:
http://www.joelonsoftware.com/news/20020912.html

I don't know what Dave's current thinking is, but you should probably find out
before doing lots of work. :-)

Gerv

Comment 159

[Dave Miller [:justdave]]

The current thinking is that we decide what the core types of these fields are
that we need to have available, and provide 3 or 4 of each hardwired in the bugs
table with a UI in the admin interface for customizing the labels shown to the
users or hiding/showing those fields.  This gives you a limited ability for
adding custom fields, while not creating headaches and performance issues with
multiple joins during queries.

Comment 160

[Ray Trent]

I would argue that it's up to the administrator of the DB to decide whether the
performance degradations or confusion of many custom fields is worth it (or even
significant, given the size of their installation).

I think it comes down to whether Bugzilla is intended to be usable in a general
corporate environment or not. 

If the answer is yes, then the number and type of custom fields isn't usually
under the control of the DB administrator, but rather is decided by some kind of
committee or by his boss. Yes, maybe that's a bad thing. But it's a real thing,
and the only purpose that would be served by making it impossible is to cause
Bugzilla not to be used. 

The ability to patch in arbitrary custom fields was simply a requirement (end of
story) when my company selected BZ for our bug db. If it wasn't there, we
wouldn't be using it. 

Also, frankly, companies that have wide ranging products (hardware/software/etc,
potentially each of which needs actual validly useful unique custom fields)
really can't live with a DB that has an arbitrarily limited number of them. 

Comment 161

[Joel Peshkin]

WRT comment 158:
  That Joel doesn't have to have custom fields.  This one requires them as do
MANY other sites.   There are many valid reasons for a site to need to add a
field.  It would be goodness to make that easy.  Sites that are expecting huge
loads may want to use some caution.

Comment 162

[Martin Ellison]

Could you make the number of custom fields an installation-specific 
configuration parameter? The site administrator could set this parameter before 
running the check setup script.

Comment 163

[Stuart Marshall]

If bugzilla is going to go the way Dave has suggested (i.e. hardwired fields
with customisable labels - comment #159) then it might be worth finding out how
many custom fields people currently have on the their installs. We've got up to
9 depending on the product so 3 or 4 would be rather limiting.

Also, It would be interesting to know how many people have noticed performance
issues after installing custom fields. I certainly haven't but our DB is pretty
small. And we don't have a problem with people finding the custom fields too
confusing as our bugzilla is only used by technical staff anyway (and manangers
too but they seem to be coping).

Comment 164

[Maciej Maczynski]

I'm afraid that if you set hardwired custom-fields number to N, you
will _always_ find someone who just needs N+1 (at least for N<100 :))). 

But maybe it would be possible to make fields number configurable through
checksetup.pl?  This way custom fields can be "bugs" table columns and
still be really "custom".

However, this way custom-fields would not be product-dependent. Most
custom fields I'm using right now is product-specific.

As far as I'm concerned, a small performance degradation is a
reasonable price for customizable fields. But my Bugzilla is really
small (bugs < 1000)...

Comment 165

[Dave Miller [:justdave]]

There's been a LOT of discussion about this on the developers mailing list the
last week or so.  New ideas for cleaner ways to implement it that won't involve
limiting the number of fields, etc.  If you're not already a subscriber, the
archives are available off of http://www.bugzilla.org/discussion.html

Comment 166

[Ray Trent]

After checking out the blog mentioned in comment 158 (an interesting set of
articles, to be sure), I've been thinking a lot about custom fields, and I've
come to the following conclusions:

1) Joel is partially right about custom fields, in that they can tend to make
the DB harder to use (especially mandatory custom fields). Also, for the most
part, the fields people want at first glance aren't really justifiable as
fields. In most cases, it would be better to give people better search abilities
and provide templates that stick the data into the description field a la
Mozilla's new bug page. 

2) Where I part with Joel is this: I think there are some categories of custom
fields  that *are* appropriate and useful (maybe even necessary). In particular,
some fields have special needs that can only be effectively addressed by a
custom field, for example: 

  a) Fields that must be searched/sorted/reported on (Some examples: Our work
process requires an ordered list of issues each engineer is working on. Also,
I'm required to generate reports on how well my team meets its written
commitment dates for fixing bugs). 

  b) Fields requiring formatting validation (e.g. dates, selection lists, email
addresses, URLs, etc.), especially when needed to enable effective searching
(e.g. it's hard to find all of a customer's bugs if the spelling of the
customer's name is left up to each bug reporter). 

  c) Fields needing security validation (e.g. only certain users can change that
data). Even if we don't want to implement such validation in BZ's custom fields,
some thought should be given to making customization for this purpose easier.

  d) Genuinely necessary required fields (the aforementioned customer name,
maybe). However, mandatory fields without format validation would probably be
better served by a customized bug template, so this is really a subset of b. 

  e) Fields that need to have customized processing applied to them. The
existing URL field is a bit like this, but different BZ installations will have
different needs. For example: I want to write some code to go through and mark
bugs as "Critical" if the "remaining effort" plus the current date is greater
than the "Customer Requested Date". It's much easier to deal with stuff like
this if these are actual (format validated :-) fields.

3) Different products will have different needs for custom fields. It's hard to
imagine wanting to sort or validate the same kinds of special fields for a
browser as for a database engine. 

4) My attempts at customizing the current bugs_customfields patch indicate it is
poor at serving these needs. The current design makes it extremely hard to code
the kinds of needed "special cases" described above, because even just selecting
records that have constraints on 2 custom fields requires quite advanced SQL
programming abilities (and usually is very inefficient). For example, the
current design makes it almost impossible to sort on more than 1 custom field,
yet sorting's one of the few valid justifications for having a custom field in
the first place. 

5) Any ideas for implementing custom fields that have all the custom fields as
separate columns in 1 table lead to database bloat, and require lengthy ALTER
TABLE's that might be hard to do in a production environment.

6) Any ideas that split chunks of the custom fields into different tables based
on product (or whatever) make it difficult to change a bug's product (or
whatever). Also, this kind of approach only reduces the ALTER TABLE problem a
little bit. 

7) Any ideas (like the current patch) that put all the fields into 1 table
without having separate columns for each field lead to multiple joins that are
very inefficient and complicated (or impossible) to program. 

My conclusion from all the above is that we want a fully orthagonal database
schema for custom fields. I.e. each custom field should have its own table,
containing only the bug_id and the field itself. Such a schema is in many ways
simpler to program than a single table mechanism, more powerful than most, and
reasonably efficient to boot. 

Yes, there are huge piles of joins, but they are (at worst) "eq_ref" joins since
the bug_id is a UNIQUE key and is the only thing you join on. In many cases they
will turn out to be "const" joins, which are even faster.

No ALTER TABLEs, no bloat, reasonably efficient and easy-to-program
searching/sorting (even with multiple custom field sort criteria)... what more
could we want?

Finally, many "custom fields" people want are really just intended to serve as
reminders about what to put into a bug report (or to make certain things
mandatory). In addition to true custom fields, I think we would serve the
community well by also providing a GUI-customizable and internally-supported
"new bug template" mechanism similar to Mozilla's new bug page. 

And, yes, I'm willing to put in effort to help with such a task...

Comment 167

[Gervase Markham [:gerv]]

> I'm required to generate reports on how well my team meets its written
> commitment dates for fixing bugs). 

I'm sure you've read Joel's comments on using a bug system for this sort of thing...

> b) Fields requiring formatting validation

This can be done using JS on the bug entry page, and using entry templates.

> 5) Any ideas for implementing custom fields that have all the custom fields as
> separate columns in 1 table lead to database bloat, and require lengthy ALTER
> TABLE's that might be hard to do in a production environment.

What is "database bloat", and how does this plan lead to it?

> Yes, there are huge piles of joins, but they are (at worst) "eq_ref" joins 
> since the bug_id is a UNIQUE key and is the only thing you join on. In many 
> cases they will turn out to be "const" joins, which are even faster.

I have no idea what either of those things are; but I would take a lot of
convincing that adding one join to every bug lookup for each custom field is a
good idea performance-wise. We cannot afford _any_ performance degredation in
Bugzilla - b.m.o. is slow enough as it is.

I agree that, conceptually, this is a clean way to do it - but I think we may
get overwhelmed by the practical issues involved.

> In addition to true custom fields, I think we would serve the
> community well by also providing a GUI-customizable and internally-supported
> "new bug template" mechanism similar to Mozilla's new bug page. 

We already have such a mechanism; it's not GUI-customisable but then neither are
any of our other templates, and we have no plans to make them so.

Gerv

Comment 168

[Ray Trent]

>> I'm required to generate reports on how well my team meets its written
>> commitment dates for fixing bugs). 
>
>I'm sure you've read Joel's comments on using a bug system for this sort of
>thing...

Not everything Joel writes is correct. It's a fundamental principle of
information management that information that's stored in more than 1 place is
subject to rot. A bug DB should store all company-necessary information related
to the fixing of bugs. I don't think this is really subject to question. The
only thing that's questionable is whether special fields are needed or if the
data can be stored in existing plaintext fields. I claim that some
(unpredictable to BZ programmers) data doesn't want to live this way. 

>> b) Fields requiring formatting validation
>
>This can be done using JS on the bug entry page, and using entry templates.

Ok, but if this is the answer for everything, why bother writing a general
purpose bug DB at all? Also, not all of us are browser/web programmers (i.e. I
would have to go to significant effort to learn JS, etc.). 

Anyway, a reasonably admin-friendly, customizable mechanism for entering bugs
and validating fields (and searching/sorting on the results of this) might be a
reasonable solution to this particular dilemma. 

BTW, bug entry templates also can take care of Joel's only valid reason for
objecting to custom fields: ease of bug entry. One can make an arbitrarily
simple (subject to business rules) bug entry template for use by people that
don't need the added complexity. 

>> separate columns in 1 table lead to database bloat, and require lengthy ALTER
>> TABLE's that might be hard to do in a production environment.
>
>What is "database bloat", and how does this plan lead to it?

Rows in tables are typically stored as fixed length records in most DBs that I
know of (for speed reasons). So if you have 30 extra custom fields (even if only
2 of them are used for each product), every row in the DB takes up all the space
used by all of the fields. While this doesn't necessarily matter directly unless
you expect to be disk-bound, it can have other performance ramifications,
especially if a row starts to exceed the size of a disk sector. 

>> Yes, there are huge piles of joins, but they are (at worst) "eq_ref" joins 
>
>I have no idea what either of those things are; but I would take a lot of

These are reasonably efficient DB join mechanisms that can rely solely on
indexed columns (and only need to grab 1 row for each combination of previous DB
lookups). 

>convincing that adding one join to every bug lookup for each custom field is a
>good idea performance-wise. We cannot afford _any_ performance degredation in
>Bugzilla - b.m.o. is slow enough as it is.

Again, b.m.o won't be affected by anything they don't want to be affected by.
There are no joins if you have no custom fields. There's no DB bloat if you have
no custom fields. With this fully orthagonal scheme there's *no* performance
degradation of any kind unless you actually add custom fields to the DB.

>I agree that, conceptually, this is a clean way to do it - but I think we may
>get overwhelmed by the practical issues involved.

Always a reasonable concern. Can anyone think of some practical concerns to
discuss about this idea (i.e. orthagonal DB schema for custom fields)?

Comment 169

[Gervase Markham [:gerv]]

> Not everything Joel writes is correct. 

I know that - I was just mentioning it.

> >What is "database bloat", and how does this plan lead to it?
> 
> Rows in tables are typically stored as fixed length records in most DBs that I
> know of (for speed reasons). So if you have 30 extra custom fields (even if 
> only 2 of them are used for each product), every row in the DB takes up all 
> the space used by all of the fields. 

OK, I get it. True. Thanks. :-)

>> Yes, there are huge piles of joins, but they are (at worst) "eq_ref" joins 
>
>I have no idea what either of those things are; but I would take a lot of

These are reasonably efficient DB join mechanisms that can rely solely on
indexed columns (and only need to grab 1 row for each combination of previous DB
lookups). 

> Always a reasonable concern. Can anyone think of some practical concerns to
> discuss about this idea (i.e. orthagonal DB schema for custom fields)?

As I think I've said in the newsgroup, custom fields really needs to be designed
 (if not implemented) by someone like bbaetz, who understands database internals.

Gerv

Comment 170

[Joel Peshkin]

[Note: This is the Bugzilla "Joel," not "Joel On Software"]

Perhaps the right approach is as follows....

1) Create a cumtomdefs (to store all the administrative controls for
customfields) customtext table, a customnum table, and a customdate table.  Each
of those other tables would keep the actual data and a link to what kind of
field (the def) and the bug or attachment to which the field applies.

2) Through administrative interfaces permit the admin to specify the following....

FIRST FIELD:
    Product/Component combinations (Default to ALL/ALL except NONE/NONE)
    Group membership to see field (Default to none needed)
    Group membership to change field (Default to none needed)
    Title of FIRST TEXT FIELD
    field type (text/number/date) (and size???)
    X include on Bug entry form

Next FIELD ....

In templates, have default run-time code that plops the relevent custom fields
in the relevent forms UNLESS something else in the template tells it not to. 
Also, provide functions to make it easy for a template to either call up the
fields or not. (might not even need the functions)

In queries and reports, it should be easy enough to build in.

Comment 171

[Dave Miller [:justdave]]

OK, Zippy volunteered one of their DBAs to chat with me about this for an
afternoon, and here's what he suggests:

Since each table you add needs to be indexed on bug_id, and every time you join
it is going to be another index to scan.  Therefore he suggests that for fields
which have a 1 to 1 relationship with a bug (the field can only exist once on
that bug - CCs and dependencies are good examples of things that DON'T fit this
definition) that each should be a new column on the same "custom fields" table.
 This way there's only one join to get all of the fields, and there's only one
index to scan in order to perform the join.

Fields that have a one to many relationship or a many to many relationship would
each be stored as a separate table, for obvious reasons. :)

We would of course need some sort of "metadata" table which contains information
Bugzilla can read about what fields are available and where they're stored.

I don't think much UI would be required from the web side for editing it...  An
interactive shell script would be fine.  In fact, an interactive shell script to
do it would be necessary, even if we do have a web interface for it.  Why? 
Because in enterprise production environments, the Bugzilla user isn't going to
get add/drop rights.  Schema changes in the production database need to be made
by a DBA account (not an application access account), and in a lot of cases that
means the DBA himself has to run said script.

Schema changes are not taken lightly in enterprise environments, so it's not
something you can just up and do on a whim.  (and yes, that's being taken into
account in the rewrites being done to checksetup.pl for supporting Sybase and
Postgres - so a DBA can run the schema updates section with a separate password
if necessary)

Comment 172

[Jouni Heikniemi]

Any shell script is bound be highly problematic cross-os-wise. If the "shell 
script" can be in Perl, we're much better off - but it's a standalone 
application, then.

Comment 173

[Dave Miller [:justdave]]

Well...  it's kinda hard to use DBI from the shell...  ;-)

Yeah, it'd be a Perl script.  I simply meant it would be accessible from the
shell. :)

Comment 174

[Gervase Markham [:gerv]]

I don't think that changing the structure of your database is something that
requires a web interface :-) But your DBA has an excellent idea. Put
single-value fields in one table, and multi-value fields in their own tables.
This way, we can convert all of os, platform, url etc. to custom fields without
b.m.o. losing performance.

Gerv

Comment 175

[Martin Ellison]

This seems a good idea. I'm not sure that we need many-to-ones; just the one 
custom fields table (plus any metadata support).

Comment 176

[Ray Trent]

Not sure I understand the implications of this latest suggestion to the problem
of "multi-select" custom fields. As currently implemented in the custom fields
patch, these are 1::1, because all the current selections are stored in the
single text field and are decomposed for display, and searching naturally does
the right thing (mostly). 

One could argue they are "many-to-one", but I'm not sure how useful that would
be vs. the current implementation. They "look" 1::1 to users. 

In case anyone's curious, the main place I think multi-selects belong are areas
like Hardware/OS(s). The current BZ kludge of "All" isn't really that useful,
IMNSHO... it should be obvious and easy to search for all issues that affect,
say, Win2k. Another example might be "Languages" for localization issues. 

Comment 177

[Bradley Baetz (:bbaetz)]

Dave: DBI::Shell could be fed a sql file, but...

Anyway, there are several custom fields types.

1-any - stuff like status_whiteboard
1-N - platform - 1 bug has multiple choces, but can only pick one
M-N - platform allowing multiple options - one bug has multiple choices, and can
pick as many as they want.

For the N-N stuff, we definately need a join. For the 1-N stuff, we do too. The
1-any stuff is a bit trickier.

The problem is that I don't see the problem in the join. If we search on a text
field (like status_whiteboard), then we need to do a table scan anyway, and the
join overhead is lost in the noise. If we're not searching, then its only going
to be used for display, and for one bug, a quick index lookup would be fine. And
I can't think of anything else a 1-1 mapping would be for, apart from text
fields (They could be used for checkboxes, but we have request flags for that)

IOW, the 1-1 mapping is (bug_id, field_id, value) with indexes on bug_id and
field_id. The lookup is trivial with subselects, and we can even cache the
field_name->id mapping in the versioncache to get rid of one of them. (That may
not be worth it; if the fieldname->id table is in the db's cache, the db can
probably do a lookup in C faster than we can in perl)

1-N mappings for versions and the like are needed to avoid the problems we have
now, wrt renaming them, and so on. So we'd be linking to one or more numbers, in
a separate table (separate because of the join speed for the text index jointing
to an int, and the like). That table could handle 1-N and N-N stuff easily.

The idea of changing the schema behind the scenes doesn't exactly fill me with
confidence. I also don't want to go this way just because mysql's optimiser sucks.

Lets be honest - we have really low requirements on our database. We don't do
anything fancy at all, really. DB speed is not a limiting factor for us, with
the exception of buglist.cgi, and for most of those queries mothra's age is the
issue. Premature optimisation is the root of all evil, and such.

Comment 178

[Bradley Baetz (:bbaetz)]

Oh, and one extra problem with the 'add a column to the table' thing is that
there have been requests for product specific fields, and doing this as a column
would waste space, and the like. I'm not sure if thats significant, but I guess
it could add up.

Comment 179

[Stuart Donaldson]

While product specific fields could be pretty nice in some cases, there is a
much more general need to at least have some level of custom field control. 
Even having a fixed number of 1:1 fields that you could just rename would be a
huge improvement over what we have now. The approach most recently discussed
would be of tremendous help to many of us who need some level of custom fields.

Comment 180

[Colin Ford]

I've tried out this patch and I seem to keep getting...

INSERT INTO bugs_customfields VALUES(35, , ''): You have an error in your SQL
syntax near ' '')' at line 1 at globals.pl line 277.

when I commit a new bug. I patched off 2.16.1 and everything went well?

I added a custom field and then deleted the custom field. I checked the database
and there are no customer fields but it keeps happening.

Comment 181

[David Bernick]

I put the Patch Against 2.16.1 against a 2.16.2 tree. 
So far things have been pretty smooth except for in the 
editcustomfields.cgi  I had to add:
    trick_taint($valid_exp);
    trick_taint($mandatory);

To avoid tainting (line 156).

in buglist.cgi
removed "as " part from
push @fields , "bcf$cf_id.value ";
(line 323)

now to see if I can add the custom columns to query.cgi.

Comment 182

[Stuart Marshall]

Has anyone upgraded their bugzilla custom fields install from 2.16.2 to 2.16.3?
I just did using CVS and when I ran checksetup.pl I got errors reported in
globals.pl. Anyone else had this problem and got a quick fix for it? 

Comment 183

[Stuart Marshall]

Had a look into it and it seems there was an error while merging globals.pl
(although I'm sure I never saw any error messages during the update). If anyone
else gets the problem, here's what you have to do to fix it:

566,567c566
< <<<<<<< globals.pl
<     print FID GenerateCode('@::legal_components');
---
>     print $fh GenerateCode('@::legal_components');
574,575c573,574
<     print FID GenerateCode('%::customfields');
<     print FID GenerateCode('%::legal_customfields');
---
>     print $fh GenerateCode('%::customfields');
>     print $fh GenerateCode('%::legal_customfields');
577,579d575
< =======
<     print $fh GenerateCode('@::legal_components');
< >>>>>>> 1.169.2.15

Comment 184

[J. Paul Reed [:preed]]

Sorry for the spam, but someone came into IRC asking about custom fields; Gerv's
page on the subject should be easy to point people to in that situation.

Comment 185

[Saqib Rasul]

we've been using custom fields for a while, and we are using Bugzilla 2.16 with
the customfields patch against 2.16 of 2002-09-24 09:22:00. And here is what we
think is missing:

- bulk updates (as in "change several bugs at once") does nothing for custom fields
- Saving bookmarkable templates doesn't save values of custom fields
- buglists that display columns that are customfields are not working as bugs
which don't have custom fields don't get shown on the buglist. We have since
fixed this, and would recommend the following in the buglist.cgi around line 303:

     if (@custom_columns > 0) {
         #push(@fields, "bugs_customfields.cf_id ");
         push(@fields, "customfields.name");
         push(@fields, "bugs_customfields.value ");
         my $cf_left_join = "LEFT JOIN bugs_customfields ".
              "ON bugs_customfields.bug_id = bugs.bug_id " .
              "AND bugs_customfields.cf_id " .
              "IN (" . CustomFieldNumbers(@custom_columns) . ")";
         push(@supptables, $cf_left_join);
         push(@supptables, "LEFT JOIN customfields ".
              "ON customfields.id = bugs_customfields.cf_id");
     }

Can anyone tell me if the newer patches address any of the issues which i have
listes?

thanks --saqib

Comment 186

[Albert Ting]

Curious question, will this feature allow you to add custom fields tied to a
specific product?  Or maybe tied to a specific group (assuming people can be in
multiple groups).

Thanks! 

Comment 187

[Saqib Rasul]

From the patch we applied (2002-09-24 09:22:00), the customfields were
per-product. Maybe the newer patches address your requirements.

Comment 188

[Irfan Deen]

I just setup Bugzilla 2.16.3 on Mandrake and it is up & running
I happened to look at Bug 91037 and I found that u have implemented custom 
fields
 
I am confused where to start from.There are some 200 comments on this bug.
The comment 131 seemed to me the start point.
 
I copied editcustomfields.cgi to my top level directory and the templates from 
customfields dir to /bugzilla/template/en/default
 
These are the only steps I followed.Do I need to make any changes to mySQL.
Shall I see some kind of GUI which allows me to add custom fields.
 
Can u please email me the step by step procedure for implementing custom fields.
I would really appreciate it
 
Thanks
Deen

Comment 189

[Vijayan Reddy]

After reading through these 200 comments, it sure is confusing about how to
reach a solution. I find many patches for patches, making it difficult to find
the right patch to apply that works.

Does anyone have a to-be-applied-from-scratch patch file ? I want to apply this
on my 2.16.3 bugzilla installation. 

I have found these shortcomings so far

* No support for custom-fields at the query page (query.cgi)
* "Change several bugs at once" doesnt work for customfields
* Sorting on the Customfields on the buglist.cgi (result of a query) doesnt work
* editposition.cgi doesnt work

Can someone help with a stable set of patches that we can use ?

Comment 190

[Saqib Rasul]

* No support for custom-fields at the query page (query.cgi)

the customfields are in the drop down box down the bottom left of the query page
under Advanced Quierying using Boolean charts

* "Change several bugs at once" doesnt work for customfields

We got this working and hope to have a patch soon. we are currently testing it

* Sorting on the Customfields on the buglist.cgi (result of a query) doesnt work

true.

* editposition.cgi doesnt work

no comemnt.

Comment 191

[Ludovic Dubost]

Attachment: Patch Agains 2.17.4

I've ported the patch to version 2.17.4 with minimal testing..
Most of the changes have been because of the change from product to product_id
in many tables..

Comment 192

[Ludovic Dubost]

Attachment: Patch Against 2.17.4

I've ported the patch to version 2.17.4 with minimal testing..
Most of the changes have been because of the change from product to product_id
in many tables..

Comment 193

[Ludovic Dubost]

Attachment: Patch Against 2.17 HEAD from Sept 16th 2003

I've ported the patch to the HEAD of Sept 16th 2003 with minimal testing..
Most of the changes have been because of the change from product to product_id
in many tables.. 
HEAD of Sept 16th is post 2.17.4 and before 2.17.5

Comment 194

[Thomas Schmidt]

using 'Sept 16th 2003' patch (attachment id=131562) leads to a server error: 
 
1. 'Edit/add custom fields' 
2. 'Commit' 
 
apache error-message contains: 
 
malformed header from script. Bad header=</pre>: 
/srv/www/htdocs/tasktrack/editcustomfields.cgi 
 
editcustomfields.cgi: Insecure dependency in parameter 1 of 
DBI::db=HASH(0x884b584)->prepare method call while running with -T switch at 
Bugzilla/DB.pm line 64. 
 
 
 

Comment 195

[Thomas Schmidt]

additional info to my comment #194:

the error occurs only when editing an existing customfield.

Comment 196

[Ludovic Dubost]

I've just tried what you say on a test installation and cannot reproduce it..
This is probably linked to 'tainted' mode and I'm not very competent at fixing
these because I don't really understand what this is about.. One of the big
changes I made is moving from using the 'product' variable to use the
'product_id' variable in queries.. Maybe there might be a tainted mode call for
this variable that is needed in some cases..

I think it would help if you had the exact line of the failure in
editcustomfields.cgi..

Ludovic

Comment 197

[Thomas Schmidt]

reply on comment #196: 
 
the following fix of editcustomfields.cgi works for me: 
 
169c169 
<     SendSQL("UPDATE customfields SET type='$type', valid_exp='$valid_exp', 
mandatory=" . ($mandatory ne ''? '1':'0') . ", default_value= '$default_value' 
--- 
>     SendSQL("UPDATE customfields SET type='$type', valid_exp=" . 
SqlQuote($valid_exp) . ", mandatory=" . ($mandatory ne ''? '1':'0') . ", default_value= 
'$default_value' 
 

Comment 198

[Billy L. Williams, Jr.]

Looks like the patch against 2.17 HEAD (possibly other patches, haven't checked
them) causes the query sort ordering to fail due to the following change on line
672 of buglist.cgi:

original line:

$query .= " ORDER BY $db_order " if ($order);

new line:

$query . " ORDER BY $db_order " if ($order);

Looks like a typo, and if you revert the line back, the original column sorting
works as it should.  Since this is such a trivial fix I'll let somebody else
more involved fix the patch if this is the correct thing to do.

Comment 199

[Ludovic Dubost]

Attachment: Patch agains 2.17 Head from Sept 27th 2003

Here is a new version of the patch that should fix most of the problems
reported and a bunch of other problems.. It is now possible to use fields of
type 'multi' and custom fields can be associated to All products and
components..

Comment 200

[Brendan Leber]

First, thanks for the great work.  This patch is gonna save me so much 
time.  ;)  Being new to the project I'm not sure if this is the proper place 
to ask questions, but I see many posted in the comments to I'll add mine.  If 
there's a better place, shoot me an email and I'll ask my questions there.

I've applied the patch without problems.  I can manually enter 
http://beabugs1/devzilla/editcustomfields.cgi and enter my own custom fields.  
The problem is I don't see the link to "custom fields" in the useful links 
part of the footer.  I checked the template source and there is the code to 
add the link.  Next, I checked the parameters and verified that data/params 
contained 'usecustomfields' => '1'.  Finally I checked my user permissions to 
make sure I had tweakparams turned on, which I do and I see the "Sanity Check" 
and "parameters" links.

Where else should I look to see why I'm not getting the "custom fields" links?

Comment 201

[Thomas Schmidt]

cannot sort a buglist by clicking on a customfield header:
1. show a buglist (query.cgi/buglist.cgi?...)
2. add a customfield to the listed columns (colchange.cgi)
3. click on customfield header to sort buglist

leads to an internal error page:
Invalid Column Name
The custom sort order specified in your form submission contains an invalid 
column name bcf1.value.

see buglist.cgi line 582


Another Problem: colchange.cgi seems to fail on including customfields with a 
multiword-name (e.g. 'Test Equipment')

Comment 202

[Ray Trent]

Is there a meta-bug that tracks all of these custom field issues? There are so
many different issues reported in this bug that it seems hard to keep track of
them all...

Comment 203

[Ludovic Dubost]

I don't think there is another bug.. Currently in the latest patch I submitted
for the 2.17 Head code, the problems in comment 194, comment 197, comment 198
are fixed.. comment 200 was a local issue (the template was copied in the custom
area so the patch did not modify it)..

I'm looking at the problems explained in comment 201

Comment 204

[Ludovic Dubost]

Attachment: Patch Against 2.17 Head of Oct 1st

Problems reported in comment 201 are now fixed.. Some of the fixes are a little
bit of a hack in the way the ordering is handled for custom fields and in the
way custom fields with white spaces are treated.. 

I've made some modifications to show the 'description' in the column headers
and the create and edit template instead of the field name..

With this modification it would probably be better to not allow custom fields
with white spaces.. this can only be a debugging nightmare..

Comment 205

[Ludovic Dubost]

Attachment: Picker for Custom Fields and Custom Fields by type of entry

This is an additional patch which has multiple features:

Custom Fields Picker:
Needs patch from Bug 102852. This allows to create custom fields of type 'user'
and of type 'date' (the 'date' type behaves like the 'any' type).. The fields
of type 'user' will have a picker allowing to search for valid email addresses
from the database (it also supports LDAP).. 
Also you can create a homemade picker (write the javascript to call pickValue
in the 'picker' entry field). 
Example: for the customer custom field
pickValue(this.form.customer, 'value', 'value', null, true, 'db',
'bugs_customfields', true, 'cf_id=27')
would allow to search for existing customer in the database...

Custom Fields by entry type:
Patch from Bug 221017 allows to create different of entry types (Bug, Task,
Tracker, Project, etc..).. This patch allows to restrict the usage of each
custom field for specific entry types.. For exemple if the 'customer' custom
field has 'Tracker|Project' in the allowedtypes field then it will only appear
in the entries of type Tracker or Project.

Comment 206

[Thomas Schmidt]

No notification email is generated, when a customfield changes. Also the initial
notification email (when submitting a new ticket) does not contain information
about the customfields.

Comment 207

[Ludovic Dubost]

I won't have time to make these modifications.. If somebody wants to help out it
would be great..

Comment 208

[Brendan Leber]

Attachment: Add "(Optional)" to the creation page for custom fields that are not mandatory.

A slight change to template/en/customfields/create.html.tmpl that will add the
string "(Optional)" after custom fields that are not mandatory.

Comment 209

[Thomas Schmidt]

Help!
I'm highly dependent on notification emails, if a customfield changes (see 
comments #206 and #207), but I'm not familiar enough with bugzilla to make the 
necessary modifications.

Comment 210

[Stuart Marshall]

Has anyone updated their 2.16.3-with-customfields to 2.16.4 using CVS yet? 
It should work OK but there were a few problems last time when going from 2.16.2
to 2.16.3.

Comment 211

[Stuart Marshall]

Upgraded via CVS and all went fine.

Comment 212

[Joe Tom]

Could somebody please let me know what are the patches that I need to apply
to get the custom-field functionality working. I have done a fresh install
of 2.16.4 last week on a linux box. Any help or pointers will be great.
Thanks

-joseph

Comment 213

[Ludovic Dubost]

Attachment: Patch against 2.17.6

New version of the patch with minor fixes working on 2.17.6

Comment 214

[Joe Tom]

I installed 2.17.6 (Nov 2 2003 release) and applied the patch(135401) suggested
in comment 213. On accessing editcustom...cgi script, I get this Software error.
(I don't see product_id column in products_customfields table)

------------------Browser Window Message------
DBD::mysql::st execute failed: Unknown column 'product_id' in 'where clause'
[for Statement "select customfields.name, products.name from customfields,
products_customfields, products 
		where customfields.id=cf_id and (product_id = products.id or product_id=0)
order by customfields.id"] at Bugzilla/DB.pm line 66
	Bugzilla::DB::SendSQL('select customfields.name, products.name from
customfields, pr...') called at globals.pl line 188
	main::GenerateVersionTable() called at globals.pl line 392
	main::GetVersionTable() called at 
..... editcustomfields.cgi line 26

Comment 215

[Ludovic Dubost]

I think your database is desynchronized between the products and the
products_customfields table:

If the table products_customfields does not exist it will be create will field
'product_id'..
If the table products_customfields already exists with field product_id nothing
needs to be done..
If the table products_customfields exists with field product then it is upgraded
only of the field product is found in the products table (sign of a 2.16 version)

So you must have a products table that is already upgraded to the product_id
field and a products_customfields that is not..

Either:

- you start from a clean DB 
or
- you run this script:
ALTER TABLE products_customfields ADD COLUMN product_id smallint not null;
UPDATE products_customfields SET product_id = XXX WHERE product 'YYY';
... repeat for each existing custom field ..
ALTER TABLE products_customfields DROP COLUMN product;

Comment 216

[Dan Fleischer]

I have 2.16.3 installed and desperately need to add Custom Fields.  How do I 
do it? 

There are so many patches, and patches for patches in this bug that I have no 
clue what to.  Even IF I did know what patches to install I can't find any 
information about how to apply them in the documentation.  I'm new to 
Bugzilla, MySQL & Linux (a triple threat, lol) and need detailed instructions 
on how/where to install the patches to get this functionality.  I found out, 
the hard way, during the installation that many times the documentation 
just "assumes" you'll do something without telling you to actually do it.  As 
a "newbie" I need detailed step-by-step instructions.  I've seen other people 
ask for this (Comments 188 & 189) in the bug but I don't actually see the 
instructions.  Can someone help point me in the right direction, please?

Comment 217

[Gervase Markham [:gerv]]

> There are so many patches, and patches for patches in this bug that I have no 
> clue what to.  Even IF I did know what patches to install I can't find any 
> information about how to apply them in the documentation.  

They aren't mentioned in the documentation because they aren't officially
supported (otherwise they'd be in Bugzilla itself.) 

> I found out, 
> the hard way, during the installation that many times the documentation 
> just "assumes" you'll do something without telling you to actually do it.

You also made this accusation about our documentation in the newsgroup. At the
time, I asked you to name, or to file bugs on, the bits you thought were
unclear. A search of Bugzilla reveals no such bugs. Perhaps while you are
waiting for someone to explain which is the right patch (I certainly don't know)
you might find time to file them? :-)

Gerv

Comment 218

[Dan Fleischer]

I added a bug which has been accepted about a minor issue I ran into during 
the install and the other bugs I wanted to add where all duplicates.  Another 
issue I brought up on the message board was also entered as a bug a week or 2 
ago based on my post.

Comment 219

[Gervase Markham [:gerv]]

> I added a bug which has been accepted about a minor issue I ran into during 
> the install and the other bugs I wanted to add where all duplicates.  

Indeed you did; I don't know why my first search didn't find it. Apologies.

If you would list the duplicates of the bugs you wanted to file (perhaps in an
email to me) I'll see if some of them can be fixed.

Gerv

Comment 220

[Thomas Schmidt]

Attachment: include customfields into change-notifaction-emails

see comment #206.
Ludovic, please verify the changes!

Comment 221

[Joe Tom]

Relating custom fields with Product level fields.

I am looking for a functionality/relationship similar to what happens when
you select a product (in the query interface) and the relevant 
components, versions, and milestones for that product is 
filtered/displayed by the UI (selectProduct javascript function).

Does anybody know of a patch/pointer/ that will allow me to establish
this relationship between 'Version' and user defined custom field, 
say, 'revisionCF' on enter bug interface? Something like the following:
I want to tie Version 3.1 for my product with revisionCF 3.1.1, 3.1.2, 3.1.3
or for Version 3.2 with 3.2.1, 3.2.2, etc.

product --> Version --> RevisionCF

I was wondering if you could please suggest the way to go about it or point
me to relevant information.

Comment 222

[Hamid Tehrani]

Background:
Upgrade from 2.17.4 (no CF patch) to 2.17.6
Applied CF patch for 2.17.6
Applied change-notification-email patch 

Now when I create a bug, edit.html.tmpl doesn't show the custom fields but 
when I click on Back To Bug # link or access the bug using its ID, custom 
fields show up. 

Some how this portion of the code is not executed (in edit.html.tmpl) when a 
bug is created for the first time:

 [% FOREACH c = customfield %]
  [% IF c.done != 1 %]
   [% PROCESS cfedit %]
   [% c.done = 1 %]
  [% END %]
 [% END %]

Is this a bug? Any idea how this can be fixed?

Any help is greatly appreciated.

Comment 223

[maverick]

------- Additional Comment #222 From Hamid Tehrani 2004-01-09 15:32 ------- 
I have encounted this problem too.
As debug the post_bug.cgi, I found that when $vars contains no {'customfield'} 
when transferred to $template->process("bug/create/created.html.tmpl", $vars), 
so didn't show custom fields after post bug.
To fix this bug, add this line in post_bug.cgi:
$vars->{'customfield'}=$bug->{'customfield'};

Comment 224

[Brendan Leber]

We're having a problem with custom fields at our installation.  We're running
v2.17.6 with the CF patch.  When people go through a list and move bugs from NEW
to ASSIGNED the contents of all the custom fields is lost.  The settings and
values for the custom fields doesn't seem to matter.

I've been unsuccessfully hunting this problem for a while now.  Has anyone else
encountered this problem?  Do you have any suggestions of where I might look?

Comment 225

[Alexander Brinkman]

In answer to 224: I probably noticed the same.

process_bug.cgi also needs the $vars->{'customfield'}=$bug->{'customfield'};
line (as described in comment 223).

Search for:
        # next.html.tmpl includes edit.html.tmpl, and therefore we
        # need $bug defined in $vars.
        $vars->{'bug'} = $bug;

and put $vars->{'customfield'}=$bug->{'customfield'}; below that (sorry for not
making a patch).

Comment 226

[Hamid Tehrani]

Do you have any problems with slow queries for creation_ts? When I specify 
dates for 'Only bugs changed between' and select [Bug Creation] it takes a 
long time to get any results (most of the cases it times out). Anybody else is 
experiencing this problem? I am using 2.17.6.

Comment 227

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #226)
> Do you have any problems with slow queries for creation_ts?

That's probably bug 232150.  Try its fix and reopen if you still see slowness.

Comment 228

[Dave Miller [:justdave]]

I'm still here, just fixing the owner to more accurately indicate that I haven't
actually been helping with this yet.  I think Sean's been the one mostly working
on this, but I'll let him take it if he wants rather than me forcing it on him.

Comment 229

[Mark Davis]

Config: linux 2.17.6 with patches 135401 and 136712.

Getting a software error when using customfields in change_columns (colchange.cgi).

This only occurs when I have selected one of my customfields to show in a list
(buglist.cgi). I can reliably reproduce this.

 
DBD::mysql::st execute failed: Unknown table 'map_assigned_to' in order clause
[for Statement "SELECT bugs.bug_id, bugs.bug_severity, bugs.priority,
bugs.bug_status, bugs.resolution, bugs.bug_severity, bugs.rep_platform,
map_reporter.login_name, bugs.bug_status, bugs.resolution, bugs.short_desc,
bcf1.value as bug_impact FROM bugs, profiles AS map_reporter LEFT JOIN
customfields cf1 ON cf1.name='bug_impact' LEFT JOIN bugs_customfields bcf1 ON
bugs.bug_id = bcf1.bug_id and bcf1.cf_id=cf1.id, keywords keywords_ LEFT JOIN
bug_group_map  ON bug_group_map.bug_id = bugs.bug_id  AND bug_group_map.group_id
NOT IN (6,7,3,8,2,1,5,4)  LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who =
55 WHERE bugs.reporter = map_reporter.userid AND keywords_.bug_id = bugs.bug_id
AND (((lower(bugs.keywords) regexp '(^|[^a-z0-9])review($|[^a-z0-9])') AND
(keywords_.keywordid = 6))) AND ((bug_group_map.group_id IS NULL)    OR
(bugs.reporter_accessible = 1 AND bugs.reporter = 55)     OR
(bugs.cclist_accessible = 1 AND cc.who IS NOT NULL)     OR (bugs.assigned_to =
55) OR (bugs.qa_contact = 55) ) GROUP BY bugs.bug_id ORDER BY
map_assigned_to.login_name,bugs.priority "] at Bugzilla/DB.pm line 66
	Bugzilla::DB::SendSQL('SELECT bugs.bug_id, bugs.bug_severity, bugs.priority,
bugs.bug_s...') called at /usr/local/bugzilla-2.17.6/buglist.cgi line 744

any ideas?

Comment 230

[Mat]

Hi folks,

Im just a newbie trying to come up to speed on this code....
I have applied Patch 135401 against 2.17.6 and it went on ok. From paramenters I
can now select UseCustomFields. But where do I add in the custom fields? There
seems to be patchs on patchs on patchs for the EditCustomFields.cgi and I for
one am confused.
If anyone has 2 mins, can they write a quick paragraph explaining to all us
newbies out there how to setup the custom fields ?

Cheers in advance,
Mat

Comment 231

[Mat]

OK...Mats mini guide to getting this installed (complete newbie!)
Sorry for the spam folks...but throught other newbies might find it useful

1. Install http://bugzilla.mozilla.org/attachment.cgi?id=135401&action=view
Do this from the bugzilla root using "patch -p1 < 91037_217H_customfields_v2.patch"

This patch installs all of the CGI code AND all the template code. From what I
can understand this is all you need to do for basic custom fields.

2. Run "perl checksetup.pl" again

3. Now you can add custom fields by
www.yourbugsinstallation.com/editcustomfields.cgi
There is also www.yourbugsinstall.com/editposition.cgi

How you use them after this....Im still learning.

Comment 232

[Mike Brown]

(In reply to comment #213)
> Created an attachment (id=135401)
> Patch against 2.17.6
> New version of the patch with minor fixes working on 2.17.6

I have successfully installed this patch on 2.17.6 in a Win32 environment.  
Things work wonderfully.  I have a small cosmetic problem though.  When I enter 
a bug(http://mybugzilla/enter_bug.cgi) or view a bug 
(http://mybugzilla/show_bug.cgi?id=1) I get strange characters () on the 
html page.  Any ideas as to why these characters are showing up?  They don't 
show up on the long list page however.  Any help would be appreciated.  We have 
some very anal folks on staff who have to use this and they are whining and 
unfortunately they pay me.

Comment 233

[Sean McAfee]

Attachment: A new implementation of custom fields

This is a new custom fields implementation.  Apply the patch to a 2.17.4
installation, then see the file README-CustomFields for instructions.

Comment 234

[Sean McAfee]

Attachment: A new implementation of custom fields

This is a new custom fields implementation.  Apply the patch to a 2.17.4
installation, then see the file README-CustomFields for instructions.

D'oh!  Sorry about the earlier attachment; I didn't realize patches shouldn't
be zipped.

Comment 235

[Svet]

I installed 2.17.6, applied Custom Fields patches(135401 and 136712), entered 2 
ne
w custom fields, added above mentioned code lines in the files process_bug.cgi 
and
 post_bug.cgi and I still cannot see the custom fields when I try to add a new 
bug
. They appear thou in the "Advanced Querying Using Boolean Charts:" drop-down 
boxe
s when I do Search.

Can anyone explain what the purpose of the editposition.cgi file? any more 
documen
tation on what is the correct syntax of creating new custom field.
I tried to add a new drop-down box and I assumed that the listed items in it I 
sho
uld place in the "Valid Expression" box in the editcustomfields.cgi page.

Any help will be greatly appreciated!

Thanks

Svet

Comment 236

[Svet]

I installed 2.17.6, applied Custom Fields patches(135401 and 136712), entered 2 
new custom fields, added above mentioned code lines in the files 
process_bug.cgi and post_bug.cgi and I still cannot see the custom fields when 
I try to add a new bug. They appear thou in the "Advanced Querying Using 
Boolean Charts:" drop-down boxes when I do Search.

Can anyone explain what the purpose of the editposition.cgi file? any more 
documentation on what is the correct syntax of creating new custom field.
I tried to add a new drop-down box and I assumed that the listed items in it I 
should place in the "Valid Expression" box in the editcustomfields.cgi page.

Any help will be greatly appreciated!

Thanks

Svet

Comment 237

[Joel Peshkin]

I took a look at attachment 141368 [details] [diff] [review] and have a few observations...

First, it generally diverges from some of the traditional Bugzilla conventions
that are a must if it is to land.  Most notably, it uses boilerplate SQL to
update the schema rather than using checksetup.pl to ensure a smooth migration
both initially and in the future.  

It also appears to implemet a number of common functions of its own that should
probably be merged with Bugzilla's common functions.

The existing code seems to attemot to lay out the fields as a programming
decision.  I think this is fine as an initial cut, but it probably wants to be
enhance in a subsequent (distinct) bug to permit a template author to "claim" a
customfield and keep the automatic code from handling that field so the template
can do it in a locally desirable manner.  

If a bug is edited and a customfield is not provided to process_bug, does it
leave the customfield untouched?

I suspect that getting this landed will require quite a drive just because of
the size of the patch.  Before suggesting that Sean do anything about matching
the rest of the Bugzilla conventions, I suggest that a design be posted here and
debated to consensus.

Having done a monster patch myself, I think it is worth reminding everyone that
this will take a few months concerted effort by the author and a few primary
reviewers.  Are we ready?  I'm in as a reviewer.

Comment 238

[Vlad Dascalu]

Count me in too.

Comment 239

[Max Kanat-Alexander]

Okay, as the beginning of a specification, I've looked over all the comments
here, and here is a brief summary based on the information comtained in this bug:

Obviously custom fields is a large patch, and it requires incremental
implementation. So, here is an in-order description of custom fields, from the
bare basic functionality to full-blown power. This is not in order of priority,
but instead in what seems like the easiest order to implement all functionality in.

(1) The basic functionality of custom fields is:
  enter_bug.cgi: The ability to enter data into a custom text field
  show_bug.cgi: The ability to see the data from entered custom text fields.

(2) An shell-based admin tool to manage custom fields.

(3) In order for this to become useful for most users:
  query.cgi: The ability to search custom fields

(4) Ability to track custom fields in the bug activity.

(5) Custom fields of different types, such as Select or Radio.

(6) Control of Custom fields through templates.

(7) Ability to do mass-changes of custom fields.

Future
------

Down the road, some users would like:
  + enter_bug.cgi: Ability to make certain fields mandatory.
  + enter_bug.cgi: Don't break bookmarkable templates
  + show_bug.cgi: Ability to control where custom fields appear
  + long_list.cgi: Ability to see custom fields in long_list.
  + buglist.cgi: The ability to see custom fields in the bug list.
  + query.cgi: Ability to search custom fields in "Bug Changes"
  + admin: GUI to add and maintain custom fields.
  + admin: Ability to restrict fields to products.
  + admin: Ability to delete custom fields from the system
  + Data validation by regular expression
  + Descriptions for custom fields somewhere in the UI
  + Ability to style custom fields with CSS, and ability to have custom name
attributes for custom fields.
  + Contrib and non-web tools should understand custom fields.
  + Date-type fields (note comment 145)
  + Multi-select fields
  + Group-based security controls for custom fields
  + Ability to tie custom fields to current fields (comment 221)

Essential Requirements as this is happening
-------------------------------------------
  + No MySQL-specific code
  + Maintainable schema changes (checksetup.pl)
  + A Bugzilla without any custom fields does not get noticeably slower.
  + Custom fields work in taint mode
  + All current Bugzilla functionality must continue to work properly.
  + Don't cause any more cross-platform bugs (for Win32)

Desired Requirements
--------------------
  + Speed of searching custom fields is good.
  + A Bugzilla *with* custom fields does not get noticeably slower.
  + No premature optimization

Important Comments from Bugzilla Maintainers
--------------------------------------------
comment 18 -- Template Interactions
comment 32 -- Certain Requirements
comment 97 -- Types of Fields, Schema
comment 165 -- Note about discussion on developers list
comment 170 -- Admin GUI
comment 171 -- DB Structure (also see following comments)
comment 237 -- General comments on Sean's new Custom Fields patch

Where to Go From Here
---------------------

  My proposal is this: Break (1) - (7) above into separate bugs, and make them
block this bug.

  Sean, can you break your patch down into a patch that does *only* (1), above,
and file it as a bug blocking this one? Then we can review that, get it in
2.19.1, and move on from there.

Comment 240

[Dave Miller [:justdave]]

This isn't going to make it into 2.18...

Comment 241

[John Christian]

Hi,
This issue refers to the 'Patch against 2.17.6' patch ...
I've noticed an issue with displaying customfield values as columns in buglist.cgi ... when displaying 
both of the two customfields I'm using, their values are swapped!  However, the correct value is there 
when displaying only one customfield column.
Is there a workaround, or is this resolved by a newer patch (i.e., the 'new implementaton')?

Comment 242

[usmle]

Do we have a customfields pathc against 2.16.5

Comment 243

[Stuart Marshall]

the existing patches work on 2.16.5. i'm not sure which ones you need to apply
though as i applied them on 2.16.1 and have just been updating via cvs since.
the only problems i had was from 2.16.2 -> 2.16.3 (see comment 183). 

Comment 244

[Henrik Wallentin]

I've installed the "A new implementation of custom fields" into 2.17.4.
-I ran the custom-fields-schema.txt and it worked fine.
-I ran the create-fields.pl and it worked fine.
-I tried to run the checksetup.pl and got the following:
Creating table group_control_map ...
[Thu Jul 15 18:04:57 2004] checksetup.pl: DBD::mysql::db do failed: 
Table 'group_control_map' already exists at checksetup.pl line 1808.

-When I now try to access the bugzilla I get the following:
Undefined subroutine &Bugzilla::CustomFields::Common::prepare_sql called at 
Bugzilla/CustomFields/Common.pm line 76.

I've had a look at the file and the prepare_sql routine isn't available, is 
that some sort of a standard file?

I'm going crazy here, since I really would like the "custom fields"...

Thanks for any help!

Comment 245

[Dave Miller [:justdave]]

(In reply to comment #244)
> I've installed the "A new implementation of custom fields" into 2.17.4.

> [Thu Jul 15 18:04:57 2004] checksetup.pl: DBD::mysql::db do failed: 
> Table 'group_control_map' already exists at checksetup.pl line 1808.

That's probably bug 212095 (which was fixed in 2.17.5)

Comment 246

[Henrik Wallentin]

(In reply to comment #245)
> (In reply to comment #244)
> > I've installed the "A new implementation of custom fields" into 2.17.4.
> > [Thu Jul 15 18:04:57 2004] checksetup.pl: DBD::mysql::db do failed: 
> > Table 'group_control_map' already exists at checksetup.pl line 1808.
> That's probably bug 212095 (which was fixed in 2.17.5)

Thanks! That fixed the first issue, the issue:
Undefined subroutine &Bugzilla::CustomFields::Common::prepare_sql called at 
Bugzilla/CustomFields/Common.pm line 76.

Still remains though, anyone got any ideas?

Comment 247

[Sean McAfee]

(In reply to comment #246)

> Thanks! That fixed the first issue, the issue:
> Undefined subroutine &Bugzilla::CustomFields::Common::prepare_sql called at 
> Bugzilla/CustomFields/Common.pm line 76.
> 
> Still remains though, anyone got any ideas?

Yes.  Replace this line:

my $sth = prepare_sql($sql, @param);

...with these lines:

my $sth = Bugzilla->dbh->prepare($sql);
$sth->execute(@param);

Unfortunately, I didn't detect this error before shipping off the patch.  It's a
bit depressing that it took so long for someone to notice.  Maybe folks have
been fixing it themselves?  I dunno.

Oh, and you can delete that line "my @row;" just prior, while you're at it. 
Dang, how did that get left in there?  It's even in my current sandbox code.

Comment 248

[Ray Trent]

Some comments on comment 239:

I don't want to rehash my (extremely long and pedantic :-) comment 166, but I
think it would be wise to keep in mind the small number of valid reasons for
adding custom fields when deciding on implementation priorities. In particular,
I think there is no point in implementing a custom fields feature that doesn't have:

  + The ability to see custom fields in the bug list, mostly to facilitate
sorting the buglist on custom fields, preferably 2 levels deep.
  + Data validation by regular expression
  + Date-type fields (though this could be a subset of data validation)
  + Single/Multi-select fields (facilitates search/sort)
  + Some mechanism to facilitate report generation based on custom fields 
(inclusion in the RDF formatted output, for example)

So I'd personally put those in as initial steps rather than some kind of
nebulous "for the future" category.

And maybe:
  + Group-based security controls for custom fields

The whole point of custom fields is to satisfy the need to validate/restrict,
search, sort, report on, or otherwise specially process, well-defined chunks of
information pertaining to a bug which are unique to a particular installation.
Using them for anything else is just inefficiency and poor usability, usually
due to bureaucracy. 

Comment 249

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Ray's right, all those things should be in the final incarnation of custom
fields and the chosen schema should not preclude easy addition of those features.

However, landing a giant patch in something like Bugzilla is much harder than
landing several smaller patches.  Bugzilla is a fast-moving target, so code rot
is a real problem to contend with and the drivers have plenty of cats to herd.

The Bugzilla bug lifecycle even exacerbates this problem to a certain extent,
since the bug can't be marked fixed until the patch lands and all relevant
patches need to land before it can be marked fixed.  i.e. you can't land several
smaller patches as each is done on a single bug. 

As such, if the schema is acceptable, this bug ought to be resolved when the
core functionality is ready and several bugs with properly marked dependencies
should be filed to handle the additional functionality.  Since today we can wish
this bug "Happy 3rd Birthday!" it's important to consider the benefits of
getting a good foundation in so we can actually get the house built.

Comment 250

[Stuart Donaldson]

Ray has good points in comment 248 regarding comment 239. However I agree with
Bill in comment 249 about needing to break this down into smaller pieces.  Max
stepped forward in comment 239 to try and identify a list of requirements, and
to break it up into phases of an implementation.

If we are ever going to get custom fields in, we have to start somewhere.  And
the most important part I believe is getting a start on the schema.  It would be
a big step forward just having a schema identified and in which would be
supported, even if there was no UI to go with it.

In the hopes that this bug doesn't live on another 3 years, I would prefer to
follow the plan outlined in commen 239 just as a start.  Can the latest approach
on custom fields be broken down as suggested there?

Comment 251

[Ray Trent]

I certainly have no argument with the notion that this monster needs to be
broken down into smaller steps. 

I was merely trying to state an opinion that the elements I mentioned really,
really don't belong in a category labelled "Future: Down the road, some users
would like", but rather that they should be steps 8-12 (and maybe 13). 

Actually, I think they should go before steps 6 and 7, but maybe that's just me. 

Comment 252

[Fawad Khan]

I have applied Custom Fields patch to my 2.14.5 Bugzilla installation.
But, when I go to editcustomfields.cgi page none of the hyperlinks are enabled. 
I can't Add new fields or Edit the existing ones. Can anyone tell what am I 
missing here?

Thanks,
Fawad 

Comment 253

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 254

[Jeffrey Bacon]

I realize that this is a huge enhancment, but I think it's something that a lot
of people would use.  I certainly would customize a lot of the fields and I know
other bugzilla users who would love to be able to make some company-specific or
industry specific fields.

Comment 255

[Dave Clendenan]

Set blocking 2.20 to '?' to match with the documented plan at
http://www.bugzilla.org/status/roadmap.html#milestones

I certainly _hope_ this will make 2.20, since there are several planned changes
to our bugzilla that are waiting on this...

I can help with some testing if it's needed, but I'm a bit unsure which of the
mountain of patches is best...

Comment 256

[Dave Miller [:justdave]]

(In reply to comment #255)

> I certainly _hope_ this will make 2.20, since there are several planned changes
> to our bugzilla that are waiting on this...

It won't.  The feature set for 2.20 is already frozen, and this counts as a
feature change.

Comment 257

[agrieco]

Has anyone seen a patch for 2.18rcN out there where N=[1,2,3]?

Comment 258

[Michael Michon]

(In reply to comment #257)
> Has anyone seen a patch for 2.18rcN out there where N=[1,2,3]?

or, for 2.18 (proper), since it's been recently released?  it's sort of
ridiculous that this feature is still not in the package.

Comment 259

[Sean McAfee]

Attachment: Bare-bones, read-only custom field implementation

This attachment is a zipped tar file that contains a very minimal custom fields
implementation for Bugzilla 2.18.3.  No changes are made to the Bugzilla
interface or to existing Bugzilla files or database entities.  Custom field
data introduced by this patch can only be examined programatically or from a
database client.

A much fuller custom fields implementation is in use at my company; the purpose
of this minimal version is to garner some support for the basic schema and
implementation before going forward with the rest.

These files are enclosed:

simplified-schema.sql
duplicate-data.sql
Bugzilla/CustomFields.pm
Bugzilla/Query.pm

To create the schema, feed simplified-schema.sql to the mysql client.

duplicate-data.sql is a SQL script that creates twenty custom fields which are
duplicates of standard bug attributes.	It also copies the data from those
standard attributes into the new custom fields.  The fields have the same names
as the columns of the BUGS table, but with "cf_" prepended.  (For example,
"op_sys" becomes "cf_op_sys".)

Bugzilla::CustomFields is a module that provides an interface to custom fields.
 It's strictly read-only; I've removed all the code from my production version
except that which implements the basic get_custom_fields() function.

Bugzilla::Query is a module for searching for bugs.

Both modules are thoroughly documented with POD.  Use "perldoc" or your
favorite editor to read it.

If you have an interest in custom fields, kindly take some time to evaluate
these files and let me know your thoughts.  Thanks.

Comment 260

[Max Kanat-Alexander]

Comment on attachment 171799 [details]
Bare-bones, read-only custom field implementation

OK, I've looked over this REALLY quickly. I like the schema, and I like
CustomFields.pm.

Are you aware that Query.pm entirely replaces Search.pm, from what I can see?
And Search.pm is probably the most complex code in Bugzilla?

Now, all in all, I prefer the interface of your Query.pm to our current
Search.pm. However, the change to using it would be so massive that it would
never be checked-in. Almost every single Bugzilla developer would have to give
it a review+ and do more extensive testing than we have QA power to do. It
would be the longest development cycle in the history of mankind to work out
any performance problems and bugs that we encountered.

That's hard for me to say, since I'd prefer that our Search.pm worked like your
Query.pm does. I think that the reality is, though, that if we depend on its
existence, this custom fields method won't get checked-in.

However, I'd be willing to do the review on any other code that you might have,
if you're willing to work with Search.pm as it is. And if a LOT of other
Bugzilla developers are willing to go with it, I'd love to try to get your
Query.pm checked-in, but it would have to be an entirely separate bug from this
one.

Comment 261

[Myk Melez [:myk] [@mykmelez]]

Attachment: FAC-based alternative implementation v1

Here's a basic alternative implementation that uses a FAC database schema (see
discussion on the developer's mailing list about FAC vs. FAD database schemas).
 It comes with a simple command-line script for adding a custom field, lets you
search custom fields via the boolean chart, displays them on bug pages, lets
you edit them, commits your changes, and includes them in XML bug output.

Besides the choice of schema, the other advantages of this implementation are
that it reuses existing code for searching, updating, and storing meta-data
about fields; it makes only minor and largely discrete modifications to
Bugzilla code; and it decouples Bugzilla field types from MySQL column types so
that we can define a much richer set of types (f.e. a "user" type which
auto-generates special user-picking UI) than those available to us as database
columns.

Current core limitations are that it supports only text fields (the
implementation supports multiple types, but I haven't added any additional ones
yet); and it does not yet provide the option of storing data in separate tables
(this requires some more Search.pm and process_bug.cgi hacking).

Comment 262

[Marc Schumann [:Wurblzap]]

Your patch on bug 280770 got into this somehow :)

Comment 263

[Joel Peshkin]

I like the approach in myk's patch, particularly in the way it uses fielddefs
and causes the standard ways of accessing fields to "just work" with
customfields.  I haven't checked for completeness yet, but that really feels
like the right path.

Comment 264

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #262)
> Your patch on bug 280770 got into this somehow :)

Yes, it's a prerequisite for this patch (the template uses the field type
constants to determine each custom fields' type).  I'll remove it from the next
version of this patch if bug 280770 gets resolved by then.

Comment 265

[Tom Maddox]

I tried applying <a
href=https://bugzilla.mozilla.org/attachment.cgi?id=135401>the most recent jumbo
patch</a> against 2.18, which obviously did not go exactly smoothly.  After some
hacking, I got everything to work well enough, execpt that I can't seem to
figure out how to populate custom fields of type "multi."  Either I'm missing
something really obvious, or I screwed up during the patching process.  Does
anyone have any pointers with regard to what I should expect to see when
creating a "multi" field or how to get this functionality to work with 2.18?

Comment 266

[Stuart Marshall]

You need to put possible values for the multi field in the "Value regexp" field,
seperated by '|'s. 

e.g. 'one|two|three|four'.

And then when you are editing a bug, they should appear in a listbox which
allows you select any of the values. 

Comment 267

[Tom Maddox]

I've got another strange problem with my custom fields implementation:  now,
whenever a bug is displayed, the custom fields are displayed three times on the
bug form.  This problem does not occur while the bug is being created (i.e.,
only show_bug.cgi appears to be producing the bogus output).  Also, if the
custom fields are updated following the bug's creation, the duplicate field
instances go away.  Where might I start looking into this problem?

Comment 268

[John Clutterbuck]

Attachment: patch for 2.18

I am not a regular Bugzilla developer but thought I would share this patch
which is a result of installing the patch: 'Patch against 2.17.6 of 2003-11-13
07:45 PST' against 2.18 (with alias fixes from bug #165022 and bug #248386). 

The patch involved some hacking to resolve. I have also fixed several issues
with custom fields on the templates and have also extended the search to
include the custom fields which seems to work OK.

Comment 269

[John Clutterbuck]

Attachment: Search fix for 2.18 patch

A small patch to be applied after the main 2.18 patch which adds a hidden field
of the match type to fix a search problem with 'multi' custom fields.

Comment 270

[nagendra]

I started looking at adding my own custom fields and then later came upon this
bug ID.  So I have some thoughts on how I think some aspects of custom fields
should be implemented .  I'll list them here as food for thought.

1.  Custom fields values should not come from a "|" delimited list as the fields
may come from a second DB system.  i.e. the list of customers can be in the
thousands and you may want the customer list populated dynamically multiple
times per day based on some script.  Also, coming from a table, the list can be
sorted by MySQL as it is fetched from the table by some sorting criteria.

2.  Custom field values should not be referred to by ID, but rather should be
stored as value because the list of custom values might change over time, and
you may still want to keep the historical value.  EX: we used to have customer
X, and customer X no longer exists.

3. We already have a type of custom fields implementation in bugzilla: Flags. 
The only difference is that flags have only 4 values: +, -, , ?.     Should we
not consider flags to be a type of custom fields and extend that implementation?

Comment 271

[Joel Peshkin]

*** Bug 285805 has been marked as a duplicate of this bug. ***

Comment 272

[John Clutterbuck]

Notwithstanding comment 270 which has some merits I am pursuing getting custom
fields working against 2.18. There are some tweaks required to the search and
edit templates for single and multi types which I will try and submit a patch for.

I have noticed two outstanding issues as follows:

If the contents of custom field are changed then sanity check finds an invalid
value in bugs.activity. This should be tweaked to recognise or ignore custom fields.

I have also noted that the custom fields are inserted into table fielddefs but
with custom = 0, which I wonder should be set to 1.

Comment 273

[nagendra]

Before a decision is made on the custom fields direction, I'd like to list a few
more thoughts on my comparison of Bugzilla and a few other work flow management
tools out there as would be nice to have implemented within Bugzilla.

1. custom field types: (checkbox, pulldown, multi-value, graphic type,
calculated type, date type, URL type)
2. Access privileges:  (view, edit, search)
3. As for the values allowed, they should also be customizable with privilages.

Comment 274

[Aaron Williams]

Ideally the custom fields should also be able to be customizable based on
product and optionally component.

Comment 275

[John Clutterbuck]

Attachment: Updated full custom fields patch for 2.18

This is a revised full patch for custom fields against 2.18 which replaces
those I submitted under comment 268 and comment 269. This solves various edit
and search issues and allows search values to be remembered when editing a
search. I have not fixed the 2 outstanding issues I noted in comment 272.

This is now being used in production and I do not plan to do any more work on
this for some time. I'll leave it to others to implement further types.

On the access privileges mentioned in comment 273 I strongly suggest this is
done as extensions to ALL fields defined in fielddefs and not just to the
additional custom fields. This again I leave to others.

Comment 276

[Max Kanat-Alexander]

As you have probably all noticed, this bug is now a meta-bug for tracking all
the requirements to have a "full-featured" custom fields feature in Bugzilla.

Incremental development should happen on the blocking bugs.

At the moment, none of them are assigned to anybody. If you'd like to work on
them, just assign them to yourself or express interest in working on it, in the
bug. If you have any questions about how to implement anything, the best thing
to do is to catch us on irc.mozilla.org in #mozwebtools. If you can't do that,
you can subsribe to the [e-mail] mailing list and ask your
development-related questions on there.

Please remember, general bugzilla support questions, such as questions about
using any patches currently attached to this bug should go to the
mozilla-webtools newsgroup, not to the developers list. For more details on
that, see http://www.bugzilla.org/support/

Comment 277

[Max Kanat-Alexander]

This is no longer assigned to a specific person. Currently, the primary people
working on it are myk, joel, and myself.

If anybody would like to help, just look over the blockers and see what you'd
like to work on.

Comment 278

[Dorian Woolger]

Since Applying "Updated full custom fields patch for 2.18 " to my fresh 
install I now loose the Summary field every time I modify a bug.

The correct summary appears in any searches but as soon as you open the bug 
for modifying it reverts to --- and if you click commit without changing it, 
it will then be stored as ---

Please help.

Comment 279

[Dorian Woolger]

Attachment: Modifaction to editcustomfields.html.tmpl

Solved my last problem, finger trouble :-(  All working fine now.

Next question.	Can anyone help me.  I need to be able to put more than 255
characters into the valid_exp field.  I have changed the template so that the
actual html field will take it but if I put more than 255 characters into it
the commit button stops working and appears to do nothing.

Any suggestions much appreciated.

Comment 280

[Dorian Woolger]

Attachment: Modifaction to editcustomfields.html.tmpl

Solved my last problem, finger trouble :-(  All working fine now.

Next question.	Can anyone help me.  I need to be able to put more than 255
characters into the valid_exp field.  I have changed the template so that the
actual html field will take it but if I put more than 255 characters into it
the commit button stops working and appears to do nothing.

Any suggestions much appreciated.

Comment 281

[Dorian Woolger]

Attachment: Modifaction to editcustomfields.html.tmpl

Solved my last problem, finger trouble :-(  All working fine now.

Next question.	Can anyone help me.  I need to be able to put more than 255
characters into the valid_exp field.  I have changed the template so that the
actual html field will take it but if I put more than 255 characters into it
the commit button stops working and appears to do nothing.

Any suggestions much appreciated.

Comment 282

[Stuart Marshall]

Looks like you're still having finger trouble!

Comment 283

[Shen ,Chen]

Hi,
I install the full custom fields patch for 2.18.
I run checksetup.pl is ok!
But my bugzilla system can't login very issue for all users.
error message below:

DBD::mysql::st execute failed: Unknown column 'product_id' in 'where clause' 
[for Statement "select customfields.name, products.name from customfields, 
products_customfields, products 
		where customfields.id=cf_id and (product_id = products.id or 
product_id=0) order by customfields.id"] at Bugzilla/DB.pm line 62
	Bugzilla::DB::SendSQL('select customfields.name, products.name from 
customfields, produ...') called at globals.pl line 189
	main::GenerateVersionTable() called at globals.pl line 393
	main::GetVersionTable() called 
at /usr/local/tools/apache/bugzilla/query.cgi line 121

Comment 284

[Olga Garber]

Does anybody know if patch for 2.16.1
https://bugzilla.mozilla.org/attachment.cgi?id=104485 supports 2.16.5?
Thanks

Comment 285

[Stuart Marshall]

I don't know if that patch will work without any modifications, but you would
certainly be able to get it working quite easily if it doesn't. I started with
earlier patches against 2.16.1 and have since upgraded via CVS without any major
problems (see commment 182).

Comment 286

[tomer]

Does it work with the latest 2.20RC1 Version ?

Comment 287

[tomer]

Does it work with the latest 2.20RC1 Version ?

Comment 288

[Jochen Wiedmann]

Attachment: Updated version to the FAC-based alternative implementation

This is an updated version for the patch from comment #261. It should be
applicable against 2.20rc2.

Comment 289

[Jochen Wiedmann]

Attachment: Extended version of the FAC based implementation

This is a highly extended version of the patch against 2.20rc2, which adds
boolean fields, enumerations, and text areas.

The patch depends on the enumeration class patch for Bug 287326:
https://bugzilla.mozilla.org/attachment.cgi?id=193864

Comment 290

[Michael Oehlhof]

I've installed the "A new implementation of custom fields" and "Search fix for
2.18 patch" and "Updated full custom fields patch for 2.18" patches to our
2.18.1 installation.

It is fine that search values to be remembered when editing a search.

But if a saved search is edited, all custom fields have the default values and
not the saved values.

The only reason I could found, is to comment out the default setting.
I tried to set the default to the saved values with
        'default'    => $default{$cfield},
but this doesn't works.

Does anyone know how to set the displayed values to the saved values of the search?

=== This is the code in query.cgi that I have modified with comment out the
default setting ===
#add custom fields
my @custom_fields;
foreach my $cfield (keys %::legal_customfields) {
    my ($t, $ve, $id, $m, $d, $desc) = @{$::legal_customfields{$cfield}};

    # Create hash to hold attributes for each product.
    my %field = (
        'name'       => $cfield,
        'desc'       => $desc,
        'id'         => $id,
#        'default'    => $d,
        'type'       => $t,
        'values'     => ($t eq 'single' or $t eq 'multi')  ? [split('\|',$ve)] : [],
        'size'       => 7,
    );
    push @custom_fields,\%field;
}
$vars->{'custom_fields'} = \@custom_fields;

Comment 291

[Robert Iakobashvili]

A have applied the patch on the most updated debian unstable distro 
and had the following minor problems with 2.18.3 version from debian-sources:
1. perl lib paths were not resolved and to resolve them
   I added to all *.cgi and *.pl files 
   use lib '/usr/share/bugzilla';
   Probably, this is a purely debian issue;

2. As soon as I add a custom field,  I get this error on commiting a new bug:

DBD::mysql::st execute failed: Table 'customfields' was not locked with LOCK
TABLES [for Statement "SELECT id, type, default_value FROM customfields
where name='build_found'"] at Bugzilla/DB.pm line 62
Bugzilla::DB::SendSQL('SELECT id, type, default_value FROM customfields
where name=\...') called at C:/bugzilla/post_bug.cgi line 450

The solution described in:
http://www.forum4designers.com/message291336.html

In post_bug.cgi, I found at line 411, the following statement:

SendSQL("LOCK TABLES bugs WRITE, bug_group_map WRITE, longdescs
WRITE,
cc WRITE, keywords WRITE, dependencies WRITE,
bugs_activity WRITE, groups READ, user_group_map READ,
keyworddefs READ, fielddefs READ");

I added this to the end of the SQL:

customfields READ, bugs_customfields WRITE

After making that change, commit of a new bug or an update bug with a custom
field now works.

Sincerely,
Robert Iakobashvili
[e-mail]

Comment 292

[Stéphane LEIBOVITSCH]

Attachment: Adaptation of previous FAC patch for Bugzilla 2.20

Corrected the Bugzilla/Constants.pm which didn't patch correctly

Comment 293

[Stéphane LEIBOVITSCH]

Attachment: Added a "Date" type for the FAC implementation, against my previous 2.20 patch

Highlights :

- Updated addcustomfield.pl with new type "date"
- New parameter "dateformat" used to control the input format of "date" fields
(no validation of user input)

Thanks for your reviews and criticisms since this is my very first contribution
to Bugzilla.

Comment 294

[Max Kanat-Alexander]

Comment on attachment 199928 [details] [diff] [review]
Added a "Date" type for the FAC implementation, against my previous 2.20 patch

This is a *meta* bug. No attachments will be accepted into the main code base
from this bug.

In fact, patches probably shouldn't be attached to this bug.

Comment 295

[Jochen Wiedmann]

Attachment: Complete version of FAC-based patch for 2.20

This patch accumulates the patches from comment 292 (which is based on the
patch from comment 289) and comment 293.

Alexander, I understand your request for not attaching patches to this bug. But
then, how about reviewing my patch in bug 287326 finally, in order to finish
this finally?

Comment 296

[Jochen Wiedmann]

Attachment: Updated FAC-based patch for 2.20

Updated version of the patch, which no longer uses mysql_last_insert_id, but
the proper bz_last_key.

Comment 297

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 298

[Frédéric Buclin]

*** Bug 320539 has been marked as a duplicate of this bug. ***

Comment 299

[Mubarak]

Please specify the steps to include custom fields.I have downloaded the customfields.tar. But i am not able to proceed further.

Comment 300

[Marc Schumann [:Wurblzap]]

*** Bug 326218 has been marked as a duplicate of this bug. ***

Comment 301

[czy]

(In reply to comment #275)
> Created an attachment (id=177870) [edit]
> Updated full custom fields patch for 2.18
> This is a revised full patch for custom fields against 2.18 which replaces
> those I submitted under comment 268 and comment 269. This solves various edit
> and search issues and allows search values to be remembered when editing a
> search. I have not fixed the 2 outstanding issues I noted in comment 272.
> This is now being used in production and I do not plan to do any more work on
> this for some time. I'll leave it to others to implement further types.
> On the access privileges mentioned in comment 273 I strongly suggest this is
> done as extensions to ALL fields defined in fielddefs and not just to the
> additional custom fields. This again I leave to others.

I use the bugzilla 2.18.1 and use the patch .
I want to update the search.html.tmpl ,what can select different product display the customfields of this product.
Can you help me?
What can i do? 

Comment 302

[nothinking]

Is there any way I can convert the custom field the script creates and change it from a freeform box to one that has preselected values for the user like OS,Priority, Hardware,etc..

Comment 303

[Stuart Marshall]

(In reply to comment #302)
> Is there any way I can convert the custom field the script creates and change
> it from a freeform box to one that has preselected values for the user like
> OS,Priority, Hardware,etc..

If you create a custom field of Type 'Single' and then enter the options in Valid Expression seperated by pipes (e.g. telephone|email|fax|letter), then it appears as a dropdown combo box. 

Or at least that's how it works for me, but I'm still running 2.16.x and hence haven't applied most of the recent customfields changes.

Comment 304

[Michael]

This would be very helpful in order to add various useful meta information to bugs, in particular it would be cool if bugZilla admins could specify meta information for bugs such as:

- estimated complexity of bug/request (low,moderate,huge etc.)
- min. skills required to address a bug/request (i.e. Perl,SQL,HTML  etc.)
- level of skills required (beginner,advanced,expert etc.)
- estimated time required for people with said skills (< 10 hrs,< 20hrs, < 50hrs)

This would make it pretty straightforward to sort of maintain a facility where potential contributors could search the database for bugs matching their individual skill profiles (expertise, max amount of time, components they want to work on etc.) Basically, something like this would probably appeal to most open source projects, as it would become extremely easy to attract new potential contributors.

Comment 305

[nothinking]

Not sure if this is going too off topic but I am using the FAC based patch and using enums. I customized it so it works like version or milestone where I can associate each with a certain product but I am having trouble finding where bugzilla does most of the sql commands to pull from the database and fill in the form values. I went through enter_bug.cgi but with no luck yet. I was looking in globals.pl at the GetVersionTable() function but am not sure there either can any give me a suggestion where to look? Been at this for days now.

Comment 306

[nothinking]

Nvermind I got it.

(In reply to comment #305)
> Not sure if this is going too off topic but I am using the FAC based patch and
> using enums. I customized it so it works like version or milestone where I can
> associate each with a certain product but I am having trouble finding where
> bugzilla does most of the sql commands to pull from the database and fill in
> the form values. I went through enter_bug.cgi but with no luck yet. I was
> looking in globals.pl at the GetVersionTable() function but am not sure there
> either can any give me a suggestion where to look? Been at this for days now.

Comment 307

[nothinking]

Sorry i had a dumb moment. I did not get it sorry help would still be appreciated.



> (In reply to comment #305)
> > Not sure if this is going too off topic but I am using the FAC based patch and
> > using enums. I customized it so it works like version or milestone where I can
> > associate each with a certain product but I am having trouble finding where
> > bugzilla does most of the sql commands to pull from the database and fill in
> > the form values. I went through enter_bug.cgi but with no luck yet. I was
> > looking in globals.pl at the GetVersionTable() function but am not sure there
> > either can any give me a suggestion where to look? Been at this for days now.

Comment 308

[nothinking]

ok this is my last comment in thsi forever I really got it this time. I must be annoying as hell

Comment 309

[Michael]

IMHO, it would possibly make sense to eventually consider providing some sort of template mechanism for custom fields, that way it would be possible to easily exchange preconfigured custom fields, possibly even via some official webpage:

There are various types of custom fields that many users may often find useful, in such cases administrators shouldn't have to manually set up such custom fields, but rather simply download a corresponding template and install it.
For example, a custom field like "benefits" (of implementing an RFE) that may offer preconfigured benefits like "performance improvement", "usability improvement", "reliability improvement", "size improvement", "administration improvement", "debugging improvement" etc. (one could even provide preconfigured drawbacks).

Similar fields are also used by other major bug tracking software (i.e. Microsoft's Connect).
If such custom fields are fully searchable and may possibly be even used to plot diagrams, this could be a very useful development aid.

Likewise, some projects may be interested in what group of people (developers, artists, support, end users), or which components would benefit from implementing a certain RFE, thus one could provide a preconfigured field for "beneficiaries" that may offer corresponding fields (target audience or components) in order to aid development teams in prioritizing their efforts.

Also, some bug trackers provide extra status information for RFEs, specifically meant to track the development progress of an RFE (i.e. discussing, planning, design, implementation phase ...)

Given that there are various patches available to extend bugZilla to be interfaces with SCM systems such as CVS, one could even take this one step further and directly provide potential contributors with a list of affected source files, directly taken from a CVS repository.

Basically, having support for custom fields in bugZilla (including some support for template-based exchange of the corresponding configuration files) would make it quite feasible to have bugZilla become a fully featured project management system. Ultimately, a well designed "custom fields" architecture would possibly make it feasible to convert all standard fields to use the same flexible approach.

Comment 310

[P P N]

I am new to bugzilla and hence would require some help from you all here.

Could anyone let me know how to get the current updates / patches for bugzilla
2.20? In such a case will all the new customization [custom field] etc get
merged with bugzilla 2.20 release?

The customizations mentioned here would really come handy for us too. Please check BUG #344086 about the same. Looking forward to your replies on the same.

Thanks,

Comment 311

[Jochen Wiedmann]

Attachment: Updated FAC-based patch for 2.20.2

This patch adds support for enum fields in the "Advanced Search".

Comment 312

[Max Kanat-Alexander]

Just to make this clear one more time:

* None of the patches on this bug are supported.
* We are implementing custom fields support, and it will have nothing to do with 
  any patch on this bug.
* You will not be able to carry over your custom fields from your old installation 
  into whatever we devise for Bugzilla 3.0.

Comment 313

[Thomas Norlund]

(In reply to comment #312)
> Just to make this clear one more time:
> 
> * None of the patches on this bug are supported.
> * We are implementing custom fields support, and it will have nothing to do
> with 
>   any patch on this bug.
> * You will not be able to carry over your custom fields from your old
> installation 
>   into whatever we devise for Bugzilla 3.0.
> 

I guess we are many who are really excited about finally getting custom field support and would love to know a bit about how it is going to work.
If somebody would tell a bit more about how it will be it would be great.

Comment 314

[Max Kanat-Alexander]

(In reply to comment #313)
> I guess we are many who are really excited about finally getting custom field
> support and would love to know a bit about how it is going to work.
> If somebody would tell a bit more about how it will be it would be great.

  Ah yeah, I totally understand. Your best bet is to read any bugs blocking this one that have been marked as RESOLVED FIXED, because that's what we've implemented so far. Other than that, the best way to find out about custom fields is to use the current CVS version of Bugzilla (using the editfields.cgi script) or to wait until we write the documentation for them.

Comment 315

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 316

[Max Kanat-Alexander]

As this is our meta-bug for tracking custom fields work, it doesn't need a target milestone, and it won't be on the roadmap itself. Instead, specific custom field features will be on the roadmap.

Comment 317

[bigstijn]

Maybe bug 342113 can be mentioned on the "depends on" list ?

Comment 318

[bigstijn]

Also, can bug 377956 be mentioned in the "depends on" list?

Comment 319

[bigstijn]

Due to the implementation of bug 287334, and the choice of bug 287334 comment 19 (For now we will implement this as a single bug id)

could bug 537749 be added to the dependency list?

Comment 320

[Max Kanat-Alexander]

  As far as I'm concerned, this bug is done, and has been for some indefinite period of time. Bugzilla 3.0 added custom fields, there are a bunch of custom field types, and custom fields are now an integral part of Bugzilla, not something we need a tracking bug for anymore.