Open Bug 674979 Opened 13 years ago Updated 11 years ago

The "Change several bugs at once" page offers you to restrict bugs to groups which are not valid for the product they belong to

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

4.0.1
defect
Not set
minor

Tracking

()

People

(Reporter: LpSolit, Unassigned)

Details

Till Bugzilla 3.6, process_bug.cgi was only looking at valid groups and ignored invalid ones (either because they do not exist, or because the group is not applicable for this product), meaning that you could try to restrict a bug to a group, and no error was thrown if this didn't happen. This was seen as a security issue, because the user may think the bug was now protected when in fact it wasn't, see e.g. bug 276553 comment 0.

So since Bugzilla 4.0, we now take care of all groups passed to process_bug.cgi and throw an error for invalid ones. This makes it clear to the user that his action wasn't successful. But the problem is that the "Change several bugs at once" page still displays too many groups to the user (it uses an union instead of an intersection to determine the groups to display, see bug 134474) and selecting a group which is invalid for at least one bug in the list now throws an error.

We should change the logic in the "Change several bugs at once" page and make it only display groups which are available for all products in the list, as we do with other product-specific fields.
Flags: blocking4.2+
Hmm, no, but what if they only choose to update some of the bugs in the list?
I also think it's telling that this bug has been around for a very long time now and no user reported it to us, AFAIK.
(In reply to comment #2)
> I also think it's telling that this bug has been around for a very long time
> now and no user reported it to us, AFAIK.

The error message being thrown is very new (4.0, see comment 0), and the form offering too many groups has already been reported in 2004, see bug 276553. So it's not just a purely theoretical test case. :)
For what it's worth, I found the current behavior very valuable just the other day. It allowed me to triage a bunch of bugzilla-security bugs that were in a list with other bugs as well.
(In reply to Max Kanat-Alexander from comment #4)
> For what it's worth, I found the current behavior very valuable just the
> other day. It allowed me to triage a bunch of bugzilla-security bugs that
> were in a list with other bugs as well.

Removing a group is not a problem as process_bug.cgi will ignore unset groups. The problem is about trying to restrict a bug to groups which are not applicable.
(In reply to Frédéric Buclin from comment #5)
> Removing a group is not a problem as process_bug.cgi will ignore unset
> groups. The problem is about trying to restrict a bug to groups which are
> not applicable.

  Sure, which throws an error. I mean, is it significantly bad to display the option to the user and then have them experience the error if they tried to do something invalid? I see more support requests from users who say things about that page like, "Why aren't values showing up for me in the drop-downs??" I've never heard a user complain, "I tried to make a mass-change and it threw an error and then I had to change my checkboxes!" That really doesn't sound like a big problem.
Let's remove the blocking flag for now, but I still think it should be make clearer that not all groups are applicable for all bugs present in the buglist.
Severity: normal → minor
Flags: blocking4.2+ → blocking4.2-
Keywords: regression
Bugzilla 4.0 is restricted to security fixes only.
Target Milestone: Bugzilla 4.0 → ---
You need to log in before you can comment on or make changes to this bug.