Explain (Document) how permissions are handled on Bugzilla

RESOLVED FIXED in Bugzilla 3.0

Status

()

Bugzilla
Documentation
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: Tom, Assigned: Sam Folk-Williams)

Tracking

unspecified
Bugzilla 3.0

Details

(URL)

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

12 years ago
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

12 years ago
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

12 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

12 years ago
> 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?  ;-)
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Assignee)

Comment 4

10 years ago
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 5

10 years ago
Created attachment 297079 [details] [diff] [review]
initial patch draft

Please review
Assignee: documentation → sam.folkwilliams
Attachment #297079 - Flags: review?(documentation)

Comment 6

10 years ago
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

10 years ago
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.
Attachment #297079 - Flags: review?(documentation) → review-
(Assignee)

Comment 8

10 years ago
Created attachment 297082 [details] [diff] [review]
second draft of patch

take two... added your comments (edited) to the user prefs page prior to the link... fixed the link id.
Attachment #297079 - Attachment is obsolete: true
Attachment #297082 - Flags: review?(documentation)

Comment 9

10 years ago
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.
Attachment #297082 - Flags: review?(documentation) → review+

Comment 10

10 years ago
Colin, what do you think?
Target Milestone: --- → Bugzilla 2.20

Comment 11

10 years ago
(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

10 years ago
Sam, could you update your patch based on comment 9?
(Assignee)

Comment 13

10 years ago
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
(Assignee)

Comment 14

10 years ago
Created attachment 297842 [details] [diff] [review]
added perm. description

ok added a list of all the descriptions, and then just have the link pointing to that other class of permissions
Attachment #297082 - Attachment is obsolete: true
Attachment #297842 - Flags: review?(documentation)

Comment 15

10 years ago
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

10 years ago
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.
Attachment #297842 - Flags: review?(documentation) → review-
(Assignee)

Comment 17

10 years ago
(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

10 years ago
(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
(Assignee)

Comment 19

10 years ago
Created attachment 297952 [details] [diff] [review]
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.
Attachment #297842 - Attachment is obsolete: true
Attachment #297952 - Flags: review?(documentation)

Comment 20

10 years ago
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.
Attachment #297952 - Flags: review?(documentation)
Attachment #297952 - Flags: review?(LpSolit)
Attachment #297952 - Flags: review+

Comment 21

10 years ago
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.
Attachment #297952 - Flags: review?(LpSolit)

Comment 22

10 years ago
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.
Attachment #297952 - Flags: review?(LpSolit)
Attachment #297952 - Flags: review-
(Assignee)

Comment 23

10 years ago
Created attachment 297976 [details] [diff] [review]
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.
Attachment #297952 - Attachment is obsolete: true
Attachment #297976 - Flags: review?(documentation)

Comment 24

10 years ago
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.
Attachment #297976 - Flags: review?(documentation) → review+

Comment 25

10 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.20 → Bugzilla 3.0
You need to log in before you can comment on or make changes to this bug.