From mkanat at kerio.com Tue Feb 1 01:04:35 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 31 Jan 2005 17:04:35 -0800 Subject: statuscount.cgi performance (WAS Re: Custom fields schema) In-Reply-To: <20050131155435.912141FB1@ldcmail.amd.com> References: <20050131155435.912141FB1@ldcmail.amd.com> Message-ID: <1107219875.2718.4.camel@localhost.localdomain> On Mon, 2005-01-31 at 07:54, Kevin Benton wrote: > Yes, however, MySQL (in 3.x) apparently won't use more than one index per > table. Since there's an awful lot of data to go through to get to the point > where I can extract the necessary information, I just don't see how FAR will > work at this point without being able to sub-index. Again, I'm glad to be > proven wrong. It'll work pretty easily. You just have to create the right multi-column indexes. Thankfully, with just one table, that's not a problem. -Max From mkanat at kerio.com Tue Feb 1 01:06:20 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 31 Jan 2005 17:06:20 -0800 Subject: Bugzilla Blues In-Reply-To: References: Message-ID: <1107219980.2718.6.camel@localhost.localdomain> On Mon, 2005-01-31 at 09:17, Shane H. W. Travis wrote: > I know just how it sounds in my head, but I don't know enough guitar to > write out the chords or anything. It's a pretty standard walking-bass blues > riff that I'm sure most of you have all heard before. So now, without > further waffling, I present to you... >[snip] That is HILARIOUS. Wow. *I* know enough guitar to chord it out and record it. :-) I'm not much of a blues guitarist, but maybe I could make it work. Who knows, maybe I'll do it. :-D -Max From gerv at mozilla.org Tue Feb 1 11:33:27 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Feb 2005 11:33:27 +0000 Subject: column selector / saving columns per query In-Reply-To: <029701c50577$e14f39c0$070aa8c0@adexainc.com> References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com> <41FA5DEA.5050107@mozilla.org> <029701c50577$e14f39c0$070aa8c0@adexainc.com> Message-ID: <41FF6907.3090009@mozilla.org> Rob Siklos wrote: > Ok, so to recap, the issues with this patch (and my proposed solutions) > are: Rob, This sort of discussion is almost always better in bug reports :-) Please file a report for your patch, summarise the current state of play, and CC anyone whose views you are soliciting. Thanks :-) Gerv From gerv at mozilla.org Tue Feb 1 11:41:06 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Feb 2005 11:41:06 +0000 Subject: Upgrading from 2.16.7 to 2.18 In-Reply-To: <20050128074951.GA14171@sukria.net> References: <20050128074951.GA14171@sukria.net> Message-ID: <41FF6AD2.2040805@mozilla.org> Alexis Sukrieh wrote: > When Upgrading from <= 2.16.7 to 2.18, I'd like to keep the old 'params' > file in order to restore the user defined settings (those that are > available through editparams.cgi). Of course. Bugzilla upgrades are designed to preserve this file. The upgrade code is in UpdateParams() in Bugzilla/Config.pm. > Sadly, using a 2.16 version of 'params' in Bugzilla 2.18 does not seam > to be possible: CGIs say that there is something wrong with the params > file and ask for a second run of checksetup.pl. Indeed not - there are lots of missing params. > When I run a second time checksetup.pl, the params file is the 2.18 > default one and that mean that everything that was saved before is reset > to default 2.18 values. Really? That's not what's supposed to happen. Are you sure? Gerv From gerv at mozilla.org Tue Feb 1 11:54:08 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Feb 2005 11:54:08 +0000 Subject: Enums In-Reply-To: <1106866641.12303.17.camel@localhost.localdomain> References: <1106866641.12303.17.camel@localhost.localdomain> Message-ID: <41FF6DE0.6060704@mozilla.org> Max Kanat-Alexander wrote: > Hey all. So, there's a patch (by me) on the "enums bug", bug 17453, one > of the oldest bugs that we have in Bugzilla. The patch is just awaiting > review. It's actually not too complex of a patch, and it's a pretty big > architectural benefit that we've been wanting for a long time. Don't jump on me for suggesting this, but if we are getting some traction on the custom fields issue, would it make sense to instead convert platform and OS into one-from-group or multi-from-group custom fields, when that ability arrives? There may, of course, be some reason (like "we have to get rid of enums ASAP for PostGres support") why that wouldn't work... Gerv From kevin.benton at amd.com Tue Feb 1 15:54:21 2005 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 1 Feb 2005 08:54:21 -0700 Subject: Enums In-Reply-To: <41FF6DE0.6060704@mozilla.org> Message-ID: <20050201155421.A51811FB1@ldcmail.amd.com> > > Hey all. So, there's a patch (by me) on the "enums bug", bug 17453, > one > > of the oldest bugs that we have in Bugzilla. The patch is just awaiting > > review. It's actually not too complex of a patch, and it's a pretty big > > architectural benefit that we've been wanting for a long time. > > Don't jump on me for suggesting this, but if we are getting some > traction on the custom fields issue, would it make sense to instead > convert platform and OS into one-from-group or multi-from-group custom > fields, when that ability arrives? > > There may, of course, be some reason (like "we have to get rid of enums > ASAP for PostGres support") why that wouldn't work... Gerv - I think getting rid of enums today has a far greater benefit than waiting for custom fields some time in the future. At this point, there is no guarantee that a custom fields patch will land prior to the 2.20 freeze, but there's a really good chance that the conversion of enums will. Based on this alone, I think we should move forward with Max's patch. It also seems to me that custom fields capability would be worth a v3.0 number as opposed to 2.20. What do others think? --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From travis at SEDSystems.ca Tue Feb 1 17:20:40 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Tue, 1 Feb 2005 11:20:40 -0600 (CST) Subject: Enums In-Reply-To: <20050201155421.A51811FB1@ldcmail.amd.com> References: <20050201155421.A51811FB1@ldcmail.amd.com> Message-ID: > On Tue, 1 Feb 2005, Gervase Markham wrote: > > There may, of course, be some reason (like "we have to get rid of enums > > ASAP for PostGres support") why that wouldn't work... AIUI ENUMs are MySQL-specific, and don't port well across databases... so what you mention is definitely one reason. On Tue, 1 Feb 2005, Kevin Benton wrote: > At this point, there is no guarantee that a custom fields patch will land > prior to the 2.20 freeze, but there's a really good chance that the > conversion of enums will. This is another really good reason. If you've already got one bird in the hand, then you only need ONE of those two from that bush over there... Also, Gerv, I think you're mistaking 'discussion' for 'movement' on Custom Fields. Right now there's a proposal (and a patch) on the table that appears to be unacceptable to several people. If that gets shot down, we're right back where we started; nowhere. If the ENUMS patch is ready to go, then don't hold it up in favour of some future developments that may or may not come to pass. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From jw_va at ureach.com Tue Feb 1 18:05:12 2005 From: jw_va at ureach.com (Jessie Wang) Date: Tue, 1 Feb 2005 13:05:12 -0500 Subject: need help on "email settings" page Message-ID: <200502011805.NAA12712@www22.ureach.com> Hi, All, We have installed bugzilla 2.16.7 and found one of the major functions is not working. The bugzilla cannot send emails out when adding and reassigning a bug. (It can send emails out when creating a new account or change password). I have account in http://landfill.bugzilla.org/bugzilla-tip/userprefs.cgi?tab=email And I found the ?Email setting? page is different from ours, we only have one Global options and don?t have the ?Enable All Mail? and ?Disable All Mail? buttons, and also ?Field/recipient specific options:? is totally different too, Ours doesn?t have all those options. Could someone please tell me where I can find this part of code? Thanks in advance Jessie ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From jw_va at ureach.com Tue Feb 1 18:17:18 2005 From: jw_va at ureach.com (Jessie Wang) Date: Tue, 1 Feb 2005 13:17:18 -0500 Subject: need help on "email settings" page Message-ID: <200502011817.NAA02607@www20.ureach.com> We have installed 2.16.7, how to do upgrading? Thanks ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Tue, 1 Feb 2005, Jessie Wang (jw_va at ureach.com) wrote: > Hi, All, > > We have installed bugzilla 2.16.7 and found one of the major > functions is not working. The bugzilla cannot send emails out > when adding and reassigning a bug. (It can send emails out when > creating a new account or change password). > > I have account in > http://landfill.bugzilla.org/bugzilla-tip/userprefs.cgi?tab=email > And I found the ?Email setting? page is different from ours, we > only have one Global options and don?t have the ?Enable All > Mail? and ?Disable All Mail? buttons, and also ?Field/recipient > specific options:? is totally different too, Ours doesn?t have > all those options. Could someone please tell me where I can find > this part of code? > > Thanks in advance > Jessie > > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > - > To view or change your list settings, click here: > > > From mkanat at kerio.com Tue Feb 1 18:53:05 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 01 Feb 2005 10:53:05 -0800 Subject: Enums In-Reply-To: <41FF6DE0.6060704@mozilla.org> References: <1106866641.12303.17.camel@localhost.localdomain> <41FF6DE0.6060704@mozilla.org> Message-ID: <1107283985.10863.2.camel@localhost.localdomain> On Tue, 2005-02-01 at 11:54 +0000, Gervase Markham wrote: > "we have to get rid of enums ASAP for PostGres support" Yep, that's exactly it. :-) -Max -- Max Kanat-Alexander Technical Support Manager, USA 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From etzwane at schwag.org Tue Feb 1 22:31:46 2005 From: etzwane at schwag.org (Sean McAfee) Date: Tue, 01 Feb 2005 17:31:46 -0500 Subject: Bugzilla enhancements Message-ID: <20050201223146.D612BBC77@mail.schwag.org> Besides an implementation of custom fields, I've made lots of local customizations to Transmeta's Bugzilla installation of greater or lesser usefulness. I'd like to make them available to the Bugzilla community. This message describes several of the more significant ones. Comments are welcome. As an aside, if you haven't been following the financial news, in all probability Transmeta will be having a mass layoff on March 31 as it adjusts for a new business model. I strongly suspect that I'll be a victim of this layoff, and if so, I won't have a large production Bugzilla database to work with anymore (unless my next employer happens to have one). In the following text which mentions CGI form elements, [Submit] indicates a submit form element, {foo,bar,baz} indicates a selection form element, and indicates a single-line text input element. Database utility routines ------------------------- These are already present in my last custom fields patch, but they're so useful it might be appropriate to put them in Bugzilla.pm or Bugzilla/DB.pm or wherever. process_query($sql, @bind [, $subref]) Prepares a statement handle from $sql, executes it with @bind as bind variables, and passes each returned row to the subroutine referred to by $subref (if given). Returns the number of rows processed. simple_query($sql, @bind) Prepares a statement handle from $sql, executes it with @bind as bind variables, and returns a list of the first column of each returned row. single_row_query($sql, @bind) Prepares a statement handle from $sql, executes it with @bind as bind variables, and returns the first returned row as a list. All three of these routines accept a slightly enhanced type of SQL. I got tired of writing my $placeholder = join ',', ('?') x @array; ...all over the place, so these routines will accept arrayrefs as bind variables as long as the corresponding placeholder is "???". The routines will expand the "???" to a comma-separated list of questions marks of the appropriate length, and expand the corresponding array reference argument to a list of the elements of the array before calling execute() on the statement handle. Typical example: process_query(qq{ SELECT field_id, value FROM cf_shortstring WHERE bug_id = ? AND field_id IN (???) }, $bug_id, \@field_ids, sub { $field{ $_[0] } = $_[1]; }); Often the subroutine is so short that it's not at all unclear to use $_[0], $_[1], etc. in the body, as one can just glance a little ways up and see immediately what columns they refer to. Auto Fields ----------- Our prior incident-tracking system, Teamshare, numbered incidents on a per-product (or "project" in Teamshare parlance) basis. When we converted to Bugzilla, various departments wanted to continue their old numbering system, rather than use Bugzilla IDs which would end up being discontinuous from their point of view. My solution was auto fields, which are fields set programmatically at bug creation. Products that correspond to older Teamshare projects have an integer custom field which at bug creation is automatically set to one greater than the current highest value of that field. To provide extra protection to these fields, which should always remain constant, I have an extra boolean column READONLY in the CUSTOM_FIELDS table, which if set indicates that that field may not be changed via the standard interface. Bug Names --------- It's all well and good that the departments mentioned above get to keep their old numbering system, but it's not that useful if they always need to enter Bugzilla bug IDs on the web interface. My solution was what I call "bug names". I have a table BUG_NAME with columns PRODUCT_ID, PREFIX, and FIELD_ID. For products in the table, bugs in that product can be identified in many places with the corresponding custom field, prefixed with the given prefix. Example, taken from our actual database: mysql> select * from bug_name; +------------+------------+----------+ | product_id | prefix | field_id | +------------+------------+----------+ | 2 | TLC Case # | 1 | | 13 | AE Case # | 224 | | 14 | AppsUnit | 260 | +------------+------------+----------+ Bug 1202 in our system is in product 2, and it has the title "TLC Case #2366" at the top of its show_bug.cgi page, rather than "Bug #1202". Instead of "[Find] bug #" in our page footers as a means of going to a specific bug, we have "{Bugzilla Bug ID,TLC Case #,AE Case #,AppsUnit} [Find]". Various bits of code expect the field ID associated with a bug to have a unique value. So really, it only makes sense to define bug names for products that have fields that are guaranteed to be unique, like the automatically-generated alternate bug IDs mentioned above. Links ----- Links are arbitrary connections between bugs. The schema supporting links is very simple, consisting of a single table, LINKS, with two columns, BUG_FROM and BUG_TO. On the show_bug page, there is a short piece of text: [Create] a {one-way,two-way} link to {Bugzilla Bug, at bugname} . A two-way link simply means to create a second link back from the target bug to this one. @bugname means all prefixes from the BUG_NAME table. Links are indicated on the show_bug.cgi page with a list of short paragraphs like this: Linked to Summary of bug 999 Workflows --------- A workflow is a way of structuring the way a bug is worked by users. For products which have an associated workflow, one single-selection type custom field is dubbed that product's "state field". The workflow is a directed graph for which the vertices are labelled with the possible values of the product's state field, and the edges are the possible transitions between states. Transitions are named. A special "initial transition" points from outside the workflow to the state a bug will have when first created. For bugs belonging to a product with a workflow, show_bug.cgi initially shows the bug in a read-only fashion. A user must press one of the buttons near the top of the page, each bearing the name of one of the available transitions, to initiate that transition. Each transition between states is associated with a subset of the product's custom fields in a particular order. When a transition is initiated, the page is redisplayed in an editable form, showing only those custom fields in that transition's subset. In addition, for each transition, each field in the subset may be tagged read-only (the field is displayed but not editable) or required (the field must be set to a non-null value or the update will fail). As a visual aid, the names of read-only fields are shown in gray, and the names of required fields are shown in red. A special transition "Update" is always available. It reloads the page showing all fields as editable--even the state field, which is normally only ever changed behind the scenes. A bug's assignee can be changed automatically in a transition, either to the original reporter, a specific user, or the user referred to in some custom field. The new assignee is only a default, and may be overridden. Transactions ------------ All changes to custom fields, and a few standard fields, are logged with the date/time and identity of the user making the change. Each change to a bug is assigned a unique transaction ID, which serves to group all the field changes together into a single unit. Currently, in our system, little use is made of the logged information, except that on the show_bug.cgi page of each bug with a workflow, a transition history table is displayed with four columns: "User" (the one who created or changed the bug), (the new) "State", (the new) "Owner", and "Date". This feature is based on a similar one in our old Teamshare system. Journaling fields ----------------- Another Teamshare feature. Long string fields may be tagged as "journaling". Such fields are append-only. In an update, new text entered by a user is prefixed with a short, standard introduction: "YY/MM/DD HH:MM - realname :\n" and appended to the existing contents of a field. This append-only behavior is enforced even during the special "update" transition, unless the user is in a special "managers" group. Quick search ------------ This is a means of letting users avoid going through query.cgi by putting common searches in the page footer. A table QUICKSEARCH describes common single-term queries. Our table currently looks like this (squeezed a bit to fit in 80 columns): mysql> select * from quicksearch; +------+-------------------+-----------------------+----------------+---------+ | p_id | query_name | query_term | query_op | sortkey | +------+-------------------+-----------------------+----------------+---------+ | 2 | Description | any note | allwordssubstr | 1 | | 2 | FAE/Issue Contact | tlc_fae_issue_contact | allwordssubstr | 2 | | 2 | Error LEDs | tlc_error_leds | allwordssubstr | 3 | | 2 | Summary | short_desc | allwordssubstr | 4 | +------+-------------------+-----------------------+----------------+---------+ The quick searches are grouped by product and displayed in the page footer to the right of a user's predefined queries, if any. The searches are selected via a