From: Gervase Markham <gerv@gerv.net>
Date: Wed, 12 Nov 2014 13:22:27 +0000 (+0000)
Subject: mcote feedback (issue #14).
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=54a665ba8e8a6bf15ba9e611cecc1e3822f34bd2;p=thirdparty%2Fbugzilla.git

mcote feedback (issue #14).
---

diff --git a/docs/en/rst/administering/categorization.rst b/docs/en/rst/administering/categorization.rst
index 07bb9c1825..cbfd41b4a3 100644
--- a/docs/en/rst/administering/categorization.rst
+++ b/docs/en/rst/administering/categorization.rst
@@ -216,35 +216,35 @@ of these options are not listed, it means they are not checked.
 Basic Product/Group Restriction
 -------------------------------
 
-Suppose there is a product called "Bar". The
-"Bar" product can only have bugs entered against it by users in the
-group "Foo". Additionally, bugs filed against product "Bar" must stay
-restricted to users to "Foo" at all times. Furthermore, only members
-of group "Foo" can edit bugs filed against product "Bar", even if other
-users could see the bug. This arrangement would achieved by the
-following:
+Suppose there is a product called "Bar". You would like to make it so that only
+users in the group "Foo" can enter bugs in the "Bar" product. Additionally,
+bugs filed in product "Bar" must be visible only to users in "Foo" (plus, by
+default, the reporter, assignee and CC list of each bug) at all times.
+Furthermore, only members of group "Foo" should be able to edit bugs filed
+against product "Bar", even if other users could see the bug. This arrangement
+would achieved by the following:
 
 ::
 
     Product Bar:
     foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
 
-Perhaps such strict restrictions are not needed for product "Bar". A
-more lenient way to configure product "Bar" and group "Foo" would be:
+Perhaps such strict restrictions are not needed for product "Bar". Instead,
+you would like to make it so that only members of group "Foo" can
+enter bugs in product "Bar", but bugs in "Bar" are not required to be
+restricted in visibility to people in "Foo". Anyone with permission
+to edit a particular bug in product "Bar" can put the bug in group "Foo", even
+if they themselves are not in "Foo".
+
+Furthermore, anyone in group "Foo" can edit all aspects of the components of
+product "Bar", can confirm bugs in product "Bar", and can edit all fields of
+any bug in product "Bar". That would be done like this:
 
 ::
 
     Product Bar:
     foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
 
-The above indicates that for product "Bar", members of group "Foo" can
-enter bugs. Any one with permission to edit a bug against product "Bar"
-can put the bug
-in group "Foo", even if they themselves are not in "Foo". Anyone in group
-"Foo" can edit all aspects of the components of product "Bar", can confirm
-bugs against product "Bar", and can edit all fields of any bug against
-product "Bar".
-
 General User Access With Security Group
 ---------------------------------------
 
diff --git a/docs/en/rst/administering/users.rst b/docs/en/rst/administering/users.rst
index 973f66b8ad..c687b9b374 100644
--- a/docs/en/rst/administering/users.rst
+++ b/docs/en/rst/administering/users.rst
@@ -58,7 +58,8 @@ fields:
 - *Login Name*:
   This is generally the user's full email address. However, if you
   have are using the ``emailsuffix`` parameter, this may
-  just be the user's login name. Note that users can now change their
+  just be the user's login name. Unless you turn off the
+  :param:`allowemailchange` parameter, users can change their
   login names themselves (to any valid email address).
 
 - *Real Name*: The user's real name. Note that