Merge lp:~adeuring/launchpad/bug-201015-bug-branch-search into lp:launchpad/db-devel

This branch is a fix of bug 201015: "Cannot search for bugs with Bazaar branches"

implementation details:

- added an enumeration BugBranchSearch to lp.bugs.interfaces.bugtask
- added a new constructor parameter and a new property "linked_branches" to class BugTaskSearchParams
- code in BugTaskSet.search() to generate an SQL clause for the new search option.
- added a Choice field with BugBranchSearch as a vocabulary to the interface class for the data of the "advanced bug search" form
- told the browser class for the "advanced bug search" to use a radio button widget for the new input filed "search for bugs having [no] linked branches"
- tests of BugTaskSet.search() (via IProduct.searchTasks()) for the new search option
- a short story test for the "presentation" of the new search option

UI note: I wanted to place the new radio buttons close to the existing input field "Show only bugs with patches available", since the new option has a similar purpose. This makes the right column of the table "other options" much longer that the left column, which is aesthetically not very appealing. I considered to move the options "Show only bugs associated with a CVE" and "Show only bugs affecting me" into the left column, but did not do this, because myself would be a bit confused by the changed layout, i.e., I would need a few extra seconds to find the options in their slightly changed location, when doing a bug search...

./bin/test -t bugtask-search.txt
./bin/test -t xx-filter-by-linked-branches.txt

no lint

Hi Abel.

I am sorry you had to touch this page and that I am the reviewer; this
page has irked me for a long time because it does not look consistent
with the rest of Launchpad. Instead of asking you to fix this page, I
will propose code and text fixes that I think are easy to make.

There are some general problems that are never being addresses when
we update this page. I really want to take the time to fix the general
problem with this branch, and you get to close some extra bugs too:

    * Hard to scan. There is not enough white-space in the layout and
      all the text is the same weight and size. Information is lost
      like a tree in a forest.
    * Labels/legends do not match their field content.
    * We have added to this page without ever asking if we need
      to rearrange to the order of the sections to match what users
      want to use.

Your screenshot illustrated these three problems. Notice that the
Tags any/all radio buttons look like there are subordinate to
Show only bugs affecting me. I also question why some checkbox text are
bold and others are normal.

What follows is my analysis and proposed fix: you can see a see a picture
and patch at:
    http://people.canonical.com/~curtis/bug-search.png
    http://people.canonical.com/~curtis/bug-search.patch

My assumption was that the primary problem with this form is that
it is crafted rather than generated. After investigating how I could
make this better, I know understand this issue is really one of
markup+css neglect. All pages that use <legend> in a collapsible field
except this one. They are used to add an expansible section to a form.
This page is intended to be long with all sections visible. We do not
have css rules for this page!

    * In style.css, replace
        legend {font-weight: bold;}

      with
        .long td {
            padding-right: 1em;
            }
        .long fieldset {
            margin-top: 1em;
            }
        .long legend {
            color: #666;
            font-weight: bold;
            font-size: 123.1%;
            }

     * In bugtask-macros-tableview.pt, update the form class in
       <metal:advanced_search_form define-macro="advanced_search_form"> from
          <form class="lesser" name="search" method="get" action="">

       to
          <form class="long" name="search" method="get" action="">

We do not want to use the .lesser class because this page is not showing
a long listing, and it is forcing all the text to be the same small font.
We are replacing the css rules for this page with rules that create space
between the sections and make each section distinct.

As for the legend text and sections:

    * Series-specific => Milestones, components, and tags
      * Remove the width="40%" rules from the <td> and the remove the
        empty <td>.
      * Move tags below milestones and components
      * Use <td span="2"> so that the layout can fit the space:
        Move the help to the right of the input,
        Move the radio button below the field that controls them.

    * Other => Bug relationships
      * Move the "Show ..." group of option to the first column,
        and make your addition to the bottom
 ...

Hi Curtis,

thanks for the improvements of the search page!

