You now need to decide what content type you want your template served as. If your content type is not there, add it. Remember the three- or four-letter tag assigned to your content type. This tag will be part of the template filename. There are a few templates you may be particularly interested in customizing for your installation. You may not wish to go to the effort of creating custom fields in Bugzilla, yet you want to make sure that each bug report contains a number of pieces of important information for which there is not a special field.
The bug entry system has been designed in an extensible fashion to enable you to add arbitrary HTML widgets, such as drop-down lists or textboxes, to the bug entry page and have their values appear formatted in the initial comment.
An example of this is the guided bug submission form. The code for this comes with the Bugzilla distribution as an example for you to copy. It can be found in the files create-guided.
A hidden field that indicates the format should be added inside the form in order to make the template functional. Its value should be the suffix of the template filename. For example, if the file is called create-guided. It needs a couple of lines of boilerplate at the top like this:. When a bug report is submitted, the initial comment attached to the bug report will be formatted according to the layout of this template.
This system allows you to gather structured data in bug reports without the overhead and UI complexity of a large number of custom fields. Navigation next previous Bugzilla 5.
Integration and Customization Guide ». The custom directory does not exist by default and must be created if you want to use it. You can use the hooks built into many of the templates to add or modify the UI from an extension. Hooks generally don't go away and have a stable interface. Write your template in whatever markup or text style is appropriate. The header includes the banner, which is what appears to users and is probably what you want to edit instead.
The default banner is reasonably barren, so you'll probably want to customize this to give your installation a distinctive look and feel. It is recommended you preserve the Bugzilla version number in some form so the version you are running can be determined, and users know what docs to read.
Editing this is another way to quickly get a distinctive look and feel for your Bugzilla installation. A hashref, where the keys are the "name" of the panel and the value is the Perl module representing that panel. For example, if the name is Auth , the value would be Bugzilla::Config::Auth. For your extension, the Perl module would start with Bugzilla::Extension::Foo , where "Foo" is the name of your Extension.
This is how you modify already-existing panels in the Parameters administrative interface. For example, if you wanted to add a new Auth method modifying Bugzilla::Config::Auth this is how you'd do it. A hashref, where the keys are lower-case panel "names" like auth , admin , etc. The hashref contains a single key, params. You can modify params and your changes will be reflected in the interface. Adding new keys to panels will have no effect. This happens right after an inbound email is converted into an Email::MIME object, but before we start parsing the email to extract field data.
This means the email has already been decoded for you. This lets you do things after the normal parsing of the email, such as sanitizing field data, changing the user account being used to file a bug, etc. A string representing the error code thrown by Bugzilla. This hash contains all the data passed to the error template. Its content depends on the error thrown. This happens at the end of "create" in Bugzilla::Group , after all other changes are made to the database.
The new Bugzilla::Group object that was just created. This happens at the end of "update" in Bugzilla::Group , after all other changes are made to the database. A flag that indicates whether or not checksetup is running in silent mode. If this is true, messages that are always printed by checksetup.
Allows for additional files and directories to be added to the list of files and directories already managed by checksetup. You will be able to also set permissions for the files and directories using this hook. You can also use this hook to create appropriate. Hash reference of files that are already present when your extension was installed but need to have specific permissions set.
Each file key points to another hash reference containing the following settings. Hash reference containing the name of each directory that will be created, pointing at its default permissions. Hash reference containing directories that we want to set the perms on, but not recurse through. These are directories not created in checksetup. Each directory key's value is the permissions to be set on the directory. Hash reference of directories that will have permissions set for each item inside each of the directories, including the directory itself.
Each directory key points to another hash reference containing the following settings. Hash reference of additional files to be created. Hash reference containing htaccess files to be created. You can set the permissions for the htaccess as well as the contents of the file. This happens at the very end of all the tables being updated during an installation or upgrade. If you need to modify your custom schema or add new columns to existing tables, do it here.
No params are passed. This is used to update the schema of the fielddefs table before any other schema changes take place. This hook should only be used for updating the schema of the fielddefs table. Do not modify any other table in this hook. This allows you to add tables to Bugzilla. Note that we recommend that you prefix the names of your tables with some word preferably the name of your Extension , so that they don't conflict with any future Bugzilla tables.
Bugzilla has a system - Bugzilla::JobQueue - for running jobs asynchronously, if the administrator has set it up. This hook allows the addition of mappings from job names to handler classes, so an extension can fire off jobs. This happens at the beginning of "create" in Bugzilla::Object. The name of the class that create was called on.
This sometimes occurs inside a database transaction. Called during "set" in Bugzilla::Object , before any actual work is done. You can use this to perform actions before a value is changed for specific fields on certain types of objects.
The object that set was called on. This hook allows you to add new "fields" to existing Bugzilla objects, that correspond to columns in their tables. For example, if you added an example column to the "bugs" table, you would have to also add an example field to the Bugzilla::Bug object in order to access that data via Bug objects.
Don't do anything slow inside this hook--it's called several times on every page of Bugzilla. The name of the class that this hook is being called on. This arrayref does not contain the standard column names--you cannot modify or remove standard object columns using this hook. Called at the end of "create" in Bugzilla::Object , after all other changes are made to the database. You can use this to run additional validation when creating an object.
A hashref. Called during "set" in Bugzilla::Object , after all the code of the function has completed so the value has been validated and the field has been set to the new value. You can use this to perform actions after a value is changed for specific fields on certain types of objects. The Bugzilla::Object which is being updated.
Called during "update" in Bugzilla::Object , after changes are made to the database, but while still inside a transaction. The object that update was called on. The fields that have been changed, in the same format that "update" in Bugzilla::Object returns. If you don't use this hook, then your custom columns won't be modified in the database by Bugzilla. The object that is about to be updated.
An arrayref. Add the string names of columns to this array to allow that column to be updated when update is called on the object. This arrayref does not contain the standard column names--you cannot stop standard columns from being updated by using this hook.
A hashref, where the keys are database columns and the values are subroutine references. You can add new validators or modify existing ones. User Interface Improvements There has been some work on the user interface for Bugzilla 3.
A re-designed "Format for Printing" page for bugs. Skins Bugzilla can have multiple "skins" installed, and users can pick between them. Unchangeable Fields Appear Unchangeable As long as you are logged in, when viewing a bug, if you cannot change a field, it will not look like you can change it. All Emails in Templates All outbound emails are now controlled by the templating system.
No More Double-Filed Bugs Users of Bugzilla will sometimes accidentally submit a bug twice, either by going back in their web browser, or just by refreshing a page.
Automatic Update Notification If you belong to the admin group, you will be notified when you log in if there is a new release of Bugzilla available to download. Welcome Page for New Installs When you log in for the first time on a brand-new Bugzilla installation, you will be presented with a page that describes where you should go from here, and what parameters you should set.
Other Enhancements and Changes These are either minor enhancements, or enhancements that have very short descriptions. There is now a user preference that will add you to the CC list of any bug you modify. Note that it's on by default. By default, comment fields will zoom large when you are typing in them, and become small when you move out of them. You can disable this in your user preferences.
You can hide obsolete attachments on a bug by clicking "Hide Obsolete" at the bottom of the attachment table. If a bug has flags set, and you move it to a different product that has flags with the same name, the flags will be preserved.
You now can't request a flag to be set by somebody who can't set it Bugzilla will throw an error if you try. You can look at an email to get an idea of what they contain. In addition to the old X-Bugzilla-Reason email header which tells you why you got an email, if you got an email because you were watching somebody, there is now an X-Bugzilla-Watch-Reason header that tells you who you were watching and what role they had. Of course, this only works for bugs in your Bugzilla installation.
If your installation has user watching enabled, you will now see the users that you can remove from your watch-list as a multi-select box, much like the current CC list. Previously it was just a text box. When a user creates their own account in Bugzilla, the account is now not actually created until they verify their email address by clicking on a link that is emailed to them. You can change a bug's resolution without reopening it.
When you view the dependency tree on a bug, resolved bugs will be hidden by default. In previous versions, resolved bugs were shown by default. When viewing bug activity, fields that hold bug numbers such as "Blocks" will have the bug numbers displayed as links to those bugs. When viewing the "Keywords" field in a bug list, it will be sorted alphabetically, so you can sanely sort a list on that field. In most places, the Version field is now sorted using a version-sort so 1.
Options for flags will only appear if you can set them. You can limit the product-related output of config. You can specify the argument more than once for multiple products.
0コメント