MantisBT - Issues

0037359: Admin check reports false FAIL when Graphviz path is outside open_basedir

Wed, 26 Aug 2026 08:23:50 -0400

## Summary

On a clean MantisBT 2.28.4 installation, the admin installation check reports multiple `FAIL` results when PHP `open_basedir` restricts access to the default Graphviz path `/usr/bin/`.

One of the reported failures appears to be misleading:

`absolute_path configuration option has a trailing directory separator`

The `absolute_path` value is correct and the corresponding condition evaluates to `true`.

## Environment

* MantisBT: 2.28.4
* PHP: with `open_basedir` enabled
* Example `open_basedir`:

```text
/var/www/example.com
```
* Default Graphviz path:

```php
$g_graphviz_path = '/usr/bin/';
```
* Relationship graphs:

```php
$g_relationship_graph_enable = OFF;
```

## Steps to reproduce

1. Install a clean MantisBT 2.28.4 release.
2. Configure PHP with an `open_basedir` restriction, for example:

```text
open_basedir = /var/www/example.com
```
3. Leave the default Graphviz configuration unchanged:

```php
$g_graphviz_path = '/usr/bin/';
```
4. Open the MantisBT Admin → Check Installation page.

## Actual result

The following checks are reported as `FAIL`:

```text
absolute_path configuration option has a trailing directory separator

graphviz_path configuration option points to a valid directory
The path '/usr/bin/' is not a valid directory.

graphviz_path configuration option points to an accessible directory
The path '/usr/bin/' is not accessible.
```

The Graphviz failures are understandable because `/usr/bin/` is outside the configured `open_basedir`.

However, the `absolute_path` check is also marked as `FAIL`, even though its value is correct.

Example runtime value:

```text
/var/www/example.com/public_html/mantisbt-2.28.4/
```

The exact condition used by the admin check:

```php
substr( $t_path['config_value'], -1, 1 ) == DIRECTORY_SEPARATOR
```

evaluates to:

```text
bool(true)
```

## Additional investigation

Calling:

```php
realpath('/usr/bin/');
```

results in an `open_basedir` restriction warning and returns:

```text
bool(false)
```

The admin check function contains:

```php
$t_unhandled = check_unhandled_errors_exist();

if( $p_pass && !$t_unhandled ) {
$t_result = GOOD;
} elseif( $p_warning && !$t_unhandled || $t_unhandled == E_DEPRECATED ) {
$t_result = WARN;
} else {
$t_result = BAD;
}
```

This appears to allow a successful check (`$p_pass === true`) to be displayed as `FAIL` when an unrelated unhandled warning is present.

## Expected result

* The `absolute_path` check should report `PASS`.
* A Graphviz-related warning or failure should not change the result of unrelated configuration checks.
* Ideally, the Graphviz path should not be validated as a required path when Graphviz functionality is disabled:

```php
$g_relationship_graph_enable = OFF;
```

## Notes

The issue is reproducible with a clean MantisBT 2.28.4 installation, so it does not appear to be caused by modified or leftover files from an upgrade.

All paths in this report are anonymized examples.

0037355: Message-ID of a submit notification is inherited by subsequent notifications for unrelated issues

Tue, 25 Aug 2026 06:38:42 -0400

MantisBT reuses one global PHPMailer instance for all messages sent within a process. Only notifications for newly submitted issues set a Message-ID header (email_bug_info_to_one_user()); every other notification carries In-Reply-To instead. The cleanup between messages clears recipients, attachments, reply-to addresses and custom headers, but not PHPMailer::$MessageID.

The value therefore survives on the shared object, and every following message that does not set its own Message-ID is sent with it. As a result, notifications belonging to different issues go out under an identical Message-ID.

Consequences observed downstream:
- Mail servers that deduplicate by Message-ID discard messages silently. This is the same failure mode already described in issue 0011123.
- Ticket systems that resolve In-Reply-To against stored message IDs attach follow-ups to whichever issue happens to own the colliding ID, so notes for issue B end up filed under issue A.

The impact scales with $g_email_send_using_cronjob. With queued delivery the whole queue is flushed in a single process, so one submit notification can propagate its Message-ID to every later message in that run.

0037354: Category auto-assign doesn't check if user is enabled and has handler access level

Sun, 23 Aug 2026 04:26:05 -0400

