=== Queries for finding bugs that directly block a tracking bug that are closed but not verified ===

=== Queries for finding bugs that directly block a tracking bug that are closed but not verified ===

−

==== F14 ====

+

−

* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&type0-1-0=equals&order=Importance&value0-1-0=Tracking&field0-1-0=keywords&field0-0-0=alias&type0-0-0=regexp&value0-0-0=^F14 F14 Tracking bugs ] - Use to check we have queries for all tracking bugs.

* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&type0-1-0=equals&order=Importance&value0-1-0=Tracking&field0-1-0=keywords&field0-0-0=alias&type0-0-0=regexp&value0-0-0=^F15 F15 Tracking bugs ] - Use to check we have queries for all tracking bugs.

* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&type0-1-0=equals&order=Importance&value0-1-0=Tracking&field0-1-0=keywords&field0-0-0=alias&type0-0-0=regexp&value0-0-0=^F15 F15 Tracking bugs ] - Use to check we have queries for all tracking bugs.

Bugzilla Extension development

The plan is to support recursive blocking / depends on queries in bugzilla and allow the use of aliases in such queries. The 4.0 version of bugzilla is being targeted because it supports more hooks, allowing this to be done as an extension (probably) without core code changes. 4.0 is currently in release candidate status. It is unknown when Red Hat would upgrade their bugzilla to 4.0.

Extension info

Extension to handle read only views

Hooks needed

We really need to subclass the various db subclasses as there isn't an appropriate hook. Probably I'll just do a PG subclass, since that's the only data base I use. Something similar could be done for each db. When the system is configured the one of the new db subclasses would need to get picked instead of the original ones.

bug_check_can_change_field to prevent changing values in views. Possibly but there isn't an easy way to get back from the field to the table/view information. Another option would be to check when a filed is marked as updatable. Otherwise we will need to rely on admins to not set these values as updatable.

Issues

Relating a field back to the view seems hard to do. May need to rely on people not adding view columns to the update list.

The above hooks aren't really hooks. We seem to need to be a sub class to do this, but that is generally for DB specific stuff and we may not be able to override these generically. We might end up doing it per DB type.

Creation order is an issue. Want the view created after the tables it depends on.

Extension to create recursive blocks / depends on view

With use WITH RECURSIVE which works at least in recent Postres versions and is part of the ANSI standard.

Hooks needed

db_schema_abstract_schema to extend the default schema

Issues

Probably need to create a new object class for this table and then use object columns to add the new columns so that Bugzilla can use them.

Extension to allow aliased by as a query operator.

Works like match any word handling a list of alias regular expressions and transforming to a list of bug ids.

Will use a sub select. That may restrict usage by some databases (probably fairly ones at this point), but is part of the ANSI standard.

Hooks needed

search_operator_field_override

Status

A plan for how to implement the feature has been developed.

A set of extension needed to implement this plan have been scoped out.

The plan has not been verified to make sure it is implementable as currently designed.

A 4.0 test environment has been set up locally.

Mockup for QA - Tracking bug queries

Queries for finding bugs that directly block a tracking bug that are closed but not verified