|
|
| Line 1: |
Line 1: |
| ==Checking Syntax==
| | See http://bugzilla.readthedocs.org/en/latest/integrating/extensions.html . |
| | |
| It's not immediately obvious how to check the syntax of your extension's modules. Running checksetup.pl might do some of it, but the errors aren't necessarily massively informative.
| |
| | |
| perl -Mlib=lib -MBugzilla -e 'BEGIN { Bugzilla->extensions; } use Bugzilla::Extension::ExtensionName::Class;'
| |
| | |
| (run from BUGZILLA_HOME) will do the trick.
| |
| | |
| ==Adding New Fields To Bugs==
| |
| | |
| To add new fields to a bug, you need to do the following:
| |
| | |
| * Add an <tt>install_update_db</tt> hook to add the fields by calling <tt>Bugzilla::Field->create</tt> (only if the field doesn't already exist). Here's what it might look like for a single field:
| |
| | |
| my $field = new Bugzilla::Field({ name => $name });
| |
| return if $field;
| |
|
| |
| $field = Bugzilla::Field->create({
| |
| name => $name,
| |
| description => $description,
| |
| type => $type, # From list in Constants.pm
| |
| enter_bug => 0,
| |
| buglist => 0,
| |
| custom => 1,
| |
| });
| |
| | |
| * Push the name of the field onto the relevant arrays in the <tt>bug_columns</tt> and <tt>bug_fields</tt> hooks.
| |
| * If you want direct accessors, or other functions on the object, you need to add a BEGIN block to your Extension.pm:
| |
| | |
| BEGIN {
| |
| *Bugzilla::Bug::is_foopy = \&_bug_is_foopy;
| |
| }
| |
|
| |
| ...
| |
|
| |
| sub _bug_is_foopy {
| |
| return $_[0]->{'is_foopy'};
| |
| }
| |
| | |
| * You don't have to change <tt>Bugzilla/DB/Schema.pm</tt>.
| |
| | |
| ==Adding New Fields To Other Things==
| |
| | |
| If you are adding the new fields to an object other than a bug, you need to go a bit lower-level.
| |
| | |
| * In <tt>install_update_db</tt>, use <tt>bz_add_column</tt> instead
| |
| * Push on the columns in <tt>object_columns</tt> and <tt>object_update_columns</tt> instead of <tt>bug_columns</tt>.
| |
| * Add validators for the values in <tt>object_validators</tt>
| |
| | |
| The process for adding accessor functions is the same.
| |
| | |
| ==Adding Configuration Panels==
| |
| | |
| As well as using the <tt>config_add_panels</tt> hook, you will need a template to define the UI strings for the panel. See the templates in <tt>template/en/default/admin/params</tt> for examples, and put your own template in <tt>template/en/default/admin/params</tt> in your extension's directory.
| |
| | |
| ==Adding User Preferences==
| |
| | |
| To add a new user preference:
| |
| | |
| * Call <tt>add_setting('setting_name', ['some_option', 'another_option'], 'some_option')</tt> in the <tt>install_before_final_checks</tt> hook. (The last parameter is the name of the option which should be the default.)
| |
| | |
| * Add descriptions for the identifiers for your setting and choices (setting_name, some_option etc.) to the hash defined in <tt>global/setting-descs.none.tmpl</tt>. Do this in a hook: <tt>hook/global/setting-descs-settings.none.tmpl</tt>. Your code can see the hash variable; just set more members in it.
| |
| | |
| * To change behaviour based on the setting, reference it in templates using <tt>[% user.settings.setting_name.value %]</tt>. Reference it in code using <tt>$user->settings->{'setting_name'}->{'value'}</tt>. The value will be one of the option tag names (e.g. some_option).
| |