310400 - Explain (Document) how permissions are handled on Bugzilla

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect)

Description

[Tom]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.10) Gecko/20050715 Firefox/1.0.6 SUSE/1.0.6-4.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.10) Gecko/20050715 Firefox/1.0.6 SUSE/1.0.6-4.3

Bugzilla seems not to specify permissions (who can change what). It seems to be
a matter of configuring the actual Bugzilla server.

This fact should be documented in the Bugzilla documentation, for it is not
clear even after some use

Reproducible: Always

Steps to Reproduce:
1. Read the Doc
Actual Results:  
no mention about permission handling in Bugzilla

Expected Results:  
Explanation that permissions are handled by configuring them. This means that
all Bugzilla servers might have different policies.
For instance, everybody might be able to change the status of a bug from
UNCONFIRMED to NEW on bugzilla.xyz.org, while on bugzilla.abc.org, only the
reporter, assignee and admistrators only could do that.

Comment 1

[Max Kanat-Alexander]

Bugzilla doesn't have the sort of permission controls you're thinking of, that's
why there isn't any documentation on them.

You would have to modify CheckCanChangeField in process_bug.cgi, which I believe
is documented somewhere in the Customizing Bugzilla area of the documentation.

Comment 2

[Frédéric Buclin]

Chapter 5.3. Customizing Who Can Change What

http://www.bugzilla.org/docs/tip/html/cust-change-permissions.html

Everything is already explained here, including some samples.

Comment 3

[Tom]

> http://www.bugzilla.org/docs/tip/html/cust-change-permissions.html
> Everything is already explained here, including some samples.

Yes, but this is a part of the doc that users of bugzilla will not read. This is
nice info for someone who wants to setup a bugzilla server. However:

1)
The bugzilla user might want to know how the permissions work. He might think
that these are identical on each running instance of bugzilla.

2)
If he wants to know how permissions work on bugzilla.mozilla.org, he will
therefore read the "using bugzilla" section of bugzilla.org (until bug #179944
is fixed). IMHO, explaining that permission policies are not specified by
bugzilla, but by the server administrator of the running instance of bugzilla,
would make things clearer.

3)
The defaults of bugzilla should also be mentioned there, for the policies are as
a matter of fact not configurable, but 'hardcoded': Administrators need to make
unportable changes to the code instead of adjusting a configuration file (with
well-defined semantics) to their needs. Therefore, permission handling _could_
be regarded as 'specified by _bugzilla_' instead of the administrator of the
running instance.

Am I too picky on details?  ;-)

Comment 4

[Sam Folk-Williams]

I'm working on cleaning up some old bugs.

I think it makes sense to point people in the right direction, so I'll attach a patch that adds an xref to the existing permissions section in 5.10.4:
http://www.bugzilla.org/docs/tip/html/userpreferences.html

-Sam

Comment 5

[Sam Folk-Williams]

Attachment: initial patch draft

Please review

Comment 6

[Vlad Dascalu]

Comment on attachment 297079 [details] [diff] [review]
initial patch draft

The <note> and </note> tags have one indentation space in addition to the ones requested by the style guide.

Comment 7

[Frédéric Buclin]

Comment on attachment 297079 [details] [diff] [review]
initial patch draft

>+        change what), see  <xref linkend="customization-cust-change-permissions"/>. 

We should explain somewhere that by default, assignees, qa owners and users with editbugs privs can edit all fields of bugs, except group restrictions (unless they are members of the groups they try to play with), and that reporters have the ability to also edit some fields, but in a more restrictive manner. Other users, without editbugs privs, cannot edit bugs, except to comment and CC themselves.

Moreover, the main reason for this r- is that the code doesn't compile. "customization-cust-change-permissions" is not an existing ID and the compiler doesn't know where the target is.

Comment 8

[Sam Folk-Williams]

Attachment: second draft of patch

take two... added your comments (edited) to the user prefs page prior to the link... fixed the link id.

Comment 9

[Frédéric Buclin]

Comment on attachment 297082 [details] [diff] [review]
second draft of patch

This looks good. Now I wonder if we shouldn't mention here some notable privileges, such as canconfirm, editbugs and admins, and keep the discussion about assignee, qa and reporters for the http://www.bugzilla.org/docs/tip/html/cust-change-permissions.html page.

Comment 10

[Frédéric Buclin]

Colin, what do you think?

Comment 11

[Colin Ogilvie [:cso]]

