MantisBT - Issues

0037441: Неправильний відмінок в слові

Mon, 05 Oct 2026 13:01:27 -0400

Замість слова "Кінострічок", має бути слово "Кінострічки"

0037436: test

Fri, 02 Oct 2026 06:23:51 -0400

rozbite

0037435: MaxBot Plugin

Thu, 01 Oct 2026 11:02:32 -0400

The plugin connects MantisBT with a bot of the MAX messenger (https://max.ru), the MAX counterpart
of the TelegramBot plugin already hosted in mantisbt-plugins. It reports issues from the chat with
a guided dialog covering every field of the report form, custom fields included, adds notes by
replying to notifications, attaches files, changes the issue status, broadcasts messages to the
members of chosen projects and sends notifications to MAX instead of, or along with, email. With
the Calendar plugin installed it also creates calendar events from the chat and notifies about them.

Requires MantisBT 2.26 or higher. MaxBot and TelegramBot can be installed side by side.

I have transferred the repository to the mantisbt-plugins organization:
https://github.com/mantisbt-plugins/MaxBot

Please add it to the plugins list on the wiki. Push access: brlumen.

Thanks!

0037434: Support S3 as backend for attachments

Wed, 30 Sep 2026 05:02:48 -0400

Currently only Database and File System are supported, but with the ability to deploy on clouds, S3 becomes a great addition to it.

0037433: wrong time locality

Tue, 29 Sep 2026 11:26:57 -0400

test to see if the time locality is not consistent with the local machine

0037431: attached Image not getting issue ID

Mon, 28 Sep 2026 08:08:36 -0400

Image not getting issue ID
http://support.svaapta.com/file_download.php?file_id=29208&type=bug

getting blank

0037428: Login form with username and password

Sun, 27 Sep 2026 14:50:18 -0400

Hello,
we were using version 1.3.0 for a long time and migrated to 2.28.4, all is fine except the login form
Would it be possible to customize the form as to display username and password on the same screen
that allows to save passwords in the web wallet and not have to input'em at every password request .

some plugin? tweaking login_page.php/login.php ?

Any help is highly appreciated and thank You!

0037427: Allow attachments stored on disk to be spread over subdirectories

Mon, 28 Sep 2026 08:15:11 -0400

With `$g_file_upload_method = DISK`, every attachment belonging to a project is
written directly into that project's upload directory. There is no way to
subdivide it.

On installations that accumulate large numbers of attachments this becomes a
real operational problem. In our case a single directory holds roughly 133,000
files. The consequences:

- Directory traversal is expensive, and every tool that walks the directory
pays for it.
- Incremental backups are the worst case. rsync has to stat the entire
directory to discover the handful of files that changed since the last run,
which took hours. After splitting the files across 256 subdirectories the
same backup completes in minutes, because unchanged subtrees are skipped
cheaply.

Other applications that store large numbers of hashed files solve this by
using the leading characters of the file name as a directory prefix - git's
object store being the obvious example.

0037426: Moving an issue between projects fails or silently skips its attachments when the source project's file path has changed

Mon, 28 Sep 2026 08:21:49 -0400

`file_move_bug_attachments()` derives each attachment's source location from
the source project's *current* `file_path`, ignoring the `folder` column that
records where the file was actually written. The function also *writes*
`folder` at the end of each move, so it disagrees with itself: it maintains a
column it never reads.

`project_update()` lets an administrator repoint a project's `file_path`
without moving the attachments already on disk. From that point on, moving an
issue out of that project looks for its attachments in a directory that never
held them, with two distinct outcomes:

1. Normally, `rename()` and then `copy()` both fail, and the move aborts with
`ERROR_FILE_MOVE_FAILED` ("Unable to move file to ..."). The issue cannot be
moved at all.

2. If the two projects' configured paths happen to be equal, the early
`if( $t_path_from == $t_path_to ) return;` skips the move entirely. The
attachment is left in its old directory and `folder` still points there,
even though the issue now belongs to a project whose uploads live elsewhere.

That early return is wrong in principle as well as in this case: it compares
two projects' configuration, which says nothing about where any particular
attachment actually is.

0037425: With `$g_login_method = LDAP`, the local password is never used

Mon, 28 Sep 2026 09:04:15 -0400

With `$g_login_method = LDAP`, the local password is never used:

- `auth_does_password_match()` returns `ldap_authenticate()` directly when the
configured login method is LDAP, with no fallback to the database password;
- `ldap_authenticate_by_username()` overwrites the stored hash with the LDAP
password on every successful login.

So the password an administrator types on manage_user_create_page.php cannot
ever be used. The form invites them to choose a credential that has no effect.

manage_user_edit_page.php already suppresses the equivalent control via
`auth_can_set_password()`; the create page has no comparable check.

## Change

Hide the password fields on the create page when the login method is LDAP, and
skip the matching `empty_password_sure_msg` confirmation in
manage_user_create.php.

The second half matters: that confirmation fires whenever the submitted
password is blank, so hiding the field without it would add an extra
confirmation step to every user creation under LDAP.

## Notes on the approach

`auth_can_set_password()` would be the natural helper, but it cannot be used
here: it calls `auth_flags()`, which throws `ClientException` for a user id of
0 with a blank username, and on the create page no user exists yet.

The explicit `LDAP != config_get_global( 'login_method' )` test is instead the
form already used in signup_page.php, login_password_page.php,
lost_pwd_page.php and print_api.php.

## Tests

No new tests: the change is display logic on a page the suite does not
exercise. Verified that the existing suite is unaffected — 395 tests, no new
failures, against MariaDB 11 on PHP 8.3.

0037424: Attachments are orphaned on disk when a project's file path is changed

Mon, 28 Sep 2026 08:21:49 -0400

bug_file.folder records where an attachment was written, but most readers ignore it and re-derive the path from the project's current file_path. project_update() lets an administrator repoint a project's file path without moving existing attachments, after which deleting an issue or project silently leaves files behind, file_get_content() returns false (empty XML export / print pages), and the SOAP API reports the attachment as missing.

0037423: Update htmlpurifier to 4.19.1

Sun, 27 Sep 2026 06:42:05 -0400

PR https://github.com/mantisbt/mantisbt/pull/2286

0037422: Installer resets prefix/suffix to default values if step 1 fails

Sat, 26 Sep 2026 13:47:44 -0400

If the data entered in the installer's step 1 form does not pass validation (e.g. due to an incorrect database password), the values entered in database prefix, suffix and plugin prefix fields are reset to their default value.

The installer should keep the values entered by the user.

0037421: Javascript errors during install

Sat, 26 Sep 2026 12:28:37 -0400

When installing MantisBT, the browser's javascript console reports the following errors

> [Warning] jQuery.Deferred exception: Can't find variable: config (2)
> [Error] ReferenceError: Can't find variable: config

0037418: PHP 8.4: error messages lose their parameters ("Issue "0" not found")

Thu, 24 Sep 2026 04:00:29 -0400

On PHP 8.4, MantisBT 2.28.x displays error messages with empty parameters. For example, when I open a non-existent issue, I get Issue "0" not found. instead of the id I requested. I first noticed it in a plugin I maintain (Calendar): plugin_error() preceded by error_parameters() shows the same "0", so both core and plugin errors are affected.

Cause: in PHP 8.4, trigger_error( ..., E_USER_ERROR ) first emits an E_DEPRECATED ("Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, ..."), and only then the actual error. Both go through error_handler(). After handling the deprecation notice, error_handler() resets $g_error_parameters = array() at its end. So when the real E_USER_ERROR arrives, the parameters are already gone: vsprintf() receives empty strings, %d placeholders render as 0 and %s ones as empty.

0037393: plugin_file.php sends a gzip body with 304 Not Modified, which strict HTTP servers (Caddy) reject

Fri, 18 Sep 2026 04:10:39 -0400

plugin_file_include() (core/plugin_api.php) answers a matching If-Modified-Since with 304 Not Modified and no output. However, compress_handler_is_enabled() (core/compress_api.php) has already switched on zlib.output_compression via ini_set(), and PHP's zlib output handler emits a gzip stream (20 bytes: header, empty deflate block, trailer) even for an empty buffer. The raw response from php-fpm is:

Status: 304 Not Modified
Last-Modified: Wed, 16 Sep 2026 06:51:05 GMT
Content-Encoding: gzip
Vary: Accept-Encoding

<20 bytes of gzip>
RFC 9110 §15.4.5 forbids a body on 304. Apache and nginx silently drop it, so this went unnoticed. Caddy (Go net/http) refuses to write it and aborts the response:

{"level":"warn","logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response",
"uri":"/plugin_file.php?file=Calendar/calendar_filter.js",
"error":"writing: http: request method or response status code does not allow body"}
In the browser every plugin CSS/JS asset then fails with net::ERR_HTTP2_PROTOCOL_ERROR and the page renders unstyled. Since plugin_file.php sends Cache-Control: private, max-age=10800, the browser starts revalidating with If-Modified-Since about three hours after the first visit, so a MantisBT behind Caddy loses all plugin assets a few hours after each hard reload. Every plugin that serves files through plugin_file.php is affected.

Steps To Reproduce:

Additional Information:

0037392: Users with "Reporter" access can't submit a bug report if they pick any product version at all

Thu, 17 Sep 2026 05:24:17 -0400

When reporting a new issue, users can pick a "Product Version" from a dropdown. For Reporters, that dropdown correctly only offers released versions — that part works fine. But when the report is actually submitted, the system rejects it, saying the version is invalid — even though it's a perfectly normal, released version that was legitimately offered in the dropdown.

This only happens for accounts below "Developer" level (the default setting for who's allowed to report against unreleased versions). Administrators and Developers don't see this problem, so it's easy to miss unless you test as a lower-permission user.

0037391: Editing/viewing a custom field can make an unrelated custom field "disappear" and break the page

Thu, 17 Sep 2026 05:38:25 -0400

MantisBT keeps a temporary lookup that maps custom field names to their IDs. If a page happens to load just one specific custom field first (for example, opening the "Edit Custom Field" page for a single field), that lookup gets partially filled in — but the system then wrongly assumes it's fully filled in. Any later attempt on that same page to find a different custom field by name will incorrectly report that it doesn't exist, even though it does.

In practice, we saw this cause a real crash: our site has a plugin that looks up a custom field called "Bug heat" by name whenever an issue number is shown as a link (e.g. in "Recently Visited"). If that link is shown on a page that just loaded a different custom field first, the plugin gets told "Bug heat" doesn't exist, and the whole page fails with a fatal error instead of just showing the link.

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

Mon, 21 Sep 2026 03:17:06 -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.