MantisBT - Issues

0037388: Anzeige

Mon, 14 Sep 2026 20:46:50 -0400

ssddfsfssfd

0037387: Caching doesn't get properly invalidated after write operations

Sun, 13 Sep 2026 16:54:36 -0400

Often a write operation involves a read and then write. If a read happens after the write, it often reads from stale cache. The write operations need to always flush the cache to avoid such stale reads. This often affects APIs more than web UI.

0037386: Complete rewrite of the installer

Sat, 12 Sep 2026 12:20:35 -0400

Our setup program is ancient, and is really showing its age.

- Its internal architecture is terrible, making it a pain to maintain
- It suffers from many security issues, many of which are not easily fixable - if at all
- It does not require user authentication

The only solution we can offer at the moment is a recommendation to delete the admin/ directory - but as a quick Google search shows, there are many public instances out there that do not do it,

It would be no small undertaking, but I believe that a complete rewrite is necessary.

0037384: "Change Status To" throws access denied error when issue handler is not developer anymore

Fri, 11 Sep 2026 08:29:08 -0400

On View issue page, when trying to change the status of an issue to *assigned* and the issue is already assigned to a user who is no longer authorized to handle issues (e.g. former developer downgraded to reporter), bug_change_status_page.php throws an Access Denied error.

This is not consistent with how such situation is handled for any other status (e.g. it is possible to change it to *resolved* without error) and in other situations (e.g. from bug_update_page.php).

We should only throw the error when the page's *handler_id* parameter is different from the issue's current handler.

0037379: Return value plugin_lang_get_defaulted when no default supplied is incorrect

Wed, 09 Sep 2026 19:08:09 -0400

When you call: plugin_lang_get_defaulted( 'test' );

I would expect when plugin_pluginname_test does not exist that i get 'test' back.
But instead it returns: 'plugin_pluginname_test'

0037377: URL doesn't change after issue creation with file attachment

Tue, 08 Sep 2026 11:26:59 -0400

The URL in browser doesn't change after we submit new issue with file attachment. It still displays .../bug_report_page.php after we were redirected to new issue.
Managed to reproduce the issue on Chrome and Firefox. The issue occurred after latest release.
Most likely it's a JS bug.

0037376: MantisBT REST API returns 302 redirect to login page instead of API response when using Authorization token

Tue, 08 Sep 2026 10:35:55 -0400

The MantisBT REST API is currently not returning the expected API response when an API token is provided through the `Authorization` header.

When calling the REST API with a valid API token, the request is redirected to the Mantis login page instead of returning the requested API data.

### API Request

```bash
curl -i \
-H "Authorization: YOUR_VALID_API_TOKEN" \
"http://support.svaapta.com/api/rest/index.php/projects"
```

### Current Response

```http
HTTP/1.1 302 Found
Location: http://support.svaapta.com/login_page.php?return=api%2Frest%2Findex.php
```

### Expected Response

The API should authenticate the user using the supplied API token and return the requested project data, for example:

```http
HTTP/1.1 200 OK
Content-Type: application/json
```

with the project information in the response body.

## Investigation Performed

The following checks have been completed:

1. The `Authorization` header is successfully reaching PHP.

```text
HTTP_AUTHORIZATION=
Authorization =>
```

2. The REST `index.php` is being executed successfully.

```text
REST INDEX EXECUTED
```

3. `AuthMiddleware.php` is successfully loaded.

```text
AUTH MIDDLEWARE FILE LOADED
```

4. The API token was independently validated using MantisBT's `api_token_get_user()` function.

```text
Token length: 32
User ID: 534
```

5. The token successfully maps to the MantisBT user.

```text
Username: hetal.parmar
```

6. `mci_check_login()` also successfully authenticates the user.

```text
mci_check_login: 534
```

7. The following REST middleware files were reviewed:

* `CacheMiddleware.php`
* `OfflineMiddleware.php`
* `VersionMiddleware.php`
* `AuthMiddleware.php`

