When you first run checksetup.pl after installing Bugzilla, it
will prompt you for the administrative username (email address) and
password for this "super user". If for some reason you delete
the "super user" account, re-running checksetup.pl will again prompt
you for this username and password.

If you wish to add more administrative users, add them to
the "admin" group and, optionally, edit the tweakparams, editusers,
creategroups, editcomponents, and editkeywords groups to add the
entire admin group to those groups (which is the case by default).

If you have "editusers" privileges or if you are allowed
to grant privileges for some groups, the "Users" link
appears in the footer.

The first screen you get is a search form to search for existing user
accounts. You can run searches based either on the ID, real name or
login name (i.e. the email address in most cases) of users. You can
search in different ways the listbox to the right of the text entry
box. You can match by case-insensitive substring (the default),
regular expression, or a reverse regular expression
match, which finds every user name which does NOT match the regular
expression.

You can also restrict your search to users being in some specific group.
By default, the restriction is turned off. Then you get a list of
users matching your criteria, and clicking their login name lets you
edit their properties.

By default, users can create their own user accounts by clicking the
"New Account" link at the bottom of each page (assuming
they aren't logged in as someone else already). If you want to disable
this self-registration, or if you want to restrict who can create his
own user account, you have to edit the "createemailregexp"
parameter in the "Configuration" page, see
Section 3.1.

Users with "editusers" privileges, such as administrators,
can create user accounts for other users:

After logging in, click the "Users" link at the footer of
the query page, and then click "Add a new user".

Fill out the form presented. This page is self-explanatory.
When done, click "Submit".

Adding a user this way will not
send an email informing them of their username and password.
While useful for creating dummy accounts (watchers which
shuttle mail to another system, for instance, or email
addresses which are a mailing list), in general it is
preferable to log out and use the "New Account"
button to create users, as it will pre-populate all the
required fields and also notify the user of her account name
and password.

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
login names themselves (to any valid email address).

Real Name: The user's real name. Note that
Bugzilla does not require this to create an account.

Password:
You can change the user's password here. Users can automatically
request a new password, so you shouldn't need to do this often.
If you want to disable an account, see Disable Text below.

Disable Text:
If you type anything in this box, including just a space, the
user is prevented from logging in, or making any changes to
bugs via the web interface.
The HTML you type in this box is presented to the user when
they attempt to perform these actions, and should explain
why the account was disabled.

Users with disabled accounts will continue to receive
mail from Bugzilla; furthermore, they will not be able
to log in themselves to change their own preferences and
stop it. If you want an account (disabled or active) to
stop receiving mail, add the account name (one account
per line) to the file data/nomail.

Even users whose accounts have been disabled can still
submit bugs via the e-mail gateway, if one exists.
The e-mail gateway should not be
enabled for secure installations of Bugzilla.

Don't disable all the administrator accounts!

<groupname>:
If you have created some groups, e.g. "securitysensitive", then
checkboxes will appear here to allow you to add users to, or
remove them from, these groups.

canconfirm:
This field is only used if you have enabled the "unconfirmed"
status. If you enable this for a user,
that user can then move bugs from "Unconfirmed" to a "Confirmed"
status (e.g.: "New" status).

creategroups:
This option will allow a user to create and destroy groups in
Bugzilla.

editbugs:
Unless a user has this bit set, they can only edit those bugs
for which they are the assignee or the reporter. Even if this
option is unchecked, users can still add comments to bugs.

editcomponents:
This flag allows a user to create new products and components,
as well as modify and destroy those that have no bugs associated
with them. If a product or component has bugs associated with it,
those bugs must be moved to a different product or component
before Bugzilla will allow them to be destroyed.

editkeywords:
If you use Bugzilla's keyword functionality, enabling this
feature allows a user to create and destroy keywords. As always,
the keywords for existing bugs containing the keyword the user
wishes to destroy must be changed before Bugzilla will allow it
to die.

editusers:
This flag allows a user to do what you're doing right now: edit
other users. This will allow those with the right to do so to
remove administrator privileges from other users or grant them to
themselves. Enable with care.

<productname>:
This allows an administrator to specify the products
in which a user can see bugs. If you turn on the
"makeproductgroups" parameter in
the Group Security Panel in the Parameters page,
then Bugzilla creates one group per product (at the time you create
the product), and this group has exactly the same name as the
product itself. Note that for products that already exist when
the parameter is turned on, the corresponding group will not be
created. The user must still have the "editbugs"
privilege to edit bugs in these products.

If the "allowuserdeletion" parameter is turned on, see
Section 3.1, then you can also delete user accounts.
Note that this is most of the time not the best thing to do. If only
a warning in a yellow box is displayed, then the deletion is safe.
If a warning is also displayed in a red box, then you should NOT try
to delete the user account, else you will get referential integrity
problems in your database, which can lead to unexpected behavior,
such as bugs not appearing in bug lists anymore, or data displaying
incorrectly. You have been warned!