4.2. User Administration
User administration is one of the easiest parts of Bugzilla. + Keeping it from getting out of hand, however, can become a + challenge. +
4.2.1. Creating the Default User
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 were to 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, you must use the + MySQL interface. Run "mysql" from the command line, and use + these commands ("mysql>" denotes the mysql prompt, not + something you should type in): + mysql> use bugs; + mysql> update profiles set + groupset=0x7ffffffffffffff where login_name = "(user's + login name)"; + |
4.2.2. Managing Other Users
4.2.2.1. Logging In
Open the index.html page for your Bugzilla installation + in your browser window. +
Click the "Query Existing Bug Reports" link. +
Click the "Log In" link at the foot of the page. +
Type your email address, and the password which was + emailed to you when you created your Bugzilla account, + into the spaces provided. +
Congratulations, you are logged in!
4.2.2.2. Creating new users
Your users can create their own user accounts by clicking + the "New Account" link at the bottom of each page. However, + should you desire to create user accounts ahead of time, + here is how you do it. +
After logging in, click the "Users" link at the footer + of the query page. +
To see a specific user, type a portion of their login + name in the box provided and click "submit". To see all + users, simply click the "submit" button. You must click + "submit" here to be able to add a new user. +
More functionality is available via the list on the + right-hand side of the text entry box. You can match + what you type as a case-insensitive substring (the + default) of all users on your system, a case-sensitive + regular expression (please see the "man regexp" manual + page for details on regular expression syntax), or a + reverse regular expression match, + where every user name which does NOT match the regular + expression is selected. +
Click the "Add New User" link at the bottom of the user + list +
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. 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. +
4.2.2.3. Disabling Users
I bet you noticed that big "Disabled Text" entry box + available from the "Add New User" screen, when you edit an + account? By entering any text in this box and selecting + "submit", you have prevented the user from using Bugzilla + via the web interface. Your explanation, written in this + text box, will be presented to the user the next time she + attempts to use the system. +
Don't disable your own administrative account, or you + will hate life! + |
4.2.2.4. Modifying Users
Here I will attempt to describe the function of each option + on the Edit User screen. +
Login Name: This is generally the + user's email address. However, if you have edited your + system parameters, this may just be the user's login + name or some other identifier. +
+For compatability reasons, you should probably stick + with email addresses as user login names. It will + make your life easier. +
Real Name: Duh! +
Password: You will only see + asterisks in versions of Bugzilla newer than 2.10 or + early 2.11. You can change the user password here. +
Email Notification: You may choose + from one of three options: +
All qualifying bugs except those which I change: + The user will be notified of any change to any bug + for which she is the reporter, assignee, QA + Contact, CC recipient, or "watcher". +
Only those bugs which I am listed on the CC line: + The user will not be notified of changes to bugs + where she is the assignee, reporter, or QA + Contact, but will receive them if she is on the CC + list. +
+She will still receive whining cron emails if + you set up the "whinemail" feature. +
All Qualifying Bugs: This + user is a glutton for punishment. If her name is + in the reporter, QA Contact, CC, assignee, or is a + "watcher", she will get email updates regarding + the bug. +
Disable Text: If you type anything + in this box, including just a space, the user account is + disabled from making any changes to bugs via the web + interface, and what you type in this box is presented as + the reason. +
+Don't disable the administrator account!
+As of this writing, the user can still submit bugs + via the e-mail gateway, if you set it up, despite + the disabled text field. The e-mail gateway should + not be enabled for secure + installations of Bugzilla. +
CanConfirm: This field is only used + if you have enabled "unconfirmed" status in your + parameters screen. If you enable this for a user, that + user can then move bugs from "Unconfirmed" to + "Confirmed" status (e.g.: "New" status). Be judicious + about allowing users to turn this bit on for other + users. +
Creategroups: This option will + allow a user to create and destroy groups in Bugzilla. + Unless you are using the Bugzilla GroupSentry security + option "usebuggroupsentry" in your parameters, this + setting has no effect. +
Editbugs: Unless a user has this + bit set, they can only edit those bugs for which they + are the assignee or the reporter. +
+Leaving this option unchecked does not prevent users + from adding comments to a bug! They simply cannot + change a bug priority, severity, etc. unless they + are the assignee or reporter. +
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. The name of a product or + component can be changed without affecting the + associated bugs, but it tends to annoy the hell out of + your users when these change a lot. +
Editkeywords: If you use Bugzilla's + keyword functionality, enabling this feature allows a + user can 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. You must be very careful about + creating too many new keywords if you run a very large + Bugzilla installation; keywords are global variables + across products, and you can often run into a phenomenon + called "keyword bloat". This confuses users, and then + the feature goes unused. +
Editusers: This flag allows a user + do what you're doing right now: edit other users. This + will allow those with the right to do so to remove + administrator priveleges from other users or grant them + to themselves. Enable with care. +
PRODUCT: PRODUCT bugs access. This + allows an administrator, with product-level granularity, + to specify in which products a user can edit bugs. The + user must still have the "editbugs" privelege to edit + bugs in this area; this simply restricts them from even + seeing bugs outside these boundaries if the + administrator has enabled the group sentry parameter + "usebuggroupsentry". Unless you are using bug groups, + this option has no effect. +