BMO/TrackingFlags

From MozillaWiki
< BMO
Jump to: navigation, search

Tracking Flags Extension

Overview

bugzilla.mozilla.org is currently utilizing custom fields to aid in tracking releases for Firefox, Thunderbird, and other projects. This is not ideal as every release requires even more custom fields to be created causing certain tables in Bugzilla to grow very large in number of columns. This new TrackingFlags extension will move the fields to their own tables which will allow us to continue to grow without affecting the core Bugzilla tables and also hopefully improve performance as a result.

https://bugzilla.mozilla.org/show_bug.cgi?id=750742

Goals

  • Change how rapid release tracking flags are stored on bmo from custom fields to an implementation better suited to the problem
    • Custom fields are added as columns to the bugs table, resulting in a performance penalty for large numbers of fields
  • Make adding and disabling flags easier
    • Adding a custom field takes time, and updates are blocked while one is being added
    • disabling a custom field requires a code push
  • Aim to be 100% backwards compatible
    • HTML, XML, XMLRPC, and JSON must all use the current field names
    • Searching (BzAPI uses buglist.cgi, so we need to remain compatible there)
    • We need to ensure real custom fields aren't created with conflicting names

Non-Goals

  • The user interface on show_bugs will not change from its current presentation.
  • The WebService calls required to update flags will not change from its current implementation.

Implementation

  • Admin needs a "copy flag" functionality
  • Admin flag properties and values on a single page (edit table for values, etc) as it's painful right now to add values
  • Need to ensure the db tables are joined as part of the single bug-fetch query (we don't want multiple db queries for each bug)
  • Implement as an extension, however for performances reasons this may not be completely possible (we should prefer performance over extensibility)
  • Add tracking fields to a single x-header in bugmail
  • Should be able to hook into Search.pm to add the custom functions
  • most of these problems should have already been solved when the votes column was moved out of the bugs table to its own extension, copy & paste from that
  • Add a new hook (or use existing hook such as object_before_create) to block adding of new custom fields in editfields.cgi that conflict with names used for tracking flags.

Database Schema

tracking_flags:

  • id PRIMARYKEY
  • name VARCHAR
  • description VARCHAR
  • type VARCHAR /* defined as FLAG_TYPES in lib/Constants.pm */
  • sortkey INTEGER
  • is_active BOOLEAN

tracking_flags_values:

  • id PRIMARYKEY
  • tracking_flag_id INTEGER /* Foreign key to tracking_flags.id */
  • value VARCHAR
  • sortkey INTEGER
  • is_active BOOLEAN
  • setter_group_id INTEGER /* Foreign key to groups.id */

tracking_flags_bugs:

  • id PRIMARYKEY
  • bug_id INTEGER /* Foreign key to bugs.bug_id */
  • tracking_flag_id INTEGER /* Foreign key to tracking_flags.id */
  • value VARCHAR

tracking_flags_visibility:

  • id PRIMARYKEY
  • tracking_flag_id INTEGER /* Foreign key to tracking_flags.id */
  • product_id INTEGER /* Foreign key to products.id */
  • component_id INTEGER /* Foreign key to components.id */