If a user that is set to be auto-assigned issue of a category later gets disabled or no longer has the access level to handle issues, they are still assigned newly created issues.

0037353: PHP 8.4: Passing E_USER_ERROR to trigger_error() is deprecated since 8.4

Sat, 22 Aug 2026 11:07:49 -0400

error_api.php L106

can be reproduced by writing text in add relationship text box.

0037352: REST API to Move an Issue + EVENT_MOVE_BUG event

Sun, 23 Aug 2026 15:22:33 -0400

Add REST API + Command to move an issue with an optional note.

- Implements IssueMoveCommand and leverages it to expose a new REST API.
- Change Web UI to leverage the new command.
- Add an trigger `EVENT_MOVE_BUG` event after the move.

0037351: Update ADOdb to 5.22.12

Fri, 21 Aug 2026 06:11:53 -0400

Improve PHP 8.5 / 8.6 compatibility (see 0037349 / https://github.com/ADOdb/ADOdb/issues/1250).

0037349: Function is_integer() is deprecated since 8.6, use is_int() instead

Fri, 21 Aug 2026 06:11:48 -0400

Running test suite on PHP 8.6 throws numerous deprecation warnings

Reference: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_is_integer

0037348: Impossible to unset product version

Tue, 18 Aug 2026 11:05:45 -0400

When an Issue has *Product Version* defined, it is not possible to remove it, error message is :

APPLICATION ERROR 1601
Version "0" not found.

0037343: validation error check mismatches return types

Tue, 18 Aug 2026 11:06:21 -0400

bug_actiongroup_ext.php checks for failed id's by matching the type of the value returned from validation function to not null:
```
$t_failed_ids = array();

foreach( $t_projects_bugs as $t_project_id => $t_bugs ) {
$g_project_override = $t_project_id;
foreach( $t_bugs as $t_bug_id ) {
$t_fail_reason = bug_group_action_validate( $f_action, $t_bug_id );
if( $t_fail_reason !== null ) {
$t_failed_ids[$t_bug_id] = $t_fail_reason;
}
if( !isset( $t_failed_ids[$t_bug_id] ) ) {
$t_fail_reason = bug_group_action_process( $f_action, $t_bug_id );
if( $t_fail_reason !== null ) {
$t_failed_ids[$t_bug_id] = $t_fail_reason;
}
}
}
}
```
However, the validation function is supposed to return either true on success or a key=>value array with reasons for validation failure:
```
/**
* Validates the combination of an action and a bug. This ends up calling
* action__validate() from bug_actiongroup__inc.php
*
* @param string $p_action The custom action name without the "EXT_" prefix.
* @param integer $p_bug_id The id of the bug to validate the action on.
*
* @return boolean|array true if action can be applied or array of ( bug_id => reason for failure to validate )
*/
function bug_group_action_validate( $p_action, $p_bug_id ) {
$t_function_name = 'action_' . $p_action . '_validate';
return $t_function_name( $p_bug_id );
}
```

0037342: Generate Bruno collection from OpenAPI spec

Sat, 15 Aug 2026 04:33:36 -0400

Generate Bruno collection from the OpenAPI spec which is the source of truth beyond the code.

0037341: Project-specific stored_query_use_threshold is ignored when retrieving available filters

Sat, 22 Aug 2026 13:15:46 -0400

MantisBT does not consistently evaluate stored_query_use_threshold in the requested project context. If a project-specific value permits a user to use saved filters while the global value is higher, the filters API incorrectly returns no filters.

Steps to reproduce

1. Create two projects.
2. Create a Reporter-level user with access to one project.
3. Set the global stored_query_use_threshold value to Developer.
4. Set the selected project’s `stored_query_use_threshold` value to Reporter.
5. Create a public named filter associated with that project.
6. Authenticate as the Reporter-level user and request GET /api/rest/filters?project_id=.
7. Observe that no filters are returned.

Expected result
The project’s public named filter is returned because the project-specific stored_query_use_threshold permits Reporter-level access.

For ALL_PROJECTS, filters should only be returned from accessible projects whose effective stored_query_use_threshold permits access, together with global filters.

0037340: Remove swagger API definition in favor of OpenAPI spec

Tue, 18 Aug 2026 10:48:17 -0400

The goal is to move to a single source of truth beyond code for REST API definition.

0037339: Generate Postman collection from OpenAPI spec

Tue, 11 Aug 2026 14:11:53 -0400

Avoid maintaining a parallel Postman collection and generate it from the OpenAPI spec which is the source of truth beyond the code.

0037338: Include generated SOAP API documentation in release distributions

Tue, 11 Aug 2026 14:11:53 -0400

The release publishing script should include the SOAP API docs in the output artifact.

0037337: Include generated REST API documentation in release distributions

Sat, 15 Aug 2026 04:33:36 -0400

The release publishing script should include the REST API docs in the output artifact.

0037336: Generate REST API documentation from OpenAPI spec

Sat, 15 Aug 2026 04:33:36 -0400

1. Use OpenAPI spec as the source of truth.
2. Generate static documentation from the spec.
3. Retire the use of Postman collection published on Postman catalog.

0037333: Accept optional Bearer prefix on API token in Authorization header

Wed, 05 Aug 2026 23:37:44 -0400

The REST API only accepts the API token bare (Authorization: ). It rejects Authorization: Bearer , which is the RFC 6750 convention and the default for most HTTP clients, SDKs, API tools, and AI agents. Users routinely send the Bearer form and get an authentication failure with no indication of the cause.

Proposal: strip an optional, case-insensitive Bearer prefix before token lookup. The bare form remains fully supported, so the change is additive. Other schemes (e.g. Basic) are unaffected. Invalid tokens fail identically with or without the prefix, so no new failure path is introduced.

0037332: dfghj

Mon, 27 Jul 2026 05:23:28 -0400

sdfghjk

0037330: test

Sun, 26 Jul 2026 08:44:53 -0400

test

0037324: Dev Guide: the Example plugin should use constants for config

Thu, 23 Jul 2026 12:25:28 -0400

Better practice than repeating a hardcoded string multiple times.

GitHub repo https://github.com/mantisbt-plugins/Example should be updated too.

0037320: Cannot submit bug when selecting any product version

Tue, 21 Jul 2026 18:33:08 -0400

Since mantisBT 2.28.4, when trying to submit a bug, when a user selects ANY Product Version mantis will reject the bug saying invalid version. I already missed several bug reports due to this.

Oh and this issue is also present on this/your very bugtracker. I just had to retype my whole bug report because of it :-)

