You should explicitly add group to project to exclude other users (non-members) from accessing project.ġ. by default project has no group assigned - this means world access to project. Note: by default bug reporting user accounts will have access to all other projects, unless these projects has group with "Entry" assigned. Setup project access rights - limit actions to members of auto-reporting group:ĭetailed view of group access rights to the project When reporting - version are taken from file's version information, so you must supply the corresponding version in description of your. Note: if you don't want to edit project each time you release new version - you can create versions for the future use. However, it's recommended to use four-number versions with optional textual description, for example: "1.0.1.0" and "1.0.1.0 beta 3". When you release update: "YourSoftware 1.0.1.0" - you need to add "1.0.1.0" version. when you release (publish on site, send to custom, etc) "YourSoftware 1.0.0.0" - you need to create "1.0.0.0" version. You should create new version for each release of your software. If you don't use versioning (highly unrecommended) - you can skip this step.
BUGZILLA CREATE NEW PRODUCT SOFTWARE
Typically component is used for identification of the part of your software product.ģ. If you don't need components - create something like "General" or "unspecified" component. You may create several projects - one for each of your software products.Ģ. (Administration/Products) Create project for your software product (projects are called products in BugZilla). Repeat this for all bug reporting accounts.ġ. Suggested group setup for bug reporting user accounts Open bug reporting user account and include it into a bug reporting group: Include all necessary users to that group.Ħ. You may want to exclude your bug reporting account from "editbugs" - to do this, edit "editbugs" group and remove default regular expression ".*". Note: by default "editbugs" group is assigned to all users. You can also create a new group of users and include all bug-reporting user accounts into that group (Administration/Groups):Ĭreating new user group for bug reporting Repeat these steps for each bug submitter user account which you've created.ĥ. Now, log off and log in again as administrator. You will need to enter it into EurekaLog settings later.Ĥ. Once API key was created - select it and copy to buffer. (Optional, but strongly recommended only for latest BugZilla versions) Go to Preferences / API Keys and create new API token:Ĭreating new API token for bug reporter account Setting properties of submitter account - e-mail notificationsģ. Setting properties of submitter account - general Go to "Preferences" and clear e-mail notifications, set default settings and switch language to "English": Create it with disabled e-mail notifications:Ģ. (Administration/Users) Create new non-admin user account for bug report submission. Create any other additional fields as you need/like (you can submit values for custom fields at run-time via OnCustomWebFieldsRequest event).ġ. Suggested setup for "e-mail" and "BugID" fieldsĢ. We strongly recommend to create at least "Count" field. Do not use "Bug ID" field type for "BugID" field.
Other suggested custom fields are: "BugID" (to store BugID and search issues) and "e-mail" ("user e-mail", which is typically entered in MS Classic error dialog). Its type should be "Integer" field name can be arbitrary, like "Occurrences", "Bug count", "Popularity", "Incidents", "Hit Count", etc. Most important field is "Count" - to store number of sent/occurred problems. (Administration/Custom Fields) Create custom field to improve usefulness of EurekaLog. Note: You can use BugZilla as external bug tracker for GitLab.ġ. It's recommendation, but it's not necessary to be absolutely like that. Please note that all actions below are just examples. Maintaining project (regularly or from time to time)
0 kommentar(er)
