254360 - CheckCanChangeField information for upgraders from the newsgroup

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect)

Description

[Dave Miller [:justdave]]

This should go in the docs in the customizing section, and/or perhaps in the
release notes?

-----

From: Nick Barnes <[e-mail]>
To: [e-mail]
Subject: Re: CheckCanChangeField changes between 2.16.5 and 2.17.7
Date: Mon, 17 May 2004 13:03:06 +0100
Message-ID: <[e-mail]>

I've been looking at changes to the CheckCanChangeField() routine
between Bugzilla releases 2.16.5 and 2.17.7.  As most of you will
know, this routine enforces some of Bugzilla's restrictions on which
users can make particular changes to particular bugs.  The routine has
been rewritten, with several semantic changes.  Bugzilla managers and
administrators should probably be aware of these changes.

I have made the following notes, which are open to correction by any
Bugzilla developer who knows better.

Bear in mind that there are other restrictions enforced by other code.
In particular, the groups system enforces restrictions on who can
create, edit, or even see any given bug.

In Bugzilla 2.16.5, the routine enforces these rules in this order:

   - anyone can make a null change;
   - anyone can add a comment;
   - anyone in the editbugs group can make any change;
   - the reporter can make any change to the status;
   - anyone in the canconfirm group can change the status to any
     opened state (NEW, REOPENED, ASSIGNED).
   - anyone can change the status to any opened state if the
     everconfirmed flag is set;
   - the owner, QA contact, or reporter can make any change *except*
     changing the status to an opened state;
   - No other changes are permitted.

[Note that these rules combine to allow the reporter to make any change
 to the bug]

In Bugzilla 2.17.7, the routine enforces these rules in this order;

   - anyone can make a null change;
   - anyone can add a comment;
   - anyone in the editbugs group can make any change;
   - anyone in the canconform group can change the status from
     UNCONFIRMED to any opened state;
   - the owner or QA contact can make any change;
   - the reporter can make any change *except*:
     - changing the status from UNCONFIRMED to any opened state; or
     - changing the target milestone; or
     - changing the priority (unless the letsubmitterchoosepriority
       parameter is set).
   - No other changes are permitted.

I believe the only effective differences between these rules are as
follows:

1. In 2.16.5, the reporter could always change anything about a bug.

   In 2.17.7, the reporter can't:

   - confirm the bug unless he is in the canconfirm group;
   - change the target milestone;
   - change the priority (unless the 'letsubmitterchoosepriority'
     parameter is set.

   (unless he is also the owner, the QA contact, or in the editbugs
   group, in which case he can do all these things).

2. In 2.16.5, the owner or QA contact (if the 'useqacontact' parameter
   is set) can't change the bug status to an opened status unless they
   are also the reporter, or have editbugs or canconfirm, or the
   everconfirmed flag is set on the bug).

   In 2.17.7 the owner or QA contact can make any change to a bug.

3. In 2.16.5, a member of the canconfirm group can set the status to
   any opened status.

   In 2.17.7 this is only possible if the status was previously the
   unconfirmed status.

4. In 2.16.5, the status can be set to anything by anybody if the
   'everconfirmed' flag is set.

   In 2.17.7, this routine does not pay any attention to the
   'everconfirmed' flag.

Nick Barnes
P4DTI Project
Ravenbrook Limited

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Nick, thanks for the very detailed and incredibly useful list of changes.  I
think the release notes are the best place to document this, since that's where
people will go to find out what has changed between releases.  I've added this
documentation to the release notes under the new header "What's changed?"
(matches the "What's new?" header).

Checking in rel_notes.txt;
/cvsroot/mozilla/webtools/bugzilla/docs/rel_notes.txt,v  <--  rel_notes.txt
new revision: 1.27; previous revision: 1.26
done

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Checking in on the branch too:

Checking in ../../bz218/docs/rel_notes.txt;
/cvsroot/mozilla/webtools/bugzilla/docs/rel_notes.txt,v  <--  rel_notes.txt
new revision: 1.24.2.3; previous revision: 1.24.2.2
done