write locking. What this means is that if someone needs to make a
change to a bug, they will lock the entire table until the operation
is complete. Locking for write also blocks reads until the write is
- complete. The
- <quote>shadowdb</quote>
+ complete. Note that more recent versions of mysql support row level
+ locking using different table types. These types are slower than the
+ standard type, and Bugzilla does not yet take advantage of features
+ such as transactions which would justify this speed decrease. The
+ Bugzilla team are, however, happy to hear about any experiences with
+ row level locking and Bugzilla</para>
+
+ <para>The <quote>shadowdb</quote>
parameter was designed to get around this limitation. While only a
single user is allowed to write to a table at a time, reads can
continue unimpeded on a read-only shadow copy of the database.
Bugzilla bug changes and comments per day.</para>
<para>The value of the parameter defines the name of the
- shadow bug database.
- Set "shadowdb" to e.g. "bug_shadowdb" if you will be running a
- *very* large installation of Bugzilla.
- <note>
- <para>Enabling "shadowdb" can adversely affect the stability of
- your installation of Bugzilla. You should regularly check that your
- database is in sync. It is often advisable to force a shadow
- database sync nightly via
- <quote>cron</quote>.
- </para>
- </note>
- </para>
-
- <para>If you use the "shadowdb" option, it is only natural that you
- should turn the "queryagainstshadowdb" option on as well. Otherwise
- you are replicating data into a shadow database for no reason!</para>
-
+ shadow bug database. You will need to set the host and port settings
+ from the params page, and set up replication in your database server
+ so that updates reach this readonly mirror. Consult your database
+ documentation for more detail.</para>
</step>
<step>
blurb about how to use Bugzilla at your site.</para>
</step>
+
+ <step>
+ <para>
+ <command>movebugs</command>:
+
+ This option is an undocumented feature to allow moving bugs
+ between separate Bugzilla installations. You will need to understand
+ the source code in order to use this feature. Please consult
+ <filename>movebugs.pl</filename> in your Bugzilla source tree for
+ further documentation, such as it is.
+ </para>
+ </step>
+
<step>
<para>
<command>useqacontact</command>:
you for this username and password.</para>
<tip>
- <para>If you wish to add more administrative users, you must use the
- MySQL interface. Run "mysql" from the command line, and use these
- commands:
- <simplelist>
- <member>
- <prompt>mysql></prompt>
- <command>use bugs;</command>
- </member>
-
- <member>
- <prompt>mysql></prompt>
-
- <command>
- update profiles set groupset=0x7ffffffffffffff where login_name =
- "(user's login name)";
- </command>
- </member>
- </simplelist>
+ <para>If you wish to add more administrative users, add them to
+ the "admin" group and, optionally, add edit the tweakparams, editusers,
+ creategroups, editcomponents, and editkeywords groups to add the
+ entire admin group to those groups.
</para>
-
- <para>Yes, that is
- <emphasis>fourteen</emphasis>
-
- <quote>f</quote>
-
- 's. A whole lot of f-ing going on if you want to create a new
- administator.</para>
</tip>
</section>
</listitem>
<listitem>
- <para>Fill out the "New Name", "New Description", and
- "New User RegExp" fields. "New User RegExp" allows you to automatically
+ <para>Fill out the "Group", "Description", and
+ "User RegExp" fields. "New User RegExp" allows you to automatically
place all users who fulfill the Regular Expression into the new group.
When you have finished, click "Add".</para>
+ <warning>
+ <para>The User Regexp is a perl regexp and, if not anchored, will match
+ any part of an address. So, if you do not want to grant access
+ into 'mycompany.com' to 'badperson@mycompany.com.hacker.net', use
+ '@mycompany\.com$' as the regexp.</para>
+ </warning>
+ </listitem>
+ <listitem>
+ <para>After you add your new group, edit the new group. On the
+ edit page, you can specify other groups that should be included
+ in this group and which groups should be permitted to add and delete
+ users from this group.</para>
</listitem>
</orderedlist>
<para>Turn on "usebuggroups" and "usebuggroupsentry" in the "Edit
Parameters" screen.</para>
- <warning>
- <para>XXX is this still true?
- "usebuggroupsentry" has the capacity to prevent the
- administrative user from directly altering bugs because of
- conflicting group permissions. If you plan on using
- "usebuggroupsentry", you should plan on restricting
- administrative account usage to administrative duties only. In
- other words, manage bugs with an unpriveleged user account, and
- manage users, groups, Products, etc. with the administrative
- account.</para>
- </warning>
</listitem>
<listitem>
</listitem>
</orderedlist>
- <warning>
- <para>Bugzilla currently has a limit of 64 groups per installation. If
- you have more than about 50 products, you should consider
- running multiple Bugzillas. Ask in the newsgroup for other
- suggestions for working around this restriction.</para>
- </warning>
-
<para>
Note that group permissions are such that you need to be a member
of <emphasis>all</emphasis> the groups a bug is in, for whatever
By modifying this, you can tell your users how they should report
bugs.
</para>
+
+ <para>
+ <command>bug/process/midair.html.tmpl</command>:
+ This is the page used if two people submit simultaneous changes to the
+ same bug. The second person to submit their changes will get this page
+ to tell them what the first person did, and ask if they wish to
+ overwrite those changes or go back and revisit the bug. The default
+ title and header on this page read "Mid-air collision detected!" If
+ you work in the aviation industry, or other environment where this
+ might be found offensive (yes, we have true stories of this happening)
+ you'll want to change this to something more appropriate for your
+ environment.
+ </para>
<para>
<command>bug/create/create.html.tmpl</command> and
</section>
+ <section id="cust-change-permissions">
+ <title>Change Permission Customisation</title>
+
+ <warning>
+ <para>
+ This feature should be considered experimental; the Bugzilla code you
+ will be changing is not stable, and could change or move between
+ versions. Be aware that if you make modifications to it, you may have
+ to re-make them or port them if Bugzilla changes internally between
+ versions.
+ </para>
+ </warning>
+
+ <para>
+ Companies often have rules about which employees, or classes of employees,
+ are allowed to change certain things in the bug system. For example,
+ only the bug's designated QA Contact may be allowed to VERIFY the bug.
+ Bugzilla has been
+ designed to make it easy for you to write your own custom rules to define
+ who is allowed to make what sorts of value transition.
+ </para>
+
+ <para>
+ For maximum flexibility, customising this means editing Bugzilla's Perl
+ code. This gives the administrator complete control over exactly who is
+ allowed to do what. The relevant function is called
+ <filename>CheckCanChangeField()</filename>,
+ and is found in <filename>process_bug.cgi</filename> in your
+ Bugzilla directory. If you open that file and grep for
+ "sub CheckCanChangeField", you'll find it.
+ </para>
+
+ <para>
+ This function has been carefully commented to allow you to see exactly
+ how it works, and give you an idea of how to make changes to it. Certain
+ marked sections should not be changed - these are the "plumbing" which
+ makes the rest of the function work. In between those sections, you'll
+ find snippets of code like:
+ <programlisting> # Allow the owner to change anything.
+ if ($ownerid eq $whoid) {
+ return 1;
+ }</programlisting>
+ It's fairly obvious what this piece of code does.
+ </para>
+
+ <para>
+ So, how does one go about changing this function? Well, simple changes
+ can be made just be removing pieces - for example, if you wanted to
+ prevent any user adding a comment to a bug, just remove the lines marked
+ "Allow anyone to change comments." And if you want the reporter to have
+ no special rights on bugs they have filed, just remove the entire section
+ which refers to him.
+ </para>
+
+ <para>
+ More complex customisations are not much harder. Basically, you add
+ a check in the right place in the function, i.e. after all the variables
+ you are using have been set up. So, don't look at $ownerid before
+ $ownerid has been obtained from the database. You can either add a
+ positive check, which returns 1 (allow) if certain conditions are true,
+ or a negative check, which returns 0 (deny.) E.g.:
+ <programlisting> if ($field eq "qacontact") {
+ if (UserInGroup("quality_assurance")) {
+ return 1;
+ }
+ else {
+ return 0;
+ }
+ }</programlisting>
+ This says that only users in the group "quality_assurance" can change
+ the QA Contact field of a bug. Getting more weird:
+ <programlisting> if (($field eq "priority") &&
+ ($vars->{'user'}{'login'} =~ /.*\@example\.com$/))
+ {
+ if ($oldvalue eq "P1") {
+ return 1;
+ }
+ else {
+ return 0;
+ }
+ }</programlisting>
+ This says that if the user is trying to change the priority field,
+ and their email address is @example.com, they can only do so if the
+ old value of the field was "P1". Not very useful, but illustrative.
+ </para>
+
+ <para>
+ For a list of possible field names, look in
+ <filename>data/versioncache</filename> for the list called
+ <filename>@::log_columns</filename>. If you need help writing custom
+ rules for your organisation, ask in the newsgroup.
+ </para>
+ </section>
+
<section id="upgrading">
<title>Upgrading to New Releases</title>
projects / thirdparty / bugzilla.git / commitdiff
