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. -