*************************************** *** The Bugzilla 2.18 Release Notes *** *************************************** Introduction ************ This document contains the release notes for Bugzilla 2.18. In this document recently added, changed, and removed features of Bugzilla are described. The 2.18 release is the first in a new stable series, containing the results of over two years of hard and dedicated work by volunteers all over the world under the lead of Dave Miller. This is a preliminary document detailing how we expect things to be in the final 2.18 release. The contents of this document are subject to change up until the final release. Please file bugs in Bugzilla for any additions or corrections needed in this document. Dependency Requirements ----------------------- Minimum software requirements: MySQL v3.23.41 (changed from 2.16) Perl v5.6.0 (changed from 2.16) (Non-Windows platforms) ActiveState Perl v5.8.1 (Windows only) Required Perl modules: AppConfig v1.52 CGI v2.93 (new since 2.16) (changed from 2.17.7) Data::Dumper (any) Date::Format v2.21 (changed from 2.16) DBI v1.36 (changed from 2.16) (changed from 2.17.7) DBD::mysql v2.1010 (changed from 2.16) File::Spec v0.82 File::Temp (any) Template Toolkit v2.08 (changed from 2.16) Text::Wrap v2001.0131 Optional Perl modules: Chart::Base v1.0 (changed from 2.16) (changed from 2.17.7) GD v1.20 (changed from 2.16) GD::Graph (any) (new since 2.16) GD::Text::Align (any) (new since 2.16) Net::LDAP (any) (new since 2.16) PatchReader v0.9.4 (new since 2.16) (changed from 2.17.7) XML::Parser (any) What's New? *********** Generic Reporting ----------------- Bugzilla has a new mechanism for generating reports of the current state of the bug database. It has two related parts: a table-based view, and several graphical views. The table-based view allows you to specify an x, y and z (multiple tables of data) axis to plot, and then restrict the bugs plotted using the standard query form. You can view the resulting data as an HTML or CSV export (e.g.: for importing into a spreadsheet). There are also bar, line and pie charts, which are defined in a very similar way. These views may be more appropriate for particular data types, and are suitable for saving and then putting into presentations or web pages. Request System --------------- The Request System (RS) is a set of enhancements that adds powerful flag (superset of the old attachment status) features to the bugs. RS allows for four states: off, granted, denied, and (optionally) requested, where "granted" is the equivalent of "on". These additions mean it is no longer necessary to define a status to negate another status (e.g. "needs-work" to negate "has-review") because negation is built into each status via the status' "denied" state. Bug statuses: Previously only attachments could have these kinds of statuses. RS enables them for bugs as well. This feature can be used to request and grant/deny certain properties for a bug, such as inclusion for a specific milestone or approval for checkin. This way, Bugzilla supports the natural decision-making process in your organization. - Requests: Flags can now optionally be made requestable, which means users can ask other users to set them. When a user requests a flag, Bugzilla emails the requestee and adds the request to a browsable queue so both the requester and the requestee can keep track of its status. Once the requestee fulfills the request by setting the flag to either granted or denied, Bugzilla emails the requestee and removes the request from the queue. This feature supports workflow like the mozilla.org code review and milestone approval processes, whereby code is peer reviewed before being committed and patches get approved by product release managers for inclusion in specific product releases. - Product/component specificity: Previously flags were product-specific, and if you wanted the same flag for multiple products you had to define multiple flags with the same name. Flags are now product/component-specific, and a single flag can be enabled or disabled for multiple product/component combinations via inclusions and exclusions lists. Flags are enabled for all combinations on their inclusions list except those that appear on their exclusions list. Enterprise Group Support ------------------------ Bugzilla is no longer limited to 55 access control groups. Administrators can define an arbitrary number of access groups composed of individual users or other groups. The groups can be configured via the web interface to achieve a wide variety of access control policies. See the documentation section on 'Groups And Group Controls' for details. User Wildcard Matching ---------------------- Sites can now enable the use of wildcards and substrings in bug entry and editing forms. If the user enters an incomplete username, he'll get a list of users that matched the given username. Support for "Insiders" ---------------------- If the 'insidergroup' parameter is defined, a specific group of users can be designated insiders who can designate comments and attachments as private to other insiders. These comments and attachments will be invisible to other users who are not members of the insiders group even if the bugs to which they apply are visible. Other insiders will see the comments and attachments with a visual tinting indicating that they are private. Time Tracking ------------- Controls for tracking time spent fixing bugs are included in the bug form for members of the group specified by the 'timetrackinggroup' parameter. Any time comments are added to the bug, members of the time tracking group can add an amount of time they spent, and it's figured into the total and displayed at the top of the bug. Shown in the bug are your original estimate, the amount of time spent so far, the revised estimate of how much time is remaining, and your gain/loss on the original estimate. Authentication module/LDAP improvements --------------------------------------- Bugzilla's authentication mechanisms have been modularized, making pluggable authentication schemes for Bugzilla a reality. Both the existing database and LDAP systems were ported as part of modularization process. Additionally, the CGI portion of the backend was redesigned to allow for authentication from other sources, including (theoretically) email, which will help Bug 94850. As part of this conversion, LDAP logins now use Perl's standard Net::LDAP module, which has no external library dependencies. Improved localization support ----------------------------- Bugzilla administrators can now configure which languages are supported by their installations and automatically serve correct, localized content to users based on the HTTP 'Accept-Language' header sent from users' browsers. There are currently localized templates available for: Arabic, Belarusian, Chinese, French, German, Italian, Korean, Portuguese (Brazil) Spanish (Spain or Mexico) and Russian. These localized template packs are third-party contributions, may only be available for specific versions, and may not be supported in the future. (http://www.bugzilla.org/download/#localizations) Patch Viewer ------------ Viewing and reviewing patches in Bugzilla is often difficult due to lack of context, improper format and the inherent readability issues that raw patches present. Patch Viewer is an enhancement to Bugzilla designed to fix that by offering increased context, linking to sections, and integrating with Bonsai, LXR and CVS. Comment Reply Links ------------------- In Edit Bug, each bug comment now includes a convenient (reply) link that quotes the comment text into the textarea. This feature is only enabled in Javascript-capable browsers, but causes no inconvenience to other user agents. Full-Text Search ---------------- It is now possible to query the Bugzilla database using full-text searching, which spans comments and summaries, and which searches for substrings and stem variations of the search term. Basically, it's like using Google. Email Address Munging --------------------- The fact that raw email addresses are displayed in Bugzilla makes it trivial for bots that spamharvest to spider through Bugzilla, in particular, through Bugzilla's buglists. This change adds HTML obfuscation of email addresses as they appear in the Bugzilla web pages. Generic Charting ---------------- Bugzilla's new charting feature allows you to display flexible summary charts, based on configurable data sets (bug 16009). Miscellaneous Improvements -------------------------- - The "Assigned To" field on the new bug page is now prefilled with the default component owner. - A bug alias column is now available in the buglist page. - Lists of bugs containing errors in the sanity check page now have a "view as buglist" link in addition to the individual bug links. - Autolinkification Page - It's now possible to apply Bugzilla's comment hyperlinking algorithm to any text you like. This should be useful for status updates and other web pages which give lists of bugs. The bug links created include the subject, status and resolution of the bug as a tooltip. - There are more tags on the links toolbar for navigating quickly between different areas. - Buglists are now available as comma-separated value files (CSV) and JavaScript (JS) as well as HTML and RDF. - Keywords and dependencies can now be entered during initial bug entry. - A CSS id signature unique to each Bugzilla installation is now added to the tag on Bugzilla pages to allow custom end-user CSS to explicitly affect Bugzilla. - Perl's path has been changed to a normal /usr/bin/perl from the original legacy "bonsaitools" path specifier. - A new "always-require-login" parameter allows administrators to require a login before being able to view any page, except the front page. - A developer may add an attachment, and also reassign a bug to himself as part of that single action. - Bugzilla is now able to use the replication facilities provided by the MySQL database to handle updates from the main database to the secondaries. - Mail handling is now between 125% to 175% faster. What's Changed? *************** Flag names ---------- Prerelease versions of Bugzilla 2.17 and 2.18 inadvertantly allowed commas and spaces in the names of flags, which due to the way they're processed, caused lots of internal havoc if you named flags to have any commas or spaces in them. Having commas or spaces in the names can cause errors in the notification emails and in the bug activity log. The ability to create new flags with these characters has been removed. If you have any existing flags that you named that way, running checksetup will attempt to automatically rename them by replacing commas and spaces with underscores. Rules for changing fields ------------------------- There have been some changes to the rules governing who can change which fields of a bug report. The rules for Bugzilla version 2.16 and 2.18, along with differences between them, are listed below. Bear in mind that there are other restrictions on bug manipulation besides the ones listed below. In particular, the groups system enforces restrictions on who can create, edit, or even see any given bug. Bugzilla 2.16 rules: - anyone can make a null change; - anyone can add a comment; - anyone in the editbugs group can make any change; - the reporter can make any change to the status; - anyone in the canconfirm group can change the status to any opened state (NEW, REOPENED, ASSIGNED). - anyone can change the status to any opened state if the everconfirmed flag is set; - the owner, QA contact, or reporter can make any change *except* changing the status to an opened state; - No other changes are permitted. [Note that these rules combine to allow the reporter to make any change to the bug.] Bugzilla 2.18 rules: - anyone can make a null change; - anyone can add a comment; - anyone in the editbugs group can make any change; - anyone in the canconfirm group can change the status from UNCONFIRMED to any opened state; - the owner or QA contact can make any change; - the reporter can make any change *except*: - changing the status from UNCONFIRMED to any opened state; or - changing the target milestone; or - changing the priority (unless the letsubmitterchoosepriority parameter is set). - No other changes are permitted. The effective differences in the rules: - In 2.16, the reporter could always change anything about a bug. In 2.18, the reporter can't: - confirm the bug unless he is in the canconfirm group; - change the target milestone; - change the priority (unless the 'letsubmitterchoosepriority' parameter is set; (unless he is also the owner, the QA contact, or in the editbugs group, in which case he can do all these things). - In 2.16, the owner or QA contact (if the 'useqacontact' parameter is set) can't change the bug status to an opened status unless they are also the reporter, or have editbugs or canconfirm, or the everconfirmed flag is set on the bug). In 2.18 the owner or QA contact can make any change to a bug. - In 2.16, a member of the canconfirm group can set the status to any opened status. In 2.18 this is only possible if the status was previously the unconfirmed status. - In 2.16, the status can be set to anything by anybody if the 'everconfirmed' flag is set. In 2.18, this authorization code does not pay any attention to the 'everconfirmed' flag. Code Changes Which May Affect Customizations ******************************************** - A mechanism (called "Template Hooks") for third party extensions to plug into existing templates without having to patch or replace distributed templates has been added. More information on this can be found in the documentation. - Header output now uses CGI.pm, in a step towards enabling mod_perl compatibility. This change will affect users that had customized charsets in their CGI files: previously the charset had to be added everywhere that printed the Content-Type header; now it only needs changing in one spot, in Bugzilla/CGI.pm. - $::FORM{} and $::COOKIE{} are deprecated. Use the $cgi methods to access them. - $::userid is gone in favor of Bugzilla->user->id - ConnectToDatabase() is gone (it's done automatically when you initialize the Bugzilla object) - quietly_check_login() and confirm_login() are gone, use Bugzilla->login() with parameters for whether the login is required or not. - Use Bugzilla->user->login in place of $::COOKIE{Bugzilla_login} - You can tell if there's a user logged in or not by checking if Bugzilla->user->id != 0 rather than looking for $::userid != 0 Recommended Practice for the Upgrade ************************************ As always, please ensure you have run checksetup.pl after replacing the files in your installation. It is recommended that you view the sanity check page (sanitycheck.cgi) both before the upgrade and after running checksetup.pl after the upgrade, to see if there are any problems with your installation. It is also recommended that, if possible, you fix any problems you find immediately. Failure to do this may mean that Bugzilla will not work correctly. Be aware that if the sanity check page contains more errors after an upgrade, it doesn't necessarily mean there are more errors in your database, as additional tests are added to the sanity check over time, and it is possible that those errors weren't being checked for in the old version. As previously noted in the Dependency Requirements MySQL is now required to be at least version 3.23.41. This implies that all tables of type ISAM will be converted by the checksetup.pl script to MyISAM. As with any upgrade it is recommended to make a backup of the database, perhaps by using mysqldump. Example: mysqldump -u root -p --databases bugs > bugs.db.backup