On 19.02.2010 19:06, Curtis Hovey wrote:
> Review: Needs Fixing ui
> Hi Abel.
>
> I am sorry you had to touch this page and that I am the reviewer; this
> page has irked me for a long time because it does not look consistent
> with the rest of Launchpad. Instead of asking you to fix this page, I
> will propose code and text fixes that I think are easy to make.
>
> There are some general problems that are never being addresses when
> we update this page. I really want to take the time to fix the general
> problem with this branch, and you get to close some extra bugs too:
>
> * Hard to scan. There is not enough white-space in the layout and
> all the text is the same weight and size. Information is lost
> like a tree in a forest.
> * Labels/legends do not match their field content.
> * We have added to this page without ever asking if we need
> to rearrange to the order of the sections to match what users
> want to use.
>
> Your screenshot illustrated these three problems. Notice that the
> Tags any/all radio buttons look like there are subordinate to
> Show only bugs affecting me. I also question why some checkbox text are
> bold and others are normal.
>
> What follows is my analysis and proposed fix: you can see a see a picture
> and patch at:
> http://people.canonical.com/~curtis/bug-search.png
> http://people.canonical.com/~curtis/bug-search.patch

I applied your patch.

>
> My assumption was that the primary problem with this form is that
> it is crafted rather than generated. After investigating how I could
> make this better, I know understand this issue is really one of
> markup+css neglect. All pages that use <legend> in a collapsible field
> except this one. They are used to add an expansible section to a form.
> This page is intended to be long with all sections visible. We do not
> have css rules for this page!
>
> * In style.css, replace
> legend {font-weight: bold;}
>
> with
> .long td {
> padding-right: 1em;
> }
> .long fieldset {
> margin-top: 1em;
> }
> .long legend {
> color: #666;
> font-weight: bold;
> font-size: 123.1%;
> }
>
> * In bugtask-macros-tableview.pt, update the form class in
> <metal:advanced_search_form define-macro="advanced_search_form"> from
> <form class="lesser" name="search" method="get" action="">
>
> to
> <form class="long" name="search" method="get" action="">
>
> We do not want to use the .lesser class because this page is not showing
> a long listing, and it is forcing all the text to be the same small font.
> We are replacing the css rules for this page with rules that create space
> between the sections and make each section distinct.
>
> As for the legend text and sections:
>
> * Series-specific => Milestones, components, and tags
> * Remove the width="40%" rules from the <td> and the remove the
> empty <td>.
> * Move tags below milestones and components
> * Use <td span="2"> so...

A screenshot of the the searhc page: http://people.canonical.com/~adeuring/branchsearch.png

Hi Abel

  review: approve

On Tue, 2010-02-23 at 09:54 +0000, Abel Deuring wrote:
> Hi Curtis,
...
> I added two checkboxes "Show bugs with[out] branches" below "Show only
> bugs with patches available".
>
> We had on Friday a short discussion on IRC if searching for bugs without
> branches is important enough. I think it is: We want to improve the
> relations with upstream project, and people working on upstream projects
> can find the most autoritative answer to what code is used in Ubuntu in
> Bazaar branches. On the other hand, a link between a branch and bug must
> be manually created by an Ubuntu developer, and this is quite easy to
> forget (I am a good example that this can happen quite often ;) So,
> being able to get a list of bugs in the states "fix commited" and "fix
> released" but having no linked branches allows Ubuntu developers to add
> possibly missing links betwwen branches and bugs, thus making live
> easier for upstream.
>
> Also, we discussed if radio button should be used to select the options
> "search for bugs with/without branches/search all bugs". Deryck proposed
> to use checkboxes instead, and while I would prefer radio buttons,
> because they describe more precisely the three possible options,
> checkboxes are of course more consistent with the other interfaces
> elements of the page.

Yes, a radio button is correct in this case. Your screenshot of two
mutually exclusive checkboxes selected shows we are encouraging users to
ask the impossible. I think the layout was the underlying reason to
change the control. This layout is much nicer and the position of the
two radio buttons will make the intent clear.

--
__Curtis C. Hovey_________
http://launchpad.net/