8. The REST API is enabled in MantisBT configuration:

```php
$g_webservice_rest_enabled = ON;
```

## Environment

* MantisBT REST API
* PHP 8.1.x
* Apache
* OpenResty / Nginx reverse proxy
* Docker
* Slim Framework 3.x
* API token authentication

## Technical Observation

The API token itself is valid and the `Authorization` header reaches the REST endpoint correctly.

However, the request ultimately receives a `302` redirect to:

```text
login_page.php?return=api/rest/index.php
```

This redirect is unexpected for an API-token-authenticated REST request.

`AuthMiddleware` normally returns `401` or `403` for authentication/authorization failures rather than a `302` login redirect.

## Impact

REST API clients are currently unable to reliably access MantisBT REST endpoints using API token authentication.

This affects API integrations that depend on endpoints such as:

```text
/api/rest/index.php/projects
```

## Next Investigation

Trace the Slim middleware execution order and identify which component/code is generating the `302` redirect to `login_page.php`.

The following should be investigated:

* `AuthMiddleware` execution
* Slim middleware stack
* `ApiEnabledMiddleware`
* Mantis authentication/redirect functions
* Any customizations or plugins that may trigger login redirects
* Source of `login_page.php?return=api/rest/index.php`

## Expected Resolution

The REST API should accept a valid API token from the `Authorization` header and return the requested API response without redirecting the request to the MantisBT login page.

0037375: Date format problem when adding a version

Tue, 08 Sep 2026 10:35:03 -0400

When adding a new version or modifying an existing one, the "Sort by date" field is in the wrong format: YYYY-MM-DD HH:hh.
For example, if a new version is added with a date of 08/09/2026, it will be displayed as 0008-09-20 11:13.
How can I change the format of this field to DD-MM-YYYY HH:hh?
If I submit the field as is, without modifying it, I get an SQL error, which is expected:
Database query failed. The error returned by the database was 1: ERROR: value "-61986730140" is out of range for type integer

----
### Original report (French)
Bonjour,
Lorsque l'on souhaite ajouter une nouvelle version ou modifier une version existante le champ "Tri par date" est au mauvais format YYYY-MM-DD HH:hh.
Par exemple si on ajoute une nouvelle version en date du 08/09/2026 il sera affiché 0008-09-20 11:13.
Comment fait-on pour modifier le format de ce champ afin qu'il prenne le format DD-MM-YYYY HH:hh ?
Si on valide en l'état sans modifier le champ on tombe sur une erreur SQL ce qui est logique :
Échec de la requête de base de données. L’erreur renvoyée par la base de données était nº -1 : ERROR: value "-61986730140" is out of range for type integer
CONTEXT: unnamed portal parameter $4 = '...' pour la requête : UPDATE mantis_project_version_table
SET version=$1,
description=$2,
released=$3,
date_order=$4,
obsolete=$5
WHERE id=$6.

0037374: Project selection list search does not work with special characters

Thu, 10 Sep 2026 20:17:59 -0400

When trying to find a project using the search bar, nothing appears when entering certain special characters like `{}()-.,\*.`.
Replacing each character with a space makes it work.

However, special characters like _ & work correctly.

Can you explain why only certain characters are allowed?`

------
### Original report (in French):

Lorsque l'on souhaite se positionner sur un projet via la barre de recherche, il ne remonte rien lorsque l'on saisie certains caractères spéciaux comme {}()-.,\*
Si on remplace chaque caractère par un espace cela fonctionne.
Par ailleurs, des caractères spéciaux comme _ & fonctionnent correctement.

Pouvez-vous m'expliquer la raison qui fait que seulement certains caractères sont autorisés ?
Merci,
Cordialement.

0037372: HTTP 500 error when activating filter criteria

Mon, 07 Sep 2026 07:53:29 -0400

In view_all_bug_page.php, when clicking on any criteria, the filter field is not displayed and an HTTP 500 error occurs (see screenshot)

Running this with xdebug, we get more details:
Fatal error: Cannot use Mantis\Exceptions\ClientException as ClientException because the name is already in use in.../mantisbt/return_dynamic_filters.php on line 48

Regression introduced by :mantisbt:121dd1b63742ecb45a90ebe7e2200c29bb30804b: (0036812).

0037370: Misleading error message when trying to delete non-existing attachment via SOAP API

Wed, 09 Sep 2026 19:20:59 -0400

Unlike the REST API's `DELETE /issues/{id}/files/{file_id}' which includes the Issue Id, the SOAP API's mc_issue_attachment_delete endpoint only expects the attachment's id and does not allow specifying the issue id.

