Closed Bug 97471 Opened 23 years ago Closed 23 years ago

assignee_accessible and qa_accessible are unnecessary


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




Bugzilla 2.16


(Reporter: justdave, Assigned: bbaetz)


(Whiteboard: [schema])


(1 file)

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.
We would need to check this and get confirmation on a QA/assignee change, as
well as groupset change.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
adding to 2.16 block list
Severity: major → blocker
Priority: P3 → P1
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?
I agree. This one's myk's baby to implement :-)

dkl is going to do this with (or after) the group changes, I believe, based on
mail messages from last week.
Assignee: myk → dkl
Depends on: 68022
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 

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.
dkl: if the new group stuff isn't going to land, are we still going to do this?
I think we should.

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.
Whiteboard: [schema]
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 are actually using them.
No longer depends on: 68022
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.
Assignee: dkl → bbaetz
Attached patch patchSplinter Review
Keywords: patch, review
Comment on attachment 68064 [details] [diff] [review]

r= justdave
Attachment #68064 - Flags: review+
Comment on attachment 68064 [details] [diff] [review]


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.
Attachment #68064 - Flags: review+
Checked in
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.