752946 - Moving a bug into another product lists inactive components, milestones and versions

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Ricky Rosario [:rrosario, :r1cky]]

This component isn't used anymore and causes confusion. We end up getting lots of bugs filed under this component that should all be handled directly in SUMO since it is a wiki and has it's own forum for article editors and localizers.

If possible, please remove it.

Comment 1

[David Lawrence [:dkl]]

Sorry, there are 514 bugs outstanding for this component. We must reassign those bugs to another component before we can delete this one. Is there another component we can move them to or should we create a "graveyard" product for support.mozilla.org and move them there?

https://bugzilla.mozilla.org/buglist.cgi?component=Knowledge%20Base%20Articles&product=support.mozilla.org

dkl

Comment 2

[Andre Klapper]

Removing is not very useful as it destroys "historical information". Closing the component for new bug entries (should be possible in the latest version IIRC) and moving to graveyard sounds more useful, but this requires a plan for what to do with open tickets.

Comment 3

[David Lawrence [:dkl]]

(In reply to Andre Klapper from comment #2)
> Removing is not very useful as it destroys "historical information". Closing
> the component for new bug entries (should be possible in the latest version
> IIRC) and moving to graveyard sounds more useful, but this requires a plan
> for what to do with open tickets.

I can certainly disable the component for future use and leave the current bugs as-is for now. Does this sound sufficient?

dkl

Comment 4

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to David Lawrence [:dkl] from comment #3)
> 
> I can certainly disable the component for future use and leave the current
> bugs as-is for now. Does this sound sufficient?

If that prevents new bugs being filed in that component, then yes that is exactly what we want :-)

Comment 5

[David Lawrence [:dkl]]

It has been done.

Comment 6

[Verdi [:verdi] Best to slack me]

People are somehow still able to file bugs with the Knowledge Base Articles component - https://bugzilla.mozilla.org/show_bug.cgi?id=822002

Comment 7

[David Lawrence [:dkl]]

(In reply to Verdi [:verdi] from comment #6)
> People are somehow still able to file bugs with the Knowledge Base Articles
> component - https://bugzilla.mozilla.org/show_bug.cgi?id=822002

Hmm. Seems to be a bug in the way that Bugzilla filters the inactive components/versions/milestones when moving a bug from one product to another. inactive values are omitted from enter_bug.cgi and show_bug.cgi for the same product, but are not omitted when moving from one to another. This is how bug 822002 was able to be moved into the inactive component.

Moving to upstream and will come up with a patch.

dkl

Comment 8

[Frédéric Buclin]

The validators should also reject the new component/milestone/version if they are disabled. Simply hiding values from the UI is not enough. It's very easy to bypass it by hacking the URL directly.

Comment 9

[David Lawrence [:dkl]]

Attachment: Patch to disallow setting of inactive values when changing product (v1)

Comment 10

[David Lawrence [:dkl]]

Comment on attachment 693948 [details] [diff] [review]
Patch to disallow setting of inactive values when changing product (v1)

Need to revise patch as this will not work when the bug is currently set to a component that was active originally but is now set to inactive and any other change is made.

dkl

Comment 11

[David Lawrence [:dkl]]

Attachment: Patch to disallow setting of inactive values when changing product (v2)

Comment 12

[Frédéric Buclin]

Comment on attachment 699477 [details] [diff] [review]
Patch to disallow setting of inactive values when changing product (v2)

>+    my $old_comp = blessed($invocant) ? $invocant->component_obj
>+                                      : $params->{component};

If we create a new bug, $params->{component} contains the name of the component and $old_comp->name will crash because it's not an object. You should do what you did for versions and milestones, i.e. get the component name using $invocant->component.


>+    if ($object->name ne $old_comp->name && !$object->is_active) {

With the change above, ->name must go away as it's a string, not an object.



>=== modified file 'template/en/default/global/user-error.html.tmpl'

>+    The [% type FILTER html %] value '[% value FILTER html %]' is not active.

The problem here is that type is not localizable. You should call [% object_name %] as done in object_does_not_exist.



Otherwise looks good.

Comment 13

[David Lawrence [:dkl]]

Attachment: Patch to disallow setting of inactive values when changing product (v3)

Thanks. New patch for review.

Comment 14

[Frédéric Buclin]

Comment on attachment 703010 [details] [diff] [review]
Patch to disallow setting of inactive values when changing product (v3)

r=LpSolit

Comment 15

[Frédéric Buclin]

I also tested it with 4.2.4 and it works fine.

Comment 16

[David Lawrence [:dkl]]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk    
modified Bugzilla/Bug.pm
modified template/en/default/global/user-error.html.tmpl
Committed revision 8560.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.4             
modified Bugzilla/Bug.pm
modified template/en/default/global/user-error.html.tmpl
Committed revision 8508.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.2             
modified Bugzilla/Bug.pm
modified template/en/default/global/user-error.html.tmpl
Committed revision 8185.

Comment 17

[Verdi [:verdi] Best to slack me]

w00t! Thanks

Comment 18

[Frédéric Buclin]

Added to relnotes for 4.4rc2 and 4.2.5.