The newly added IssueFileDeleteCommand (0034425) requires both *issue_id* and *file_id*; to accomodate this, mc_issue_attachment_delete calls file_get_field() to retrieve the issue id, but does check the return value to ensure that the file actually exists. The Web UI (bug_file_delete.php) does the same thing.

So when the attachment does not exist, `false` is simply passed on to the Command's issue_id query parameter, and validate() returns a misleading error message: "'issue_id' missing". While this is technically true, it does not help the user figure out what is wrong with their request.

A more meaningful error message should be returned.
l

0037369: helper_parse_id() throws PHP warning when $p_id parameter is `null` (PHP 8.1)

Sun, 06 Sep 2026 06:40:57 -0400

The function's PHPDoc states that *$p_id* parameter should be a string, but in fact it can also be `null` (and possibly other types as well).

When this happens, PHP throws
DEPRECATED: trim(): Passing null to parameter 0000001 ($string) of type string is deprecated.

0037368: Calling access_denied() function from CLI triggers PHP warning

Sun, 06 Sep 2026 06:40:35 -0400

When running from CLI, PHP throws
SYSTEM WARNING: http_response_code(): Cannot set response code - headers already sent.

It makes no sense to output HTML, send a response code and redirect in a CLI context, this code should not be executed.

0037367: REST API: remove token authentication without bearer scheme

Fri, 04 Sep 2026 03:05:32 -0400

Following implementation of RFC-compliant authentication in 0035286 and 0037333, the legacy usage of the *Authentication* header without the *bearer* scheme (i.e. `Authentication: `) has been deprecated.

This tracks the future removal of this non-standard authentication method.

0037366: Deprecated error in PHP 8.5 when importing XML file

Thu, 03 Sep 2026 18:45:14 -0400

Importing XML file via `Import/Export issues` plugin gives

```
DEPRECATED: 'Case statements followed by a semicolon (;) are deprecated, use a colon (:) instead' in '.../mantisbt/plugins/XmlImportExport/ImportXml/Issue.php' line 152
```

See the [PHP 8.5 deprecation](https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_semicolon_after_case_in_switch_statement) for more details.

0037363: Error moving issue via REST API when $g_file_upload_method = DISK and attachment is missing

Sun, 30 Aug 2026 11:20:58 -0400

The API fails, even when no attachments are provided in the payload, e.g. with the following request

```http
POST {{resturl}}/issues/42601/move
Authorization: {{token}}
Content-Type: application/json

{
"project": {
"id": 1
}
}
```

PHP Warning is thrown:
chmod(): No such file or directory in .../mantisbt/mantis/core/file_api.php on line 1433

The API returns status 200 with an HTML error page (containing an Xdebug call stack on my dev box)

The error should be caught and reported to the user with a proper HTTP status.

0037362: Fix cases where existing commands were not used

Fri, 28 Aug 2026 12:08:32 -0400

There are some cases where the following commands are not being used:

- UserDeleteCommand
- ProjectUsersAddCommand
- ProjectUsersDeleteCommand
- MonitorAddCommand
- Version commands
- Tag commands

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

Fri, 28 Aug 2026 02:43:58 -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

Fri, 28 Aug 2026 12:09:11 -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, 30 Aug 2026 11:10:53 -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.