If you have like DEVELOPER level then the bug does not occur. If you select NO product version then the bug does not occur.

The fix in "Additional Information" or a workaround is setting: $g_report_issues_for_unreleased_versions_threshold = REPORTER;

Thanks for fixing this. We are happy to use mantis since 2002 :)

0037319: Duplicated code in MantisGraph plugin's graph_api.php

Mon, 20 Jul 2026 13:54:45 -0400

*create_developer_resolved_summary()* and *create_developer_open_summary()* functions are nearly identical, differing only by a condition in the SQL query where clause.

Duplicated code should be factored out.

0037318: get_gd_version() should return the complete version number

Mon, 20 Jul 2026 12:40:59 -0400

Currently, the function is returning the major GD version as an int (1 or 2) based on the presence of *imagegd2()*, or GD if the extension is not available.

This is a legacy from early PHP 4 days, when gd_info() did not exist (it was introduced in PHP 4.3.0).

We should simply call gd_info() and return the actual version number.

0037317: no-op upgrade step in plugin_upgrade() not working properly

Tue, 18 Aug 2026 11:08:07 -0400

The no-op schema operations for plugins implemented in 0023367 are not working as expected.

plugin_upgrade() is throwing
SYSTEM WARNING: Trying to access array offset on value of type null in '.../core/plugin_api.php' line 835

0037316: New error code: ERROR_PLUGIN_ENTITY_NOT_FOUND

Sat, 18 Jul 2026 13:08:27 -0400

This follows a suggestion by @vboctor in a TODO in the Snippets plugin [[1]]:

> ideally we should have a generic ENTITY_NOT_FOUND error to trigger 404 http status code
> low priority since this is not used by the UI.

[1]: https://github.com/mantisbt-plugins/Snippets/commit/f1e2cac7ce27e751919051bf054d9f1b1ff6b656#diff-02e954a8c250ad93b560d6cd5659b22bb84236ca86e1320299e9ae55a878735aR78-R80