.. _about:
-================
-About This Guide
-================
+========================
+About This Documentation
+========================
This is the documentation for version |version| of Bugzilla, a bug-tracking
system from Mozilla. Bugzilla is an enterprise-class piece of software
.. _administering:
-======================
-Administering Bugzilla
-======================
+====================
+Administration Guide
+====================
For those with :group:`admin` privileges, Bugzilla can be administered using
the :guilabel:`Administration` link in the header. The administrative
categorise bugs. For example, the keyword "regression" is commonly used.
A company might have a policy stating all regressions
must be fixed by the next release—this keyword can make tracking those
-bugs much easier.
-
-Keywords are global, rather than per product. If the administrator changes
-a keyword currently applied to any bugs, the keyword cache must be rebuilt
-using the :ref:`sanity-check` script.
-
-.. todo:: Does this mean changing the name of the keyword? Is it still true?
-
-Currently keywords cannot be marked obsolete to prevent future usage.
+bugs much easier. Keywords are global, rather than per product.
Keywords can be created, edited, or deleted by clicking the "Keywords"
link in the admin page. There are two fields for each keyword—the keyword
-itself and a brief description.
+itself and a brief description. Currently keywords cannot be marked obsolete
+to prevent future usage.
Bugzilla pages for all users, including Admins. Used in the event
of site maintenance or outage situations.
- .. note:: Although regular log-in capability is disabled
- while :param:`shutdownhtml`
- is enabled, safeguards are in place to protect the unfortunate
- admin who loses connection to Bugzilla. Should this happen to you,
- go directly to the :file:`editparams.cgi` (by typing
- the URL in manually, if necessary). Doing this will prompt you to
- log in, and your name/password will be accepted here (but nowhere
- else).
-
- .. todo:: Is this still true? The editparams.cgi code seems to
- call using LOGIN_REQUIRED in the conventional manner...
-
announcehtml
Any text in this field will be displayed at the top of every HTML
page in this Bugzilla installation. The text is not wrapped in any
used for querying bugs.
.. todo:: This is spectacularly unclear. I have no idea what makeproductgroups
- does - can someone explain it to me?
+ does - can someone explain it to me? Convert this item into a bug on checkin.
chartgroup
The name of the group of users who can use the 'New Charts' feature. Administrators should ensure that the public categories and series definitions do not divulge confidential information before enabling this for an untrusted population. If left blank, no users will be able to use New Charts.
+++ /dev/null
-.. _extensions:
-
-Extensions
-##########
-
-One of the best ways to customize Bugzilla is by using a Bugzilla
-Extension. Extensions can modify both the code and UI of Bugzilla in a way
-that can be distributed to other Bugzilla users and ported forward to future
-versions of Bugzilla with minimal effort.
-
-We maintain a
-`list of available extensions <https://wiki.mozilla.org/Bugzilla:Addons>`_
-written by other people on our wiki. You would need to
-make sure that the extension in question works with your version of Bugzilla.
-Or you can look into :ref:`writing your own extension <writing-extensions>`.
+++ /dev/null
-.. highlight:: perl
-
-.. _customizing:
-
-====================
-Customizing Bugzilla
-====================
-
-You may find that Bugzilla already does what you want it to do, you just
-need to configure it correctly. Read the :ref:`administering` sections
-carefully to see if that's the case for you. If not, then this chapter
-explains how to use the available mechanisms for customization.
-
-.. toctree::
- :maxdepth: 2
-
- faq
- extensions
- skins
- languages
- templates
- writing-extensions
======================
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
:numbered: 4
about/index
+ using/index
installing/index
- upgrading/index
- maintaining/index
- customizing/index
- integrating/index
administering/index
- using/index
+ integrating/index
.. toctree::
:hidden:
#. Replace ``%r`` with ``%m %U``.
-.. todo:: Is this the right line? Or given how we've configured it above, is it not a vhost?
+(If you have configured Apache differently, a different log line might apply.
+Adjust these instructions accordingly.)
Restart Apache
==============
`mysqldump documentation <http://dev.mysql.com/doc/mysql/en/mysqldump.html>`_
for more information on :file:`mysqldump`.
-.. todo:: Mention max_allowed_packet?
+.. todo:: Mention max_allowed_packet? Convert this item to a bug on checkin.
PostgreSQL
----------
will delete TestComponent automatically). Note that if you've filed a bug in
TestProduct to try Bugzilla out, you'll need to move it elsewhere before it's
possible to delete TestProduct.
+
+Now, you may want to do some of the :ref:`optional-post-install-config`.
.. _installing:
-===================
-Installing Bugzilla
-===================
+==================================
+Installation and Maintenance Guide
+==================================
.. note:: If you just want to *use* Bugzilla,
you do not need to install it. None of this chapter is relevant to
you. Ask your Bugzilla administrator for the URL to access it from
- your web browser. You may want to read :ref:`using`.
+ your web browser. You may want to read the :ref:`using`.
Bugzilla can be installed under Linux, Windows, Mac OS X, and perhaps other
operating systems. However, if you are setting it up on a dedicated machine
case, you may want to read the :ref:`Quick Start instructions <quick-start>`.
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
quick-start
linux
optional-post-install-config
migrating
moving
+ upgrading
+ backups
+ sanity-check
+ merging-accounts
+ multiple-bugzillas
If you are installing your machine from scratch, :ref:`quick-start` may be
the best instructions for you.
-.. todo:: What's our current position on Debian/Ubuntu packages of Bugzilla? Are
- there any, and are they any good?
-
-.. todo:: Which versions of RHEL have packages new enough for us to support them?
-
.. _linux-install-packages:
Install Packages
will instead need:
:command:`yum install httpd mysql-server mod_perl mod_perl-devel httpd-devel
-graphviz patchutils gcc perl(Apache2::SizeLimit) perl(Authen::Radius)
-perl(Authen::SASL) perl(Cache::Memcached) perl(CGI) perl(Chart::Lines)
-perl(Daemon::Generic) perl(Date::Format) perl(DateTime)
-perl(DateTime::TimeZone) perl(DBI) perl(Digest::SHA) perl(Email::MIME)
-perl(Email::MIME::Attachment::Stripper) perl(Email::Reply) perl(Email::Sender)
-perl(Encode) perl(Encode::Detect) perl(File::MimeInfo::Magic)
-perl(File::Slurp) perl(GD) perl(GD::Graph) perl(GD::Text)
-perl(HTML::FormatText::WithLinks) perl(HTML::Parser) perl(HTML::Scrubber)
-perl(IO::Scalar) perl(JSON::RPC) perl(JSON::XS) perl(List::MoreUtils)
-perl(LWP::UserAgent) perl(Math::Random::ISAAC) perl(MIME::Parser)
-perl(mod_perl2) perl(Net::LDAP) perl(Net::SMTP::SSL) perl(PatchReader)
-perl(SOAP::Lite) perl(Template) perl(Template::Plugin::GD::Image)
-perl(Test::Taint) perl(TheSchwartz) perl(URI) perl(XMLRPC::Lite)
-perl(XML::Twig)`
-
-.. todo:: Converted to perl() form as per glob's request using info in
- Requirements.pm, but I have no idea if that's exactly right...
+graphviz patchutils gcc 'perl(Apache2::SizeLimit)' 'perl(Authen::Radius)'
+'perl(Authen::SASL)' 'perl(Cache::Memcached)' 'perl(CGI)' 'perl(Chart::Lines)'
+'perl(Daemon::Generic)' 'perl(Date::Format)' 'perl(DateTime)'
+'perl(DateTime::TimeZone)' 'perl(DBI)' 'perl(Digest::SHA)' 'perl(Email::MIME)'
+'perl(Email::MIME::Attachment::Stripper)' 'perl(Email::Reply)'
+'perl(Email::Sender)' 'perl(Encode)' 'perl(Encode::Detect)'
+'perl(File::MimeInfo::Magic)' 'perl(File::Slurp)' 'perl(GD)' 'perl(GD::Graph)'
+'perl(GD::Text)' 'perl(HTML::FormatText::WithLinks)' 'perl(HTML::Parser)'
+'perl(HTML::Scrubber)' 'perl(IO::Scalar)' 'perl(JSON::RPC)' 'perl(JSON::XS)'
+'perl(List::MoreUtils)' 'perl(LWP::UserAgent)' 'perl(Math::Random::ISAAC)'
+'perl(MIME::Parser)' 'perl(mod_perl2)' 'perl(Net::LDAP)' 'perl(Net::SMTP::SSL)'
+'perl(PatchReader)' 'perl(SOAP::Lite)' 'perl(Template)'
+'perl(Template::Plugin::GD::Image)' 'perl(Test::Taint)' 'perl(TheSchwartz)'
+'perl(URI)' 'perl(XMLRPC::Lite)' 'perl(XML::Twig)'`
If you are running RHEL6, you will have to enable the "RHEL Server Optional"
channel in RHN to get some of those packages.
-.. todo:: Add Sqlite RPMs
+If you plan to use SQlite as your database, you will need to also install
+the appropriate packages for that.
Ubuntu and Debian
-----------------
libauthen-sasl-perl libtemplate-perl-doc libfile-mimeinfo-perl
libhtml-formattext-withlinks-perl libgd-dev lynx-cur graphviz`
-.. todo:: Add Sqlite debs
+If you plan to use SQlite as your database, you will need to also install
+the appropriate packages for that.
Gentoo
------
includes any directory which is configured using the
``ScriptAlias`` directive of Apache.
-Once all the files are in a web accessible directory, make that
-directory writable by your web server's user. This is a temporary step
-until you run the :file:`checksetup.pl` script, which locks down your
-installation.
-
-.. todo:: Why is this necessary? What does the webserver write there before
- checksetup.pl is run?
-
.. _linux-install-perl-modules:
Perl Modules
your distribution packages, in which case you will need to install a
Bugzilla-only copy of the newer version.
-At this point, you need to :file:`su` to root. You should remain as root
-until the end of the install.
-
-.. todo:: Is this true, if they are installing modules locally?
+At this point you probably need to become ``root``, e.g. by using
+:command:`su`. You should remain as root until the end of the install. This
+can be avoided in some circumstances if you are a member of your webserver's
+group, but being root is easier and will always work.
-To check whether you have all the required modules and what is still missing,
-run:
+To check whether you have all the required modules, run:
:command:`./checksetup.pl --check-modules`
You can run this command as many times as necessary.
-Install all missing modules locally like this:
+If you have not already installed the necessary modules, and want to do it
+system-wide, invoke your package manager appropriately at this point.
+Alternatively, you can install all missing modules locally (i.e. just for
+Bugzilla) like this:
:command:`./install-module.pl --all`
distribution you are using, but are often called
:file:`<packagename>-devel`.
- .. todo:: Give examples for Debian/Ubuntu and RedHat?
+ .. todo:: Give examples for Debian/Ubuntu and RedHat.
+ Convert this item to a bug after checkin.
.. _linux-config-webserver:
.. _macosx-install-packages:
+.. note:: The Bugzilla team has very little Mac expertise and we've not been
+ able to do a successful install of the latest version. We got
+ close, though. If you've managed it, tell us how and we can update
+ these docs!
+
Install Packages
================
Bugzilla supports MySQL, PostgreSQL, Oracle and SQLite as database servers.
You only require one of these systems to make use of Bugzilla. MySQL is
-most commonly used on Mac OS X. Configure your server according to the
-instructions below:
-
-.. todo:: Has anyone tried anything other than MySQL on Mac OS X?
+most commonly used on Mac OS X. (In fact, we have no reports of anyone using
+anything else.) Configure your server according to the instructions below:
* :ref:`mysql`
* :ref:`postgresql`
--- /dev/null
+.. This file is included in multiple places, so can't have labels as they
+ appear as duplicates.
+
+The procedure to migrate to Git is as follows. The idea is to switch version
+control systems without changing the version of Bugzilla you are using,
+to minimise the risk of conflict or problems. Any upgrade can then
+happen as a separate step.
Download Code from Git
======================
-Download an additional copy of your *current* version of Bugzilla from the git
-repository into a separate directory alongside your existing Bugzilla
-installation (which we will assume is in a directory called :file:`bugzilla`).
-
-You will need a copy of the git program. All Linux distributions have it;
-search your package manager for "git". On Windows or Mac OS X, you can
+First, you need to find what version of Bugzilla you are using. It should be
+in the top right corner of the front page but, if not, open the file
+:file:`Bugzilla/Constants.pm` in your Bugzilla directory and search for
+:code:`BUGZILLA_VERSION`.
+
+Then, you need to download an additional copy of your *current* version of
+Bugzilla from the git repository, and place it in a separate directory
+alongside your existing Bugzilla installation (which we will assume is in a
+directory called :file:`bugzilla`).
+
+To do this, you will need a copy of the :command:`git` program. All Linux
+distributions have it; search your package manager for "git". On Windows or
+Mac OS X, you can
`download the official build <http://www.git-scm.com/downloads>`_.
Once git is installed, run these commands to pull a copy of Bugzilla:
e.g. "4.2.2". (If the the final digit would have been a 0, omit it - so use
"4.4" for the first release in the 4.4 series.)
+You will get a message about a 'detached HEAD'. Don't worry; your head is
+still firmly attached to your shoulders.
+
Save Any Local Customizations
=============================
If you have made customizations to your Bugzilla, and you made them by
changing the Bugzilla code itself (rather than using the Extension system),
-then :file:`patch.diff` will have non-zero size. You will want to keep a copy
-of those changes by keeping a copy of this file. If the file has zero size,
+then :file:`patch.diff` will have significant content. You will want to keep a copy
+of those changes by keeping a copy of this file and any files referenced in it
+by "Only in" lines. If the file has zero size or only insignificant content,
you haven't made any local customizations of this sort.
Shut Down Bugzilla
--- /dev/null
+.. _migrating-from-a-tarball:
+
+Migrating from a Tarball
+########################
+
+.. |diffcommand| replace:: :command:`diff -ru -x data -x lib -x docs -x .git -x CVS -x .cvsignore -x .bzr -x .bzrignore -x .bzrrev ../bugzilla-new . > ../patch.diff`
+
+.. |extstatusinfo| replace:: Copy across any subdirectories which do not exist
+ in your new install.
+
+The procedure to migrate to Git is as follows. The idea is to switch without
+changing the version of Bugzilla you are using, to minimise the risk of
+conflict or problems. Any upgrade can then happen as a separate step.
+
+.. include:: migrating-from-2.inc.rst
--- /dev/null
+.. _multiple-bz-dbs:
+
+One Installation, Multiple Instances
+####################################
+
+This is a somewhat specialist feature; if you don't know whether you need it,
+you don't. It is useful to admins who want to run many separate instances of
+Bugzilla from a single installed codebase.
+
+This is possible by using the ``PROJECT`` environment variable. When accessed,
+Bugzilla checks for the existence of this variable, and if present, uses
+its value to check for an alternative configuration file named
+:file:`localconfig.<PROJECT>` in the same location as
+the default one (:file:`localconfig`). It also checks for
+customized templates in a directory named
+:file:`<PROJECT>` in the same location as the
+default one (:file:`template/<langcode>`). By default
+this is :file:`template/en/default` so ``PROJECT``'s templates
+would be located at :file:`template/en/PROJECT`.
+
+To set up an alternate installation, just export ``PROJECT=foo`` before
+running :command:`checksetup.pl` for the first time. It will
+result in a file called :file:`localconfig.foo` instead of
+:file:`localconfig`. Edit this file as described above, with
+reference to a new database, and re-run :command:`checksetup.pl`
+to populate it. That's all.
+
+Now you have to configure the web server to pass this environment
+variable when accessed via an alternate URL, such as virtual host for
+instance. The following is an example of how you could do it in Apache,
+other Webservers may differ.
+
+.. code-block:: apache
+
+ <VirtualHost 12.34.56.78:80>
+ ServerName bugzilla.example.com
+ SetEnv PROJECT foo
+ </VirtualHost>
+
+Don't forget to also export this variable before accessing Bugzilla
+by other means, such as repeating tasks like those above.
the complete path to :file:`dot.exe` in the :param:`webdotbase` parameter,
using forward slashes as path separators. E.g.
:paramval:`C:/Program Files/ATT/Graphviz/bin/dot.exe`.
-
-.. _multiple-bz-dbs:
-
-Running Multiple Bugzillas from a Single Code Installation
-==========================================================
-
-.. todo:: This doesn't really live here. Where does it live?
-
-This is a somewhat specialist feature; if you don't know whether you need it,
-you don't. It is useful to admins who want to run many separate instances of
-Bugzilla from a single codebase.
-
-This is possible by using the ``PROJECT`` environment variable. When accessed,
-Bugzilla checks for the existence of this variable, and if present, uses
-its value to check for an alternative configuration file named
-:file:`localconfig.<PROJECT>` in the same location as
-the default one (:file:`localconfig`). It also checks for
-customized templates in a directory named
-:file:`<PROJECT>` in the same location as the
-default one (:file:`template/<langcode>`). By default
-this is :file:`template/en/default` so ``PROJECT``'s templates
-would be located at :file:`template/en/PROJECT`.
-
-To set up an alternate installation, just export ``PROJECT=foo`` before
-running :command:`checksetup.pl` for the first time. It will
-result in a file called :file:`localconfig.foo` instead of
-:file:`localconfig`. Edit this file as described above, with
-reference to a new database, and re-run :command:`checksetup.pl`
-to populate it. That's all.
-
-Now you have to configure the web server to pass this environment
-variable when accessed via an alternate URL, such as virtual host for
-instance. The following is an example of how you could do it in Apache,
-other Webservers may differ.
-
-.. code-block:: apache
-
- <VirtualHost 12.34.56.78:80>
- ServerName bugzilla.example.com
- SetEnv PROJECT foo
- </VirtualHost>
-
-Don't forget to also export this variable before accessing Bugzilla
-by other means, such as repeating tasks like those above.
.. _quick-start:
-Quick Start (Ubuntu 14.04 LTS)
-##############################
+Quick Start (Ubuntu Linux 14.04)
+################################
This quick start guide makes installing Bugzilla as simple as possible for
those who are able to choose their environment. It creates a system using
-Ubuntu 14.04 LTS, Apache and MySQL, and installs Bugzilla as the default
+Ubuntu Linux 14.04 LTS, Apache and MySQL, and installs Bugzilla as the default
home page. It requires a little familiarity with Linux and the command line.
Obtain Your Hardware
:command:`./testserver.pl http://localhost/`
-All the tests should pass.
+All the tests should pass. You will get warnings about deprecation from
+the ``Chart::Base`` Perl module; just ignore those.
.. todo:: Chart::Base gives confusing deprecation warnings :-|
https://rt.cpan.org/Public/Bug/Display.html?id=79658 , unfixed for
-.. _upgrading-overview:
+.. _upgrading:
-Overview
-########
+Upgrading
+#########
You can upgrade Bugzilla from any version to any later version in one go -
there is no need to pass through intermediate versions unless you are changing
Whichever path you use, you may need help with
:ref:`upgrading-customizations`.
+
+.. toctree::
+ :maxdepth: 1
+
+ upgrading-with-git
+ migrating-from-bzr
+ migrating-from-cvs
+ migrating-from-a-tarball
+ upgrading-with-a-tarball
+ upgrading-customizations
+
+Bugzilla can automatically notify administrators when new releases are
+available if the :param:`upgrade_notification` parameter is set.
+Administrators will see these notifications when they access the Bugzilla home
+page. Bugzilla will check once per day for new releases. If you are behind a
+proxy, you may have to set the :param:`proxy_url` parameter accordingly. If
+the proxy requires authentication, use the
+:paramval:`http://user:pass@proxy_url/` syntax.
#######
Making Bugzilla work on Windows is more difficult than making it work on Unix,
-fewer Bugzilla developers use it and so it's less well supported. However, if
-you are still determined to do it, here's how.
-
-.. note:: ``mod_perl`` doesn't work very well on Windows, so you probably
- don't want to use Windows for a large site.
-
-.. todo:: Is this still true?
+fewer Bugzilla developers use it and so it's less well supported. We would
+particularly recommend against doing it for a large site. However, if
+you are still determined to go ahead, here's how.
.. windows-install-perl:
-.. _writing-extensions:
+.. _extensions:
-Writing Extensions
-##################
+Extensions
+##########
-See the `Bugzilla Extension
+One of the best ways to customize Bugzilla is by using a Bugzilla
+Extension. Extensions can modify both the code and UI of Bugzilla in a way
+that can be distributed to other Bugzilla users and ported forward to future
+versions of Bugzilla with minimal effort. We maintain a
+`list of available extensions <https://wiki.mozilla.org/Bugzilla:Addons>`_
+written by other people on our wiki. You would need to
+make sure that the extension in question works with your version of Bugzilla.
+
+Or, you can write your own extension. See the `Bugzilla Extension
documentation <../html/api/Bugzilla/Extension.html>`_ for the core
-documentation on how to write an Extension. It would make sense to read
+documentation on how to do that. It would make sense to read
the section on :ref:`templates`. There is also a sample extension in
:file:`$BUGZILLA_HOME/extensions/Example/` which gives examples of how to
use all the code hooks.
+.. highlight:: perl
+
.. _integrating:
-=========================
-Integrating with Bugzilla
-=========================
+===================================
+Integration and Customization Guide
+===================================
+
+You may find that Bugzilla already does what you want it to do, you just
+need to configure it correctly. Read the :ref:`administering` sections
+carefully to see if that's the case for you. If not, then this chapter
+explains how to use the available mechanisms for integration and customization.
.. toctree::
:maxdepth: 2
+ faq
+ languages
+ skins
+ templates
+ extensions
apis
- tips
-
Bugzilla uses a system of templates to define its user interface. The standard
templates can be modified, replaced or overridden. You can also use template
-hooks in an :ref:`extension <writing-extensions>` to add or modify the
+hooks in an :ref:`extension <extensions>` to add or modify the
behaviour of templates using a stable interface.
.. _template-directory:
+++ /dev/null
-.. _tips:
-
-Integration Tips
-################
-
-.. todo:: Do we have any of these?
+++ /dev/null
-.. _maintaining:
-
-====================
-Maintaining Bugzilla
-====================
-
-.. toctree::
- :maxdepth: 2
-
- upgrades
- backups
- sanity-check
- merging-accounts
+++ /dev/null
-.. _upgrades:
-
-Upgrades
-########
-
-For details on how to upgrade Bugzilla, see the :ref:`upgrading` chapter.
-
-Bugzilla can automatically notify administrators when new releases are
-available if the :param:`upgrade_notification` parameter is set.
-Administrators will see these notifications when they access the Bugzilla home
-page. Bugzilla will check once per day for new releases. If you are behind a
-proxy, you may have to set the :param:`proxy_url` parameter accordingly. If
-the proxy requires authentication, use the
-:paramval:`http://user:pass@proxy_url/` syntax.
+++ /dev/null
-.. _upgrading:
-
-==================
-Upgrading Bugzilla
-==================
-
-.. toctree::
- :maxdepth: 2
-
- overview
- upgrading-with-git
- migrating-from-bzr
- migrating-from-cvs
- migrating-from-a-tarball
- upgrading-with-a-tarball
- upgrading-customizations
+++ /dev/null
-.. This file is included in multiple places, so can't have labels as they
- appear as duplicates.
-
-The procedure to migrate to Git is as follows. The idea is to switch version
-control systems without changing the version of Bugzilla you are using,
-to minimise the risk of conflict or problems. Any major upgrade can then
-happen as a separate step.
-
-Update Bugzilla To The Latest Point Release
-===========================================
-
-It is recommended that you switch to Git while using the latest
-point release for your version, so if you aren't running that, you may
-want to do a minor upgrade first.
-
-.. todo:: Is this actually necessary? It adds several extra steps. What are we
- trying to avoid here? If we do have to do it, can we avoid them
- having to work out the latest point release manually? And do the
- bzr and CVS update commands take the full version number including
- the third digit, or do they just take major and minor? We need to
- make sure all commands operate on the same version number style,
- and that it's clearly explained.
-
-First, you need to find what version of Bugzilla you are using. It should be
-in the top right corner of the front page but, if not, open the file
-:file:`Bugzilla/Constants.pm` in your Bugzilla directory and search for
-:code:`BUGZILLA_VERSION`.
-
-Then, you need to find out what the latest point release for that major
-version of Bugzilla is. The
-`Bugzilla download page <http://www.bugzilla.org/download/>`_
-should tell you that for supported versions. For versions out of support, here
-is a list of the final point releases:
-
-* 3.6.13
-* 3.4.14
-* 3.2.10
-* 3.0.11
-* 2.22.7
-* 2.20.7
-* 2.18.6
-* 2.16.11
-* 2.14.5
-
-If you are not currently running the latest point release, you should use the
-following update command:
-
-|updatecommand|
-
-Where you replace $VERSION by the version number of the latest point release.
-Then run checksetup to upgrade your database:
-
-:command:`./checksetup.pl`
-
-You should then test your Bugzilla carefully, or just use it for a day or two,
-to make sure it's all still working fine.
+++ /dev/null
-.. _migrating-from-a-tarball:
-
-Migrating from a Tarball
-########################
-
-.. todo:: Need to check the diff command in the tarball case using a real
- tarball and git checkout
-
-.. |diffcommand| replace:: :command:`diff -ru -x data -x .git ../bugzilla-new . > patch.diff`
-.. |extstatusinfo| replace:: Copy across any subdirectories which do not exist
- in your new install.
-
-The procedure to migrate to Git is as follows. The idea is to switch without
-changing the version of Bugzilla you are using, to minimise the risk of
-conflict or problems. Any major upgrade can then happen as a separate step.
-
-Find Your Current Bugzilla Version
-==================================
-
-First, you need to find what version of Bugzilla you are using. It should be
-in the top right corner of the front page but, if not, open the file
-:file:`Bugzilla/Constants.pm` in your Bugzilla directory and search for
-:code:`BUGZILLA_VERSION`.
-
-.. include:: migrating-from-2.inc.rst
.. todo:: Need to incorporate the full reference, and link it properly from
the GUI. https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html
+ Turn this item into a bug after checkin.
Simple Search
=============
---------------
.. todo:: This needs rewriting for the new UI.
-
+ Turn this item into a bug after checkin.
+
The terms within a single row of a boolean chart are all
constraints on a single piece of data. If you are looking for
a bug that has two different people cc'd on it, then you need
================================
.. todo:: Looks like you can no longer do this from search results; is that right?
-
+ Turn this item into a bug after checkin.
+
You can add and remove tags from individual bugs, which let you find and
manage bugs more easily. Tags are per-user and so are only visible and editable
by the user who created them. You can then run queries using tags as a criteria,
.. _using:
-==============
-Using Bugzilla
-==============
+==========
+User Guide
+==========
.. toctree::
:maxdepth: 2
Bugzilla because the docs aren't always on a Bugzilla (e.g.
when they are on ReadTheDocs). Best solution is to port the
Markdown guide to ReST.
-
+ Turn this item into a bug after checkin.
+
To use the Markdown feature, make sure that :guilabel:`Enable Markdown
support for comments` is set to :guilabel:`on`
in your :ref:`user-preferences` and that you also check the :guilabel:`Use
projects / thirdparty / bugzilla.git / commitdiff
