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)
Tracking
()
NEW
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+
Comment 1•13 years ago
|
||
Hmm, no, but what if they only choose to update some of the bugs in the list?
Comment 2•13 years ago
|
||
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.
Reporter | ||
Comment 3•13 years ago
|
||
(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. :)
Comment 4•13 years ago
|
||
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.
Reporter | ||
Comment 5•13 years ago
|
||
(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.
Comment 6•13 years ago
|
||
(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.
Reporter | ||
Comment 7•13 years ago
|
||
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.
Reporter | ||
Comment 8•12 years ago
|
||
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.
Description
•