(In reply to comment #9)
> (From update of attachment 297082 [details] [diff] [review])
> This looks good. Now I wonder if we shouldn't mention here some notable
> privileges, such as canconfirm, editbugs and admins, and keep the discussion
> about assignee, qa and reporters for the
> http://www.bugzilla.org/docs/tip/html/cust-change-permissions.html page.

That would make more sense to me, as from what I can gather (it's early) it's talking about /userprefs.cgi?tab=permissions where things like reporter/QA etc. don't really apply but canconfirm, editbugs etc. does.

Comment 12

[Frédéric Buclin]

Sam, could you update your patch based on comment 9?

Comment 13

[Sam Folk-Williams]

yes i can update the patch... so change the patch just to takl about privs such as canconfirm, editbugs, admins, etc... and take out the stuff about QA because that is referenced in the link

Comment 14

[Sam Folk-Williams]

Attachment: added perm. description

ok added a list of all the descriptions, and then just have the link pointing to that other class of permissions

Comment 15

[Frédéric Buclin]

Wait! I liked what you wrote in your previous patch, except it was not at the correct place. Do not delete it. Append it to your new patch.

Comment 16

[Colin Ogilvie [:cso]]

Comment on attachment 297842 [details] [diff] [review]
added perm. description

Your variablelist is wrong -- you don't need a <variablelist> before each <varlistentry>

Also see LpSolit's comment #15 and the 'editusers' should probably be in some sort of tag to make it stand out (like emphasis for example) so it doesn't look like just part of the text.

Comment 17

[Sam Folk-Williams]

(In reply to comment #15)
> Wait! I liked what you wrote in your previous patch, except it was not at the
> correct place. Do not delete it. Append it to your new patch.
> 

OK sorry misunderstood.

(In reply to comment #16)
> (From update of attachment 297842 [details] [diff] [review])
> Your variablelist is wrong -- you don't need a <variablelist> before each
> <varlistentry>
> 

When you say it's "wrong" - is there a document that defines the style? i can't find one. I took this syntax from another place in the current documentation. Can you point me to something that describes correct syntax? Also, do we need to go through a fix this everywhere else in the docs?

Comment 18

[Colin Ogilvie [:cso]]

(In reply to comment #17)
> When you say it's "wrong" - is there a document that defines the style? i can't
> find one. I took this syntax from another place in the current documentation.
> Can you point me to something that describes correct syntax? Also, do we need
> to go through a fix this everywhere else in the docs?

It's wrong because it is invalid XML - the correct layout should be:

<variablelist>
  <varlistentry>
    <term>
      admin
    </term>
    <listitem>
      <para> 
       Indicates user is an Administrator.
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term>
      bz_canusewhineatothers
    </term>
    <listitem>
      <para> 
       Indicates user can configure whine reports for other users.
      </para>
    </listitem>
  </varlistentry>
</variablelist>

All the .xml should be syntatically valid XML, and the definition for variablelist  is http://www.docbook.org/tdg/en/html/variablelist.html

Comment 19

[Sam Folk-Williams]

Attachment: fixed xml, re-added text

Colin - i'm sorry that was a copy/paste error on my part. Didn't read your comment closely enough.

Comment 20

[Colin Ogilvie [:cso]]

Comment on attachment 297952 [details] [diff] [review]
fixed xml, re-added text

r=me but I'm not sure it matches what Frédéric was meaning with his previous comment.

Frédéric - if it is what you asked for, go ahead and check it in.

Comment 21

[Colin Ogilvie [:cso]]

Comment on attachment 297952 [details] [diff] [review]
fixed xml, re-added text

Actually, r=me with a nit: the <variablelist> tag should line up with the <para>'s vertically, and the rest should be indented accordingly.

Comment 22

[Frédéric Buclin]

Comment on attachment 297952 [details] [diff] [review]
fixed xml, re-added text

>+      <para>
>+      By default, assignees, QA owners and users
>+      with <emphasis>editbugs</emphasis> privileges can edit all fields of bugs, 
>+      except group restrictions (unless they are members of the groups they 
>+      are trying to change). Bug reporters also have the ability to edit some 
>+      fields, but in a more restrictive manner. Other users, without 
>+      <emphasis>editbugs</emphasis> privileges, can not edit 
>+      bugs, except to comment and add themselves to the CC list.
>+      </para>

No, what I meant in comment 15 is that this text should be in cust-change-permissions.html, see section 6.4, as it has nothing to do with user privs. So we should keep this text as part of this patch, but moved in cust-change-permissions.html.

Comment 23

[Sam Folk-Williams]

Attachment: new patch for both files

ok i think i finally got it... colin i addressed the nit, lpsolit i moved that bit to the customization file.

Comment 24

[Colin Ogilvie [:cso]]

Comment on attachment 297976 [details] [diff] [review]
new patch for both files

One more nit on the spacing, but that can be fixed on checkin.

Comment 25

[Colin Ogilvie [:cso]]

Checking in on Bugzilla3.0 and BugzillaTrunk only:

Checking in bugzilla-3.0/docs/xml/customization.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/customization.xml,v  <--  customization.xml
new revision: 1.37.2.4; previous revision: 1.37.2.3
done
Checking in bugzilla-3.0/docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.64.2.8; previous revision: 1.64.2.7
done
Checking in bugzilla-trunk/docs/xml/customization.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/customization.xml,v  <--  customization.xml
new revision: 1.43; previous revision: 1.42
done
Checking in bugzilla-trunk/docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.74; previous revision: 1.73
done