821028 - Alternate solution for sorting products by classification using "Browse"

Status: UNCONFIRMED

(Bugzilla :: User Interface, enhancement)

Description

[te.atl75]

Attachment: patch.diff

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

Enable classifications and define some classifications with products in them
Select Browse from either header or footer
Select a product



Actual results:

In 4.2 and earlier all products that are visible to the user were listed with no set sort order.  For implementations with large numbers of products this is unwieldy.

In 4.4 all products that are visible to the user were listed, separated into sections by Classification, and sorted.  While easier to search for the appropriate product, this is still unwieldy for implementations with large numbers of products.

In all releases, once a product is selected, the list of components for the product is presented.  The user can select a single component to browse, but can not browse all bugs in the product regardless of component.


Expected results:

If classifications are enabled, the interface to enter bugs first presents the user with a list of classifications that contain products the user can access.   The user selects the appropriate classification and then is presented with a list of all the products that the user can access.  

When browsing, the user should have the option to select a Classification, then be presented only with the products associated with that Classification that the user can access.   Selecting a product should then display the list of the components.  In addition to being able to select a single component to browse for, the user should be presented with the option to browse against all components in the product.

Attached is  a patch to 4.4rc1 code to be considered that implements this.  Files changed were describecomponents.cgi and template/en/default/reports/components.html.tmpl

Comment 1

[Koosha KM]

Comment on attachment 691515 [details] [diff] [review]
patch.diff

>=== modified file 'template/en/default/reports/components.html.tmpl'
>--- template/en/default/reports/components.html.tmpl	2012-09-19 19:11:15 +0000
>+++ template/en/default/reports/components.html.tmpl	2012-12-12 21:55:11 +0000
>@@ -1,9 +1,22 @@
>-[%# This Source Code Form is subject to the terms of the Mozilla Public
>-  # License, v. 2.0. If a copy of the MPL was not distributed with this
>-  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
>-  #
>-  # This Source Code Form is "Incompatible With Secondary Licenses", as
>-  # defined by the Mozilla Public License, v. 2.0.
>+[%# The contents of this file are subject to the Mozilla Public
>+  # License Version 1.1 (the "License"); you may not use this file
>+  # except in compliance with the License. You may obtain a copy of
>+  # the License at http://www.mozilla.org/MPL/
>+  #
>+  # Software distributed under the License is distributed on an "AS
>+  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
>+  # implied. See the License for the specific language governing
>+  # rights and limitations under the License.
>+  #
>+  # The Original Code is the Bugzilla Bug Tracking System.
>+  #
>+  # The Initial Developer of the Original Code is Netscape Communications
>+  # Corporation. Portions created by Netscape are
>+  # Copyright (C) 1998 Netscape Communications Corporation. All
>+  # Rights Reserved.
>+  #
>+  # Contributor(s): Bradley Baetz <[e-mail]>
>+  #                 Max Kanat-Alexander <[e-mail]>
>   #%]


Do not change the header of the file.

Comment 2

[Frédéric Buclin]

Comment on attachment 691515 [details] [diff] [review]
patch.diff

Thanks for your patch. There is a lot of duplicated code with enter_bug.cgi and Classification.pm, which is bad from a maintainability point of view. Also, as koosha said, you are not allowed to change the license used by Bugzilla.

I'm not sure this is a good idea to only list classifications because it can make it harder to quickly find the product you want. You would first have to know the classification in which the product is. I would prefer classifications to be listed at the top of the page, and they would be clickable to bring you to the correct section of the page.

Comment 3

[te.atl75]

Whoops.  Missed that when I merged.  I originally made this on 4.2 and the source has a different header.  I'll fix that.

I respectfully disagree about only listing classifications.  Its a consistent look and feel to the interface with how bug creation is done.  We have well north of 100 products in our installation, some with similar names.  My users will find the product they want way faster with this method.  However, I will concede that whether its easier or not is going to be dependent on the installation.  Not all installations will be laid out like ours.

As to the shared code, I'll take a second look at it and see about making a common subroutine shared between enter_bug and describecomponents.  I can also look into adding a preferences setting or a new adminstrative setting to control whether the classifications are listed first, at the top, or the current default manner.

Comment 4

[Frédéric Buclin]

(In reply to te.atl75 from comment #3)
> also look into adding a preferences setting or a new adminstrative setting
> to control whether the classifications are listed first, at the top, or the
> current default manner.

No need for a user preference or parameter for that.

Comment 5

[te.atl75]

Attachment: Revised patch for classification based browsing

Comment 6

[te.atl75]

I've reworked it.  The licenses are all current this time.  describecomponents.cgi is cleaned up.  I also made a change to Classification.pm to alpha sort the products in the sort_products_by_classification, and added a message to messages.html.tmpl for display when an invalid classification is submitted in the URL to describecomponents.

I spent several days playing with putting the classifications at the top of the chooseproduct.html.tmpl screen, but my test users were unhappy with the appearance.  I thought about using 2 separate div sections for the classification list and the product list, but that only works for long classification lists if the divs are side by side and ideally needs a fixed height browser window for scrolling, plus its not really consistent with the look and feel elsewhere.  Feedback?

Comment 7

[Benjamin Smedberg]

Comment on attachment 693476 [details] [diff] [review]
Revised patch for classification based browsing

Setting review flag to a real person.

Comment 8

[:glob ✱]

Comment on attachment 693476 [details] [diff] [review]
Revised patch for classification based browsing

Review of attachment 693476 [details] [diff] [review]:
-----------------------------------------------------------------

sorry for taking so very very long to look at this.

i've been playing with this patch, but i agree with comment 2 that it would be better to display both classifications and products on the same page, however i also see how it can be helpful for some installations.

i think a user preference is actually warranted here, to switch between the current layout (classifications and products on a single page) and one with classification selection as a discrete step before product selection.

Comment 9

[David Lawrence [:dkl]]

(In reply to Byron Jones ‹:glob› from comment #8)
> Comment on attachment 693476 [details] [diff] [review]
> Revised patch for classification based browsing
> 
> Review of attachment 693476 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> sorry for taking so very very long to look at this.
> 
> i've been playing with this patch, but i agree with comment 2 that it would
> be better to display both classifications and products on the same page,
> however i also see how it can be helpful for some installations.
> 
> i think a user preference is actually warranted here, to switch between the
> current layout (classifications and products on a single page) and one with
> classification selection as a discrete step before product selection.

I also vote for all on the same page. I am against adding more preferences than necessary. I don't see this kind of choice in other sites and feel we should have all together in one place. People will adjust.

dkl

Comment 10

[te.atl75]

I had almost forgotten this bug.   We actually implemented this as a customization.  Let me point out that this bug describes a fix to two separate issues (though related) and the comments are only addressing the filtering of products by classification.

When I wrote this, we had over 100 products, we are now over 300.  We have to filter.

I don't believe an additional preference is necessary, and a list of more then 10 classifications at the top of the page (which we have) can make display a little unwieldy.  How about a dropdown of classifications at the top of the page to filter by IF classifications are enabled.

As to the second issue, we are talking about exactly the opposite logic of the first issue.  Implementation currently supports filtering all bugs in a product by the component (analogous to filtering products by classification) however does NOT give the option to browse all bugs in the product regardless of component.   Sometimes we have a need to browse all bugs in a product.  So what we implemented was a pseudo component called "All" which allows all bugs to be retrieved for the product regardless of component. 

Combining both modifications preserves a consistent logic behavior in the selection screens instead of flip-flopping the logic rules.