Components list should dynamically update when changing the product on the "show_bug.cgi" page

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
P1
enhancement
14 years ago
3 years ago

People

(Reporter: Max Alekseyev, Unassigned)

Tracking

(Blocks: 1 bug)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

14 years ago
I've just tried to change a Product in an existing bugreport but Component list
was not updated by that change and was still showing component list for "old"
Product.

To reproduce:
1. Open some bugreport at bugzilla.mozilla.org
2. Try to select different Product
3. Observe that Component list was not updated according to the chosen Product
works as designed.

you have to click submit and it'll prompt you to set the new component.  The
overhead involved in supplying every possible component of every product is too
big to be worth giving that list to the show_bug page.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

14 years ago
Ok. But why then not make list empty on Product change? Or turn it into a single
option like "Specify later..."?
Current behavior is very confusing. 

btw, WONTFIX seems to be more suitable resolution to your comment than WORKSFORME.

Reopenning for further comments / final resolution.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Hmmm...  "Specify Later..."   I'll go for that. :)  Would be nice and easy to
do, too.  
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

14 years ago
a) The overhead involved in supplying the components is similar to the overhead
in query.cgi -- namely, complicated javascript. :-)

b) I'm unclear as to what is being proposed here. Do you mean having a blank
components list in show_bug? Or when product is changed, blank out the component
list? 
preferably replace the component list (and probably version and milestone) with
"Select later" or something like that.

To be safe, we probably want to stash the original list, and replace it (and its
selection) if they change the product back to the original one before submitting.
>The overhead involved in supplying the components is similar to the overhead
>in query.cgi -- namely, complicated javascript. :-)

Right.  Which isn't that much overhead at all, especially if we reuse the code.
 I think updating the components list like we do on the query form is the right
approach, since then users don't have to load, parse, and act upon an additional
page when making this change.
*** Bug 272179 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> >The overhead involved in supplying the components is similar to the overhead
> >in query.cgi -- namely, complicated javascript. :-)
> 
> Right.  Which isn't that much overhead at all, especially if we reuse the code.

Unless you have products with 3000 components in them.  (Thinking of the RedHat
and Ubuntu bugzillas)
Just for the record, when I was in charge of the Ubuntu Bugzilla, I used to get
a couple complaints a week from people on dialup about how long it took to load
show_bug.cgi for a bug in the Ubuntu product (because of having to load that
3000 item component list for the component dropdown).  We ended up moving the
component list into a separate js file so it could be cached and then having the
javascript populate it after the page loaded, but the caching appeared to break
when it moved to https.

Comment 10

13 years ago
At Red Hat they have a "Use javascript" link that you can use to *turn on* JS on
the page. So by default the JS components stuff is off, which helps the dial-up
users.
Severity: major → enhancement
Summary: Change of Product in existing bugreport doesn't update Component list accordingly → Component list should change when changing the product on the "show bug" page

Comment 11

12 years ago
That's definitely something I would like to see implemented in 2.24. We unfreeze in two weeks. ;)
Target Milestone: --- → Bugzilla 2.24

Updated

12 years ago
Assignee: myk → gandalf

Updated

12 years ago
Blocks: 325501

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa

Comment 12

11 years ago
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

Updated

11 years ago
Duplicate of this bug: 368228

Comment 14

10 years ago
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0

Updated

9 years ago
Duplicate of this bug: 100088
This is a frequent workflow breaker which is very confusing, even if you already know about it. In the age of AJAX and DSL, the technical limitations mentioned in some comments have become irrelevant. I agree with Frédéric's comment 11 from 2006 that this would be a very desirable improvement.
Summary: Component list should change when changing the product on the "show bug" page → Components list should dynamically update when changing the product on the "show_bug.cgi" page

Updated

8 years ago
Duplicate of this bug: 557345

Updated

8 years ago
Duplicate of this bug: 498744

Updated

8 years ago
Assignee: gandalf → create-and-change
Target Milestone: Bugzilla 4.0 → ---

Updated

