User administration is one of the easiest parts of Bugzilla. + Keeping it from getting out of hand, however, can become a challenge. +
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. +
Tip: 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)"; +
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!
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. +
Tip: 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". +
Note: 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. +
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. +
| Warning |
Don't disable your own administrative account, or you will hate life! + |
Here I will attempt to describe the function of each option on the user edit 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. +
Tip: 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, Q/A 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 Q/A contact, but will receive them if she is on the CC list. +
Note: 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, Q/A 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. +
| Warning |
Don't disable the administrator account! |
Note: 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 (ergo: "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. +
Note: 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. +