151326 - reporter/qa_contact/assignee cannot confirm bugs

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Gervase Markham [:gerv]]

The reporter, qa_contact and assignee should be able to edit and confirm a bug
even if they normally couldn't. They cannot confirm bugs, however, because
DoConfirm() in process_bug.cgi only checks for group membership.

On a related issue, the above scenario fails silently. So, if an unprivileged
reporter of a bug tries to confirm it, the processing goes through, and mail is
sent - but nothing happens. The bug remains UNCONFIRMED. I have not yet received
such a mail, so can't tell you what it says.

This could be fixed by DoConfirm() throwing a UserError. It probably should do that.

Gerv

Comment 1

[Gervase Markham [:gerv]]

myk, dave: Looking into this bug, it's all a bit of a mess.
CheckCanChangeField() makes very little sense towards the end.

Can we have a definitive policy statement on exactly what fields reporters,
assignees and QA contacts of a bug can change on that bug? Is the answer "all"?

Gerv

Comment 2

[Bradley Baetz (:bbaetz)]

at the moment, its 'most'. We really need ot tighten this up - the repoter
shouldn't be able to change hte target milestone, for example (unless they have
editbugs)

Actually, is this a bug? canconfirm is separate to canedit, and, AFAIK, hsa
always been.

Comment 3

[Matthew Tuck [:CodeMachine]]

Err, reporter shouldn't be able to confirm.

But seriously folks, we're not going to make everyone happy with a strict policy
and we shouldn't try to.  We should just try to make the defaults sensible and
reasonably loose, and let people tighten it up for themselves.

Comment 4

[Bradley Baetz (:bbaetz)]

yeah, but reporter needs to have extra restrictions:

a) milestone
b) alias
c) priority if !PAram("letsubmitterchoosepriority") (or whatever its called)

Anything else?

Comment 5

[Matthew Tuck [:CodeMachine]]

Yeah, my head hurts.

Comment 6

[Jouni Heikniemi]

Hmm... This is interesting. I basically agree with bbaetz that reporter
shouldn't be allowed to change the target milestone, alias and priority fields
(unless letsubmitter blah blah param is set). However, if the assignee and qa
can change even those and the reporter can freely reassign or change the qa,
then he will essentially have editbugs anyway. So for the reporter limitations
to properly apply, we would also have to prevent reassigning and setting the qa
from the reporter (maybe apart from the initial edit_bug screen).

This is fishy. 

Comment 7

[Bradley Baetz (:bbaetz)]

These paramaters aren't really meant to protect against someone forcibly
subverting the system. They're mainly there as a 'don't do that' thing ('oh, I
didn't know I couldn't change the target milestone')

People without editbugs can't do mass changes anyway. If we ever do come across
someone exploiting the system like this, then we cna reconsider it, but I don't
think its needed. Maybe a param, defaulting to on, for
'letSubmitterChooseAssignee'? I don't know - people often come onto #mozilla to
report a bug, and we say, 'yes, file that on [e-mail], its to do with
their change'

Comment 8

[Gervase Markham [:gerv]]

I'm going to sit down and write an access summary. Hopefully it will be simple.
People an then review it, and we can implement it. In the mean time, this bug is
trivial, and can safely be ignored.

Gerv

Comment 9

[Gervase Markham [:gerv]]

Suggested permissions summary now posted to the newsgroups. See also related bug
151714.

Gerv

Comment 10

[Gervase Markham [:gerv]]

We fixed this.

Gerv