7 years ago
Duplicate of this bug: 649847

Comment 20

7 years ago
This can easily be accomplished by using the value-controller JS, particularly once bug 636416 goes in.
Priority: -- → P1

Updated

7 years ago
Depends on: 636416

Comment 21

7 years ago
However, we should still be vary careful about performance issues when you have a lot of products or components. Having a slow query.cgi is bad, but having a slow show_bug.cgi is totally unacceptable.

Comment 22

7 years ago
IMO, it would be better to use WS (or the same code as user auto-completion) to get the new component list, instead of making the page even bigger by loading everything into a JS script.

Comment 23

7 years ago
... and if JS is disabled or it's not possible to get the data, then display the intermediate page as we do now.

Comment 24

7 years ago
Doing things via the WS may be the way to go. My suspicion is that it will be ideal for large lists and not a good idea for small lists, so we will want to use a hybrid solution. I think we can adjust the value-controller JS to do this, but I also think that we should do some testing to see at what point this actually gets slow before we make any decisions. (Keeping code simplicity in mind, of course, as well.)
I did something similar to this at Red Hat except it was not taking into account value controls, etc. Basically when the component count was > 50, we did the ajax call to get the whole list if the user clicked on (edit) next to the component name similar to editing assignee, etc. I added a component_count() sub to Product.pm so that it could quickly get a count of components using SQL instead of counting the length of product.components (very big). Reason for this was Fedora for example has 6000+ components. That being said, Red Hat would definitely not go for having all components for all products in JS for show_bug.cgi.

dkl

Updated

7 years ago
Whiteboard: [roadmap: 5.0]
Duplicate of this bug: 728137

Comment 27

5 years ago
Note: This is *already implemented* for the Advanced Search page, see 

http://bzr.mozilla.org/bugzilla/trunk/annotate/head:/js/productform.js

"Reads the selected products and updates component, version and milestone lists accordingly."
Duplicate of this bug: 910367

Updated

4 years ago
Assignee: create-and-change → sgreen
Status: NEW → ASSIGNED
Target Milestone: --- → Bugzilla 5.0

Comment 29

