Abstract
git config --global user.name "John Smith" git config --global user.email "jsmith@mantisbt.org"
git config --global color.diff "auto" git config --global color.status "auto" git config --global color.branch "auto" git config --global alias.st "status" git config --global alias.di "diff" git config --global alias.co "checkout" git config --global alias.ci "commit"
git@github.com:mantisbt/mantisbt.git. Alternatively, an HTTPS link can be used as well, in which case you will have to provide your GitHub User ID and password when Git requests it: https://github.com/mantisbt/mantisbt.git.
Note
git@github.com:mantisbt/mantisbt.git (SSH). or https://github.com/mantisbt/mantisbt.git (HTTPS) will always be read-only.
git@github.com:MyGithubId/mantisbt.git. or https://github.com/MyGithubId/mantisbt.git
git clone YourCloneURLAfter performing the cloning operation, you should end up with a new directory in your workspace,
mantisbt/, containing the MantisBT repository with a remote named origin pointing to your Clone URL.
composer install
Warning
/vendor folder, which will then cause errors when running MantisBT.
remote for MantisBT's official repository, which will make it easier to keep your repository up-to-date.
git remote add --tags upstream git://github.com/mantisbt/mantisbt.git
master, which is the latest development version of MantisBT. If you are planning to work with stable release or other development branches, you will need to set up local tracking branches in your repository.
master-1.3.x.
git checkout -b master-1.3.x origin/master-1.3.x
Note
/library rather than a submodule:
$ git checkout old_branch error: The following untracked working tree files would be overwritten by checkout (list of files) Aborting
/tmp:
sed -rn "s/^.*path\s*=\s*(.*)$/\1/p" .gitmodules |xargs -I{} mv -v {} /tmp
git checkout old_branch
git checkout -f old_branch git clean -df
git submodule update
/tmp back into the empty directories, e.g.
sed -rn "s/^.*path\s*=\s*(.*)$/\1/p" .gitmodules |xargs -n 1 basename |xargs -I{} mv -v /tmp/{} library
master and master-1.3.x.
git fetch origin
Note
git fetch upstream
git checkout BranchName git rebase
git checkout master git pull --rebase
master is to use the rebase command. This will append all of your feature branch commits into a linear history after the last commit on the master branch.
git rebase master feature
Note
git checkout feature git fetch remote/feature git rebase remote/feature
master.
merge the current master branch, which will create a special "merge commit" in the branch history, causing a logical "split" in commit history where your branch started and joining at the merge. These merge commits are generally disliked, because they can crowd commit history, and because the history is no longer linear. They will be dealt with during the submission process (see Section 1.5, “Running PHPUnit tests”).
git checkout feature git merge master
tests directory. You are encouraged to add your own tests for the patches you are submitting, but please remember that your changes must not break existing tests.
bootstrap.php file. The boostrap.php.sample file contains the settings you will need to adjust to run all the tests.
phing test
bootstrap.php file to point to your local installation.
config_inc.php to enable all the features tested using the SOAP tests. The simplest way to do that is to run all the tests once and adjust it based on the skipped tests.
Note
git fetch upstream git rebase upstream/master MyBranch
git push origin MyBranch
master as described in Section 1.4, “Preparing Feature Branches” currently checked out, generating a formatted patch set should be relatively straightforward, using an appropriate filename as the target of the patch set:
git format-patch --binary --stdout origin/master..HEAD > feature_branch.patch
git am --signoff feature_branch.patch
git@githosting.com:contrib.git, kept it up-to-date with MantisBT's official repository, and that you have pushed your feature branch MyBranch to it.
git request-pull origin/master git@githosting.com:contrib.git MyBranch
git remote add feature git@githosting.com:contrib.git git checkout -b MyBranch feature/MyBranch
master:
git rebase master feature git checkout master git merge --no-ff feature
core/event_api.php in the codebase.
Declaring Events
When declaring events, the only information needed is the event name and event type. Events can be declared alone using the form:event_declare( $name, $type=EVENT_TYPE_DEFAULT );or they can be declared in groups using key/value pairs of name => type relations, stored in a single array, such as:$events = array( $name_1 => $type_1, $name_2 => $type_2, ... ); event_declare_many( $events );
Hooking Events
Hooking events requires knowing the name of an already-declared event, and the name of the callback function (and possibly associated plugin) that will be hooked to the event. If hooking only a function, it must be declared in the global namespace.event_hook( $event_name, $callback, [$plugin] );In order to hook many functions at once, using key/value pairs of name => callback relations, in a single array:$events = array( $event_1 => $callback_1, $event_2 => $callback_2, ... ); event_hook( $events, [$plugin] );
Signalling Events
When signalling events, the event type of the target event must be kept in mind when handling event parameters and return values. The general format for signalling an event uses the following structure:$value = event_signal( $event_name, [ array( $param, ... ), [ array( $static_param, ... ) ] ] );Each type of event (and individual events themselves) will use different combinations of parameters and return values, so perusing Chapter 5, Events Reference is recommended for determining the unique needs of each event when signalling and hooking them.
EVENT_TYPE_EXECUTE
This is the simplest event type, meant for initiating basic hook execution without needing to communicate more than a set of immutable parameters to the event, and expecting no return of data.These events only use the first parameter array, and return values from hooked functions are ignored. Example usage:event_signal( $event_name, [ array( $param, ... ) ] );
EVENT_TYPE_OUTPUT
This event type allows for simple output and execution from hooked events. A single set of immutable parameters are sent to each callback, and the return value is inlined as output. This event is generally used for an event with a specific purpose of adding content or markup to the page.These events only use the first parameter array, and return values from hooked functions are immediately sent to the output buffer via 'echo'. Another parameter$formatcan be used to model how the results are printed. This parameter can be either:
EVENT_TYPE_CHAIN
This event type is designed to allow plugins to successively alter the parameters given to them, such that the end result returned to the caller is a mutated version of the original parameters. This is very useful for such things as output markup parsers.The first set of parameters to the event are sent to the first hooked callback, which is then expected to alter the parameters and return the new values, which are then sent to the next callback to modify, and this continues for all callbacks. The return value from the last callback is then returned to the event signaller.This type allows events to optionally make use of the second parameter set, which are sent to every callback in the series, but should not be returned by each callback. This allows the signalling function to send extra, immutable information to every callback in the chain. Example usage:$value = event_signal( $event_name, $param, [ array( $static_param, ... ) ] );
EVENT_TYPE_FIRST
The design of this event type allows for multiple hooked callbacks to 'compete' for the event signal, based on priority and execution order. The first callback that can satisfy the needs of the signal is the last callback executed for the event, and its return value is the only one sent to the event caller. This is very useful for topics like user authentication.These events only use the first parameter array, and the first non-null return value from a hook function is returned to the caller. Subsequent callbacks are never executed. Example usage:$value = event_signal( $event_name, [ array( $param, ... ) ] );
EVENT_TYPE_DEFAULT
This is the fallback event type, in which the return values from all hooked callbacks are stored in a special array structure. This allows the event caller to gather data separately from all events.These events only use the first parameter array, and return values from hooked functions are returned in a multi-dimensional array keyed by plugin name and hooked function name. Example usage:$values = event_signal( $event_name, [ array( $param, ... ) ] );
MantisPlugin class as defined in core/classes/MantisPlugin.php. Each plugin may define information about itself, as well as a list of conflicts and dependencies upon other plugins. There are many methods defined in the MantisPlugin class that may be used as convenient places to define extra behaviors, such as configuration options, event declarations, event hooks, errors, and database schemas. Outside a plugin's core class, there is a standard method of handling language strings, content pages, and files.
Example.
mantis_plugin_Example_foo_table.
Example/ Example.php
Warning
example will not work.
MantisPlugin class, which must be named in the form of %Basename%Plugin, which for our purpose becomes ExamplePlugin.
MantisPlugin declares the register() method as abstract, our plugin must implement that method before PHP will find it semantically valid. This method is meant for one simple purpose, and should never be used for any other task: setting the plugin's information properties including the plugin's name, description, version, and more. Please refer to Section 4.2.2, “Properties” below for details about available properties.
register() method, and sets at least the name and version properties, it is then considered a "complete" plugin, and can be loaded and installed within MantisBT's plugin manager. At this stage, our Example plugin, with all the possible plugin properties set at registration, looks like this:
Example/Example.php
<?php
class ExamplePlugin extends MantisPlugin {
function register() {
$this->name = 'Example Plugin'; # Proper name of plugin
$this->description = 'Example Plugin from MantisBT Developers Guide';
# Short description of the plugin
$this->page = ''; # Default plugin page
$this->version = '2.0'; # Plugin version string
$this->requires = array( # Plugin dependencies
'MantisCore' => '2.0', # Should always depend on an appropriate
# version of MantisBT
);
$this->author = 'MantisBT Team'; # Author/team name
$this->contact = 'mantisbt-dev@lists.sourceforge.net';
# Author/team e-mail address
$this->url = 'https://mantisbt.org'; # Support webpage
}
}
Note
MantisCore basename can be used to specify the minimum requirement for MantisBT core.
<' will allow the plugin to specify the highest version (non-inclusive) up to which the required dependency is supported.
Note
'<2').
$this->requires = array( 'MantisCore' => '1.3.1' );The plugin is compatible with MantisBT >= 1.3.1 and < 2.0.0 - note that the maximum version (
<2) was added by the system.
$this->requires = array( 'MantisCore' => '2.0' );The plugin is compatible with MantisBT >= 2.0 and < 3.0 (the latter is implicit); code supporting older releases (e.g. 1.3) must be maintained separately (i.e. in a different branch).
$this->requires = array( 'MantisCore' => '< 3.1' );The plugin is compatible up to MantisBT 3.1 (not inclusive).
$this->requires = array( 'MantisCore' => '1.3, < 4.0' );The plugin is compatible with MantisBT >= 1.3 and < 4.0.
requires above for details on how to specify versions.
pages/ directory,
.php file extension
plugin_page() should be used. Our Example plugin will create a page named foo.php, which can then be accessed via plugin_page.php?page=Example/foo:
Example/pages/foo.php
<?php
layout_page_header();
layout_page_begin();
?>
<p>
Here is a link to <a href="<?php echo plugin_page( 'foo' ) ?>">page foo</a>.
</p>
<?php
layout_page_end();
Note
layout_page_begin() and layout_page_end() trigger the standard MantisBT header and footer portions, respectively, which also displays things such as the menus and triggers other layout-related events. layout_page_header() pulls in the CSS classes for alternating row colors in the table, amongst other things.
files/ directory, and can only contain a single period in the name. The file's URI is generated with the plugin_file() function.
Example/files/foo.css
p.foo {
color: red;
}
Example/pages/foo.php
...
<link rel="stylesheet" type="text/css" href="<?php echo plugin_file( 'foo.css' ) ?>" />
<p class="foo">
Our custom stylesheet paints this text red.
</p>
Note
plugin_page() expects only the page's name without the extension, plugin_file() on the other hand requires the entire filename, so that it can distinguish e.g. between foo.css and a potential image file called foo.png.
Example/ Example.php pages/ foo.php files/ foo.css
events() method of your plugin class, and return an associative array with event names as the key, and the event type as the value.
Example/Example.php
<?php
class ExamplePlugin extends MantisPlugin {
...
function events() {
return array(
'EVENT_EXAMPLE_FOO' => EVENT_TYPE_EXECUTE,
'EVENT_EXAMPLE_BAR' => EVENT_TYPE_CHAIN,
);
}
}
Note
foo() and a bar() methods in our plugin class, then hook them to the events we declared earlier. We'll also hook the standard EVENT_MENU_MAIN event, to link the custom page we created in Section 4.2.3, “Pages and Files”.
Example/Example.php
<?php
class ExamplePlugin extends MantisPlugin {
...
function hooks() {
return array(
'EVENT_MENU_MAIN' => 'menu',
'EVENT_EXAMPLE_FOO' => 'foo',
'EVENT_EXAMPLE_BAR' => 'bar',
);
}
}
$p_event parameter, which contains the event name triggering the method (allowing a single method to respond to multiple events). The bar() method also accepts and returns a second parameter, in order to match the expectations of chained events.
Example/Example.php
<?php
class ExamplePlugin extends MantisPlugin {
...
function menu() {
$t_menu[] = array(
'title' => $this->name,
'url' => plugin_page( 'foo' ),
'access_level' => ANYBODY,
'icon' => 'fa-smile-o'
);
return $t_menu;
}
function foo( $p_event ) {
echo 'In method foo(). ';
}
function bar( $p_event, $p_chained_param ) {
return str_replace( 'foo', 'bar', $p_chained_param );
}
}
Example/pages/foo.php
...
<p>
Custom event hooks:
<?php
event_signal( 'EVENT_EXAMPLE_FOO' );
$t_string = 'A sentence with the word "foo" in it.';
$t_new_string = event_signal( 'EVENT_EXAMPLE_BAR', array( $t_string ) );
echo $t_new_string;
?>
</p>
foo() method will execute and echo a string. After that, the second event "bar" is signaled, and the page passes a string parameter; the plugin's bar() gets the string and replaces any instance of "foo" with "bar", and returns the resulting string. If any other plugin had hooked the event, that plugin could have further modified the new string from the Example plugin, or vice versa, depending on the loading order of plugins. The page then echos the modified string that was returned from the event.
config() method on your plugin class, your plugin can return an associative array of configuration options, with the option name as the key, and the default option as the array value. Our Example plugin will declare an option "foo_or_bar", with a default value of "foo":
Example/Example.php
<?php
class ExamplePlugin extends MantisPlugin {
...
function config() {
return array(
'foo_or_bar' => 'foo',
);
}
}
plugin_config_get() function, and can be set to a modified value in the database using plugin_config_set(). With these functions, the config option is prefixed with the plugin's name, in an attempt to automatically avoid conflicts in naming.
config.php, and handling the form on a separate config_update.php page that will modify the value in the database, and redirect back to the config page, just like any other form and action page in MantisBT:
Note
Example/pages/config.php
<?php
$t_foo_or_bar = plugin_config_get( 'foo_or_bar' );
?>
<form action="<?php echo plugin_page( 'config_update' )?>" method="post">
<?php echo form_security_field( 'plugin_Example_config_update' ) ?>
<label>
Foo or Bar?
<input name="foo_or_bar" value="<?php echo string_attribute( $t_foo_or_bar ) ?>" />
</label>
<br>
<label>
Reset
<input type="checkbox" name="reset" />
</label>
<br>
<input type="submit" />
</form>
Example/pages/config_update.php
<?php
form_security_validate( 'plugin_Example_config_update' );
$f_foo_or_bar = gpc_get_string( 'foo_or_bar' );
$f_reset = gpc_get_bool( 'reset', false );
form_security_purge( 'plugin_Example_config_update' );
if( $f_reset ) {
plugin_config_delete( 'foo_or_bar' );
} elseif( $f_foo_or_bar == 'foo' || $f_foo_or_bar == 'bar' ) {
plugin_config_set( 'foo_or_bar', $f_foo_or_bar );
} else {
error_parameters( 'foo_or_bar', string_attribute( $f_foo_or_bar ) );
trigger_error( ERROR_CONFIG_OPT_INVALID, ERROR );
}
print_successful_redirect( plugin_page( 'config', true ) );
Note
form_security_*() functions are part of the Form API, and prevent CSRF attacks against forms that make changes to the system.
register() method, which will turn the Plugin's name into an hyperlink.
Example/Example.php
function register() {
...
$this->page = 'config'; # Default plugin page
lang/ directory, and named the same as the core language files. Strings specific to the plugin should be "namespaced" in a way that will minimize any risk of collision. Translating the plugin to other languages already supported by MantisBT is then as simple as creating a new strings file with the localized content; the MantisBT core will find and use the new language strings automatically.
Example/lang/strings_english.txt
<?php
$s_plugin_Example_title = "Example Plugin";
$s_plugin_Example_description = "Example Plugin from MantisBT Developers Guide";
$s_plugin_Example_configuration = "Configuration";
$s_plugin_Example_foo_or_bar = "Foo or Bar?";
$s_plugin_Example_reset = "Reset Value";
plugin_lang_get() API function, replacing the hardcoded text and adding page title:
Example/Example.php
function register() {
...
$this->description = plugin_lang_get( 'title' );
Example/pages/foo.php
<?php
layout_page_header( plugin_lang_get( 'title' ) );
layout_page_begin();
?>
...
Example/pages/config.php
<?php
layout_page_header( plugin_lang_get( 'title' ) );
layout_page_begin();
$t_foo_or_bar = plugin_config_get( 'foo_or_bar' );
?>
<form action="<?php echo plugin_page( 'config_update' )?>" method="post">
<?php echo form_security_field( 'plugin_Example_config_update' ) ?>
<label>
<?php echo plugin_lang_get( 'foo_or_bar' ) ?>
<input name="foo_or_bar" value="<?php echo string_attribute( $t_foo_or_bar ) ?>" />
</label>
<br>
<label>
<?php echo plugin_lang_get( 'reset' ) ?>
<input type="checkbox" name="reset" />
</label>
<br>
<button type="submit"><?php echo lang_get( 'change_configuration' )?></button>
</form>
Note
helper_alternate_rows() API function.
Example/pages/config.php
<?php
layout_page_header( plugin_lang_get( 'title' ) );
layout_page_begin();
$t_foo_or_bar = plugin_config_get( 'foo_or_bar' );
?>
<div class="col-md-12 col-xs-12">
<div class="space-10"></div>
<div class="form-container">
<form action="<?php echo plugin_page( 'config_update' ) ?>" method="post">
<?php echo form_security_field( 'plugin_Example_config_update' ) ?>
<div class="widget-box widget-color-blue2">
<div class="widget-header widget-header-small">
<h4 class="widget-title lighter">
<?php
print_icon( 'fa-text-width', 'ace-icon' );
echo " ";
echo plugin_lang_get( 'title') . ': '
. plugin_lang_get( 'configuration' );
?>
</h4>
</div>
<div class="widget-body">
<div class="widget-main no-padding table-responsive">
<table class="table table-bordered table-condensed table-striped">
<tr>
<th class="category">
<label for="foo_or_bar">
<?php echo plugin_lang_get( 'foo_or_bar' ) ?>
</label>
</th>
<td>
<input type="text" id="foo_or_bar" name="foo_or_bar"
value="<?php echo string_attribute( $t_foo_or_bar ) ?>"
/>
</td>
</tr>
<tr>
<th class="category">
<label for="reset">
<?php echo plugin_lang_get( 'reset' ) ?>
</label>
</th>
<td>
<input type="checkbox" id="reset" name="reset" class="ace" />
<span class="lbl"> </span>
</td>
</tr>
</table>
</div>
<div class="widget-toolbox padding-8 clearfix">
<button class="btn btn-primary btn-white btn-round">
<?php echo lang_get( 'change_configuration' )?>
</button>
</div>
</div>
</div>
</form>
</div>
</div>
<?php
layout_page_end();
core/plugin_api.php in the codebase.
EVENT_EXAMPLE (Default)
This is an example event description.Parameters
Return Value
EVENT_PLUGIN_INIT (Execute)
This event is triggered by the MantisBT plugin system after all registered and enabled plugins have been initialized (theirinit()functions have been called). This event should always be the first event triggered for any page load. No parameters are passed to hooked functions, and no return values are expected.This event is the first point in page execution where all registered plugins are guaranteed to be enabled (assuming dependencies and such are met). At any point before this event, any or all plugins may not yet be loaded. Note that the core system has not yet completed the bootstrap process when this event is signalled.Suggested uses for the event include:
EVENT_CORE_HEADERS (Execute)
This event is triggered by the MantisBT bootstrap process just before emitting the headers. This enables plugins to emit their own headers or use API that enables tweaking values of headers emitted by core. An example, of headers that can be tweaked is Content-Security-Policy header which can be tweaked using http_csp_*() APIs.
EVENT_CORE_READY (Execute)
This event is triggered by the MantisBT bootstrap process after all core APIs have been initialized, including the plugin system, but before control is relinquished from the bootstrap process back to the originating page. No parameters are passed to hooked functions, and no return values are expected.This event is the first point in page execution where the entire system is considered loaded and ready.
EVENT_REST_API_ROUTES (Execute)
This event is triggered by MantisBT to enable plugins to register their own routes to be accessible via the REST API. All APIs belonging to a plugin named 'Example', MUST live under 'https://.../api/rest/plugins/Example/'. The route registration is done using the Slim Framework app instance that is passed as a parameter. A route group should be used to include all routes for the plugin. The name of the route group should be retrieved via calling plugin_route_group(). See MantisGraph core plugin for an example and Slim Framework router documentation.Before calling into the plugin routes, the user would be already authenticated and authorized for API access in general. However, it is the responsibility of the plugin to do its own plugin specific authorization.
EVENT_LOG (Execute)
This event is triggered by MantisBT to log a message. The contents of the message should be hyper linked based on the following rules: #123 means issue 123, ~123 means issue note 123, @P123 means project 123, @U123 means user 123. Logging plugins can capture extra context information like timestamp, current logged in user, etc. This event receives the logging string as a parameter.Parameters
EVENT_AUTH_USER_FLAGS (First)
An event that enables plugins to return a set of flags that control the authentication behaviors for the user who is logging in or logged in. In some cases, the user will be in the system, but there will be cases where the username provided by the user doesn't exist. In case the user doesn't exist, it is up to the authentication plugin whether to fail the login, validate credentials then fail, or validate credentials then auto-provision the user based on information the plugin is aware of (e.g. IDP or some db of accounts). If no plugin is registered for events, then defaults are used. If plugin sets a subset of the options, then the default will be used for the rest.Checkout SampleAuth plugin for more details.EVENT_CRONJOB (Execute)
This is an event that is triggered by the scripts/cronjob.php on some recurring schedule (once an hour is recommended). Plugins handle this event to execute recurring tasks.
EVENT_DISPLAY_BUG_ID (Chained)
This is an event to format bug ID numbers before being displayed, using thebug_format_id()API call. The result should be plain-text, as the resulting string is used in various formats and locations.Parameters
Return Value
EVENT_DISPLAY_EMAIL (Chained)
This is an event to format text before being sent in an email. Callbacks should be used to process text and convert it into a plaintext-readable format so that users with textual email clients can best utilize the information. Hyperlinks and other markup should be removed, leaving the core content by itself.Parameters
Return Value
EVENT_DISPLAY_EMAIL_BUILD_SUBJECT (Chained)
This is an event to format the subject line of an email before it is sent.Parameters
Return Value
EVENT_DISPLAY_FORMATTED (Chained)
This is an event to display generic formatted text. The string to be displayed is passed between hooked callbacks, each taking a turn to modify the output in some specific manner. Text passed to this may be processed for all types of formatting and markup, including clickable links, presentation adjustments, etc.Parameters
Return Value
EVENT_DISPLAY_RSS (Chained)
This is an event to format content before being displayed in an RSS feed. Text should be processed to perform any necessary character escaping to preserve hyperlinks and other appropriate markup.Parameters
Return Value
EVENT_DISPLAY_TEXT (Chained)
This is an event to display generic unformatted text. The string to be displayed is passed between hooked callbacks, each taking a turn to modify the output in some specific manner. Text passed to this event should only be processed for the most basic formatting, such as preserving line breaks and special characters.Parameters
Return Value
EVENT_MENU_ACCOUNT (Default)
This event gives plugins the opportunity to add new links to the user account menu available to users from the 'My Account' link on the main menu.Return Value
EVENT_MENU_DOCS (Default)
This event gives plugins the opportunity to add new links to the documents menu available to users from the 'Docs' link on the main menu.Return Value
EVENT_MENU_FILTER (Default)
This event gives plugins the opportunity to add new links to the issue list menu available to users from the 'View Issues' link on the main menu.Return Value
EVENT_MENU_ISSUE (Default)
This event gives plugins the opportunity to add new links to the issue menu available to users when viewing issues.Parameters
Return Value
EVENT_MENU_ISSUE_RELATIONSHIP (Default)
This event allows plugins to add new links to the menu under the Relationships section in the View Issue Details page.Parameters
Return Value
EVENT_MENU_MAIN (Default)
This event gives plugins the opportunity to add new menu options to the main menu. New links will be added AFTER the standard menu options.Return Value
EVENT_MENU_MAIN_FRONT (Default)
This event gives plugins the opportunity to add new menu options to main menu. New links will be added BEFORE the standard menu options.Return Value
EVENT_MENU_MAIN_FILTER (Chained)
This event gives plugins the opportunity to modify the complete main menu before it is output (for example re-order items, add items in the middle, remove built-in items, change icons of built-in items).A single parameter is passed as an array of associate arrays containing the items in the main sidebar menu. The format of this array is the same as EVENT_MENU_MAIN and EVENT_MENU_MAIN_FRONT, and will also contain any entries added as a result of these events.Plugins should do any modifications needed and return the array back. Returning an empty array will hide the main menu.Parameters
Return Value
Note
When returning the updated menu, the plugin's hook function needs to wrap it in an array, i.e.return array( $p_menu_data );and notreturn $p_menu_data;. The reason for this is that the Event API relies on call_user_func_array() to execute callback functions.
EVENT_MENU_MANAGE (Default)
This event gives plugins the opportunity to add new links to the management menu available to site administrators from the 'Manage' link on the main menu. Plugins should try to minimize use of these links to functions dealing with core MantisBT management.Return Value
EVENT_MENU_MANAGE_CONFIG (Default)
This event gives plugins the opportunity to add new links to the configuration management menu available to site administrators from the 'Manage Configuration' link on the standard management menu. Plugins should try to minimize use of these links to functions dealing with core MantisBT configuration.Return Value
EVENT_MENU_SUMMARY (Default)
This event gives plugins the opportunity to add new links to the summary menu available to users from the 'Summary' link on the main menu.Return Value
EVENT_LAYOUT_RESOURCES (Output)
This event allows plugins to output HTML code from inside the<head>tag, for use with CSS, Javascript, RSS, or any other similar resources. Note that this event is signaled after all other CSS and Javascript resources are linked by MantisBT.Return Value
EVENT_LAYOUT_BODY_BEGIN (Output)
This event allows plugins to output HTML code immediately after the<body>tag is opened, so that MantisBT may be integrated within another website's template, or other similar use.Return Value
EVENT_LAYOUT_PAGE_HEADER (Output)
This event allows plugins to output HTML code immediately after the MantisBT header content, such as the logo image.Return Value
EVENT_LAYOUT_CONTENT_BEGIN (Output)
This event allows plugins to output HTML code after the top main menu, but before any page-specific content begins.Return Value
EVENT_LAYOUT_CONTENT_END (Output)
This event allows plugins to output HTML code after any page- specific content has completed, but before the bottom menu bar (or footer).Return Value
EVENT_LAYOUT_PAGE_FOOTER (Output)
This event allows plugins to output HTML code after the MantisBT version, copyright, and webmaster information, but before the query information.Return Value
EVENT_LAYOUT_BODY_END (Output)
This event allows plugins to output HTML code immediately before the</body>end tag, to so that MantisBT may be integrated within another website's template, or other similar use.Return Value
EVENT_VIEW_BUG_ATTACHMENT (Output)
This event allows plugins to output HTML code immediately after the line of an attachment. Receives the attachment data as a parameter, in the form of an attachment array from within the array returned by thefile_get_visible_attachments()function.Parameters
core/file_api.php)Return Value
EVENT_FILTER_FIELDS (Default)
This event allows a plugin to register custom filter objects (based on theMantisFilterclass) that will allow the user to search for issues based on custom criteria or datasets. The plugin can return either a class name (which will be instantiated at runtime) or an already instantiated object. The plugin must ensure that the filter class has been defined before returning the class name for this event.Return Value
EVENT_FILTER_COLUMNS (Default)
This event allows a plugin to register custom column objects (based on theMantisColumnclass) that will allow the user to view data for issues based on custom datasets. The plugin can return either a class name (which will be instantiated at runtime) or an already instantiated object. The plugin must ensure that the column class has been defined before returning the class name for this event.Return Value
EVENT_VIEW_BUG_DETAILS (Execute)
This event allows a plugin to either process information or display some data in the bug view page. It is triggered after the row containing the target version and product build fields, and before the bug summary is displayed.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_VIEW_BUG_EXTRA (Execute)
This event allows a plugin to either process information or display some data in the bug view page. It is triggered after the bug notes have been displayed, but before the history log is shown.Any output here should be contained within its own<table>element.Parameters
EVENT_REPORT_BUG_FORM (Execute)
This event allows plugins to do processing or display form elements on the Report Issue page. It is triggered immediately before the summary text field.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_REPORT_BUG_FORM_TOP (Execute)
This event allows plugins to do processing or display form elements at the top of the Report Issue page. It is triggered before any of the visible form elements have been created.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_REPORT_BUG_DATA (Chain)
This event allows plugins to perform pre-processing of the new bug data structure after being reported from the user, but before the data is saved to the database. At this point, the issue ID is not yet known, as the data has not yet been persisted.Parameters
core/bug_api.php)Return Value
EVENT_REPORT_BUG (Execute)
This event allows plugins to perform post-processing of the bug data structure after being reported from the user and being saved to the database. At this point, the issue ID is actually known, and is passed as a second parameter.Parameters
core/bug_api.php)
EVENT_UPDATE_BUG_FORM (Execute)
This event allows plugins to do processing or display form elements on the Update Issue page. It is triggered immediately before the summary text field.Parameters
EVENT_UPDATE_BUG_FORM_TOP (Execute)
This event allows plugins to do processing or display form elements on the Update Issue page. It is triggered immediately before before any of the visible form elements have been created.Parameters
EVENT_UPDATE_BUG_STATUS_FORM (Execute)
This event allows plugins to do processing or display form elements in the bug change status form. It is triggered immediately before the add bugnote fields.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_UPDATE_BUG_DATA (Chain)
This event allows plugins to perform pre-processing of the updated bug data structure after being modified by the user, but before being saved to the database.Parameters
core/bug_api.php)core/bug_api.php)Return Value
core/bug_api.php)
EVENT_UPDATE_BUG (Execute)
This event allows plugins to perform post-processing of the bug data structure after being updated.Parameters
core/bug_api.php)core/bug_api.php)
EVENT_BUG_ACTIONGROUP_FORM (Execute)
This event allows plugins to do processing or display form elements in the bug group action page form. It is triggered immediately after the standard fields, and before bugnote fields (if applicable).Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
Parameter array contents
The parameter array contains elements for these indexes:
bug_actiongroup.php)
EVENT_BUG_ACTION (Execute)
This event allows plugins to perform post-processing of group actions performed from the View Issues page. The event will get called for each bug ID that was part of the group action event.Parameters
bug_actiongroup.php)
EVENT_BUG_DELETED (Execute)
This event allows plugins to perform pre-processing of bug deletion actions. The actual deletion will occur after execution of the event, for compatibility reasons.Parameters
EVENT_VIEW_BUGNOTES_START (Execute)
This event allows a plugin to either process information or display some data in the bug notes section, before any bug notes are displayed. It is triggered after the bug notes section title.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_VIEW_BUGNOTE (Execute)
This event allows a plugin to either process information or display some data in the bug notes section, interleaved with the individual bug notes. It gets triggered after every bug note is displayed.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_VIEW_BUGNOTES_END (Execute)
This event allows a plugin to either process information or display some data in the bug notes section, after all bugnotes have been displayed.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_BUGNOTE_ADD_FORM (Execute)
This event allows plugins to do processing or display form elements in the bugnote adding form. It is triggered immediately after the bugnote text field.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_BUGNOTE_DATA (Chained)
This event allows plugins to preprocess bugnote contents.Parameters
Return value
EVENT_BUGNOTE_ADD (Execute)
This event allows plugins to do post-processing of bugnotes added to an issue.Parameters
EVENT_BUGNOTE_EDIT_FORM (Execute)
This event allows plugins to do processing or display form elements in the bugnote editing form. It is triggered immediately after the bugnote text field.Any output here should be defining appropriate rows and columns for the surrounding<table>elements.Parameters
EVENT_BUGNOTE_EDIT (Execute)
This event allows plugins to do post-processing of bugnote edits.Parameters
EVENT_BUGNOTE_DELETED (Execute)
This event allows plugins to do post-processing of bugnote deletions.Parameters
EVENT_TAG_ATTACHED (Execute)
This event allows plugins to do post-processing of attached tags.Parameters
EVENT_TAG_DETACHED (Execute)
This event allows plugins to do post-processing of detached tags.Parameters
EVENT_NOTIFY_USER_INCLUDE (Default)
This event allows a plugin to specify a set of users to be included as recipients for a notification. The set of users returned is added to the list of recipients already generated from the existing notification flags and selection process.Parameters
Return Value
EVENT_NOTIFY_USER_EXCLUDE (Default)
This event allows a plugin to selectively exclude individual users from the recipient list for a notification. The event is signalled for every user in the final recipient list, including recipients added by the event NOTIFY_USER_INCLUDE as described above.Parameters
Return Value
EVENT_ACCOUNT_PREF_UPDATE_FORM (Execute)
This event allows plugins to do processing or display form elements on the Account Preferences page. It is triggered immediately after the last core preference element.Any output here should follow the format found in account_prefs_inc.php. As of 1.3.x this is no longer table elements.Parameters
EVENT_ACCOUNT_PREF_UPDATE (Execute)
This event allows plugins to do pre-processing of form elements from the Account Preferences page. It is triggered immediately before the user preferences are saved to the database.Parameters
EVENT_USER_AVATAR (First)
This event gets the user's avatar as an instance of the Avatar class. The first plugin to respond with an avatar wins. Hence, in case of multiple avatar plugins, make sure to tweak the priorities. Avatars should return null if they don't have an avatar for the specified user id.Parameters
EVENT_MANAGE_OVERVIEW_INFO (Output)
This event allows plugins to display special information on the Management Overview page.Any output here should be defining appropriate rows and columns for the surrounding <table> elements.Parameters
EVENT_MANAGE_PROJECT_PAGE (Execute)
This event allows plugins to do processing or display information on the View Project page. It is triggered immediately before the project access blocks.Any output here should be contained within its own <table> element.Parameters
EVENT_MANAGE_PROJECT_CREATE_FORM (Execute)
This event allows plugins to do processing or display form elements on the Create Project page. It is triggered immediately before the submit button.Any output here should follow the format found in manage_proj_create_page.php. As of 1.3.x this is no longer table elements.
EVENT_MANAGE_PROJECT_CREATE (Execute)
This event allows plugins to do post-processing of newly-created projects and form elements from the Create Project page.Parameters
EVENT_MANAGE_PROJECT_UPDATE_FORM (Execute)
This event allows plugins to do processing or display form elements in the Edit Project form on the View Project page. It is triggered immediately before the submit button.Any output here should follow the format found in manage_proj_edit_page.php. As of 1.3.x this is no longer table elements.Parameters
EVENT_MANAGE_PROJECT_UPDATE (Execute)
This event allows plugins to do post-processing of modified projects and form elements from the Edit Project form.Parameters
EVENT_MANAGE_PROJECT_DELETE (Execute)
This event allows plugins to do pre-processing of project deletion. This event is triggered prior to the project removal from the database.Parameters
EVENT_MANAGE_VERSION_CREATE (Execute)
This event allows plugins to do post-processing of newly-created project versions from the View Project page, or versions copied from other projects. This event is triggered for each version created.Parameters
EVENT_MANAGE_VERSION_UPDATE_FORM (Execute)
This event allows plugins to do processing or display form elements on the Update Version page. It is triggered immediately before the submit button.Any output here should follow the format found in manage_proj_ver_edit_page.php. As of 1.3.x this is no longer table elements.Parameters
EVENT_MANAGE_VERSION_UPDATE (Execute)
This event allows plugins to do post-processing of modified versions and form elements from the Edit Version page.Parameters
EVENT_MANAGE_VERSION_DELETE (Execute)
This event allows plugins to do pre-processing of version deletion. This event is triggered prior to the version removal from the database.Parameters
EVENT_MANAGE_USER_CREATE_FORM (Execute)
This event allows plugins to do processing or display form elements on the Create User page. It is triggered immediately before the submit button.Any output here should follow the format found in manage_user_create_page.php.
EVENT_MANAGE_USER_CREATE (Execute)
This event allows plugins to do post-processing of newly-created users. This event is triggered for each user created. The Manage Users create form is one possible case for triggering such events, but there can be other ways users can be created.Parameters
EVENT_MANAGE_USER_UPDATE_FORM (Execute)
This event allows plugins to do processing or display form elements in the Manage User page. It is triggered immediately before the submit button.Any output here should follow the format found in manage_user_edit_page.php.Parameters
EVENT_MANAGE_USER_UPDATE (Execute)
This event allows plugins to do post-processing of modified users. This may be triggered by the Manage User page or some other path.Parameters
EVENT_MANAGE_USER_DELETE (Execute)
This event allows plugins to do pre-processing of user deletion.Parameters
EVENT_MANAGE_USER_PAGE (Execute)
This event allows plugins to do processing or display information on the View User page. It is triggered immediately after the reset password segment.Any output here should be contained within its own container.Parameters
https://server.com/mantis/api/rest/.
https://server.com/mantis/api/soap/mantisconnect.php.
<dependency>
<groupId>biz.futureware.mantis</groupId>
<artifactId>mantis-axis-soap-client</artifactId>
<version>1.2.15</version>
</dependency>| Revision History | |||
|---|---|---|---|
| Revision 2.25-0 | Mon Mar 8 2021 | ||
| |||
| Revision 2.24-1 | Sun May 3 2020 | ||
| |||
| Revision 2.24-0 | Sun Mar 15 2020 | ||
| |||
| Revision 2.23-0 | Sun Dec 9 2019 | ||
| |||
| Revision 2.22-1 | Thu Sep 26 2019 | ||
| |||
| Revision 2.22-0 | Sun Aug 25 2019 | ||
| |||
| Revision 2.21-2 | Mon Aug 19 2019 | ||
| |||
| Revision 2.21-1 | Thu Jun 13 2019 | ||
| |||
| Revision 2.21-0 | Sat Apr 20 2019 | ||
| |||
| Revision 2.20-0 | Sat Mar 16 2019 | ||
| |||
| Revision 2.19-0 | Wed Jan 2 2019 | ||
| |||
| Revision 2.18-0 | Tue Oct 16 2018 | ||
| |||
| Revision 2.17-1 | Mon Sep 24 2018 | ||
| |||
| Revision 2.17-0 | Mon Sep 3 2018 | ||
| |||
| Revision 2.16-0 | Sun Jul 29 2018 | ||
| |||
| Revision 2.15-0 | Tue Jun 5 2018 | ||
| |||
| Revision 2.14-0 | Sun Apr 29 2018 | ||
| |||
| Revision 2.13-1 | Wed Apr 4 2018 | ||
| |||
| Revision 2.13-0 | Sun Apr 1 2018 | ||
| |||
| Revision 2.12-0 | Sat Mar 3 2018 | ||
| |||
| Revision 2.11-0 | Tue Feb 6 2018 | ||
| |||
| Revision 2.10-0 | Sat Dec 30 2017 | ||
| |||
| Revision 2.9-0 | Sun Dec 3 2017 | ||
| |||
| Revision 2.8-0 | Sat Oct 28 2017 | ||
| |||
| Revision 2.7-0 | Sun Oct 8 2017 | ||
| |||
| Revision 2.6-0 | Sun Sep 3 2017 | ||
| |||
| Revision 2.5-1 | Sat Jun 17 2017 | ||
| |||
| Revision 2.5-0 | Sun Jun 4 2017 | ||
| |||
| Revision 2.4-1 | Sat May 20 2017 | ||
| |||
| Revision 2.4-0 | Sun Apr 30 2017 | ||
| |||
| Revision 2.3-3 | Sun Apr 30 2017 | ||
| |||
| Revision 2.3-2 | Sun Apr 17 2017 | ||
| |||
| Revision 2.3-1 | Fri Mar 31 2017 | ||
| |||
| Revision 2.2-3 | Wed Mar 22 2017 | ||
| |||
| Revision 2.2-2 | Sun Mar 12 2017 | ||
| |||
| Revision 2.2-1 | Sun Feb 26 2017 | ||
| |||
| Revision 2.1-2 | Sun Feb 26 2017 | ||
| |||
| Revision 2.1-1 | Tue Jan 31 2017 | ||
| |||
| Revision 2.0-2 | Fri Dec 30 2016 | ||
| |||
| Revision 2.0-1 | Sat Nov 26 2016 | ||
| |||