97471 - assignee_accessible and qa_accessible are unnecessary

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P1)

Description

[Dave Miller [:justdave]]

Bug 39816 made it possible for the Assignee, QA, Reporter, and CC list to see a
bug even if they were not a member of the group the bug was restricted to, by
adding checkboxes for these roles on the bug form.

I'd like to recommend removing the QA and Assignee checkboxes from the form. 
The QA and the Assignee should ALWAYS be able to see a bug.  Perhaps if the
reporter specifies that a bug belongs to a group that the assignee is not a
member of, it should prompt the filer to confirm that they want to put the bug
in that group, or use that assignee (but still allow it since the assignee would
be able to see it anyway).  Same for QA.

Comment 1

[Matthew Tuck [:CodeMachine]]

We would need to check this and get confirmation on a QA/assignee change, as
well as groupset change.

Comment 2

[Dave Miller [:justdave]]

adding to 2.16 block list

Comment 3

[Matthew Tuck [:CodeMachine]]

If this drops off for whatever reason we need to deal with bug #40885 again.

Perhaps we should check no one uses these on the newsgroups?

Comment 4

[Gervase Markham [:gerv]]

I agree. This one's myk's baby to implement :-)

Gerv

Comment 5

[Bradley Baetz (:bbaetz)]

dkl is going to do this with (or after) the group changes, I believe, based on
mail messages from last week.

Comment 6

[David Lawrence [:dkl]]

I could work up a patch over the weekend to the current code and also add this 
changed to the new group branch. I also would like to have the system warn a user 
when:

1. The bug is being changed to a group set that the assignee or qa contact is not a 
member of one or more groups
2. That the bug that this bug is being marked as a duplicate,. depends on, or 
blocker is private or this bug is private and the target bug is not. If that is case then 
offer to add the assignee or qa contact to the Cc list of the target bug.

I am sure there are other scenarios that would need to be covered.

Comment 7

[Gervase Markham [:gerv]]

dkl: if the new group stuff isn't going to land, are we still going to do this?
I think we should.

Gerv

Comment 8

[Bradley Baetz (:bbaetz)]

Removing the fields is easy. Having warnings is more difficult, but it is
technically seperate, and probably easier to do that way.

It is a schema change, and I thought we were trying to avoid those now... Its
not a complicated one though.

Comment 9

[Dave Miller [:justdave]]

removing dependency on bug 68022, which is no longer going to make the cut for
2.16.  This should still go in though.  Most sites that use release code haven't
even seen these fields yet, so we're better off getting rid of them now before
people besides mozilla.org are actually using them.

Comment 10

[Bradley Baetz (:bbaetz)]

Actually, these fields were in 2.14

I'll attach a patch which doesn't do the warning thing - thats a spearate bug.
You can take this or leave it for 2.16 - I'm not going to spend time adding
warnigns at this stage.

Comment 11

[Bradley Baetz (:bbaetz)]

Attachment: patch

Comment 12

[Dave Miller [:justdave]]

Comment on attachment 68064 [details] [diff] [review]
patch

r= justdave

Comment 13

[Andreas Franke (gone)]

Comment on attachment 68064 [details] [diff] [review]
patch

r=afranke.

It's all plausible, and I have not found any other occurrences of
assignee_accessible in the bugzilla sources.

I haven't tested it, though.

Comment 14

[Bradley Baetz (:bbaetz)]

Checked in