4 years ago
(In reply to Waldir from comment #27)
> Note: This is *already implemented* for the Advanced Search page, see 
> 
> "Reads the selected products and updates component, version and milestone
> lists accordingly."

The problem with this code though is the list of components, version and milestones is loading in the HTML. While taking this approach works on smaller sites, larger sites (like brc, where we have 63,000+ components) would blow the page load time and the page rendering time.

Therefore the approach I am going to take is to use AJAX. For sites that don't have JSON-RPC, they will see what they see now.

Updated

4 years ago
Blocks: 909653

Updated

4 years ago
Blocks: 909203

Comment 30

4 years ago
Created attachment 8348374 [details] [diff] [review]
v1 bundle

It's a bzr bundle since it contains a new gif file. If you prefer a patch + image, let me know.

Known caveat with this change: If the current product only has one version or one milestone, then no select box will show up for that value (no JS error either). The best solution for this is to always show the select box. Let me know if you want this to happen.

The field-ajax.js file has some code relating to the 'anyval' variable. This will be used as part of bug 921566 and bug 921353. I will submit new patches for those bugs once this code has hit trunk.
Attachment #8348374 - Flags: review?(dkl)

Updated

4 years ago
Attachment #8348374 - Attachment is patch: true

Comment 31

4 years ago
Why is the code so different from what has been done in bug 22353? Wouldn't it make sense to share some code between both features? At least the way to call our WebServices and to return data. Note that I'm not a JS expert at all, so this is just a suggestion/question.

Comment 32

4 years ago
> Attachment #8348374 [details] [diff] - Attachment is patch: true

I didn't know if a bzr bundle was considered a patch or not.

(In reply to Frédéric Buclin from comment #31)
> Why is the code so different from what has been done in bug 22353?

Looking at js/bug.js, I don't think is is anything that could be shared here. bug.js populates a YUI2 DataTable complete with formatting, while this code updates one or more drop down box. You couldn't even share the code to call our WebServices, since the init in js/bug.js makes reference to the DataTable object. Or at least I don't think it is possible from the little bit of YUI2 that I know. Am happy for a YUI2 knowledgeable person to tell me otherwise.


  -- simon

Comment 33

4 years ago
(In reply to Simon Green (away until Jan 20th) from comment #30)
> The best solution for this is to always show the select box.
> Let me know if you want this to happen.

Select boxes should always be visible, yes.


(In reply to Myk Melez [:myk] [@mykmelez] from comment #6)
> approach, since then users don't have to load, parse, and act upon an
> additional page when making this change.

There will always be the intermediate page as long as groups are involved. Said differently, loading components dynamically (and the code associated with it) is of no use if the intermediate page will be displayed due to new groups being available or old groups becoming unavailable. So either we fix this problem, or the new AJAX code is useless.

Comment 34

4 years ago
(In reply to Frédéric Buclin from comment #33)
> (In reply to Simon Green (away until Jan 20th) from comment #30)
> > The best solution for this is to always show the select box.
> > Let me know if you want this to happen.
> 
> Select boxes should always be visible, yes.

Okay, I'll fix this after the review is done.

> (In reply to Myk Melez [:myk] [@mykmelez] from comment #6)
> There will always be the intermediate page as long as groups are involved.
> Said differently, loading components dynamically (and the code associated
> with it) is of no use if the intermediate page will be displayed due to new
> groups being available or old groups becoming unavailable. So either we fix
> this problem, or the new AJAX code is useless.

I disagree. Being able to select the new component, version and milestone is of help, but having the groups on a separate page is mandatory. If you move a bug to a product that has no groups (or not the same groups as original product) you want a nice warning about that. You would also need to do the same with flags (since flags can differ between products).

As I see it, this patch is a good start. Doing the groups and flags would require changes to RPC as well (since Product.get doesn't give us group information currently), and that should a separate bug.

YMMV.

  -- simon

Comment 35

4 years ago
(In reply to Simon Green (away until Jan 20th) from comment #34)
> I disagree. Being able to select the new component, version and milestone is
> of help

If of help for what? To get the intermediate page anyway? It would only be helpful if the component, version and milestone are not editable again in the intermediate page.


> but having the groups on a separate page is mandatory. If you move
> a bug to a product that has no groups (or not the same groups as original
> product) you want a nice warning about that.

I totally agree, which is why I think AJAX doesn't help your workflow as you get that page anyway.

Updated

4 years ago
Attachment #8348374 - Attachment is obsolete: true
Attachment #8348374 - Flags: review?(dkl)

Updated

4 years ago
Assignee: sgreen → create-and-change
Status: ASSIGNED → NEW

Updated

4 years ago
No longer blocks: 909203, 909653
No action on this bug in a while, and it's not necessary for 5.0.

Updated

4 years ago
Whiteboard: [roadmap: 5.0]

Updated

3 years ago
Target Milestone: Bugzilla 5.0 → ---
Duplicate of this bug: 1147189
Duplicate of this bug: 1150547

Comment 39

3 years ago
Most new triagers don't know the right product anyway. The search box at https://bugzilla.mozilla.org/enter_bug.cgi?full=1 gets around that by letting you search on the component names and descriptions. Triagers should be able to use this from the bug editing screen to pick a component by searching.

Comment 40

3 years ago
Does this bug also cover the “show info” link? It only shows the description for the current product and component, instead of the newly selected ones.
(In reply to Gingerbread Man from comment #40)
> Does this bug also cover the “show info” link? It only shows the description
> for the current product and component, instead of the newly selected ones.

Pretty sure that could be fixed separately.

Comment 42

3 years ago
(In reply to :Gijs Kruitbosch from comment #41)
> Pretty sure that could be fixed separately.

The good news is a report for the Show Info link already exists (it wasn't easy to find). The bad news is someone proposed essentially wontfixing it.
Bug 1081833
You need to log in before you can comment on or make changes to this bug.