MantisBT - Issues

0037460: Adding a note to a read-only issue is denied when "All Projects" is selected, although allowed by the project's threshold

Mon, 26 Oct 2026 05:12:44 -0400

bug_is_readonly() reads $g_bug_readonly_status_threshold for the issue's project, but $g_update_readonly_bug_threshold for the user's currently selected project.

When update_readonly_bug_threshold is overridden at project level, the result therefore depends on the project selector. view.php overrides the current project, so the "Add Note" form is shown, but when the note is submitted, bugnote_add.php -> IssueNoteAddCommand::validate() -> bug_is_readonly() evaluates the threshold for "All Projects" and rejects the note:

APPLICATION ERROR #1103: The action cannot be performed because issue "X" is read-only. (HTTP 403)

If the user selects the issue's project first, the note is added.

0037459: Resolution field missing when closing a reopened issue

Mon, 26 Oct 2026 05:15:09 -0400

hen an issue that has been reopened is closed directly from the "Change Status To: closed" page, the Resolution field is not shown, so the resolution cannot be set and stays at "reopened".

bug_change_status_page.php considers the current resolution as "fixed" if it is >= $g_bug_resolution_fixed_threshold (FIXED). With the default enum, REOPENED (30) is greater than FIXED (20), so a reopened issue is treated as already fixed and the Resolution field is hidden when closing it. When resolving a reopened issue, the field is shown but "reopened" is preselected instead of "fixed".

bug_update.php already treats $g_bug_reopen_resolution as a special case in its resolution checks (see 0022468 for the original change on the status page).

0037458: Database schema differences for old MantisBT versions updated to recent versions

Mon, 26 Oct 2026 06:22:23 -0400

I happen to have a very old MantisBT MySQL/MariaDB database that has been updated over time to 2.28.4.
I also made a clean MantisBT 2.28.4 install.
I compared the two database structures.
Most differences are the text and longtext column types. But there is also a primary index and default value difference.

0037457: mci_file_add does not apply proper value for bugnote_id

Mon, 26 Oct 2026 07:43:38 -0400

In the /admin/schema.php it says the following.

```
# 0 - file was added pre-2.23.0 and not explicitly linked to an issue or a note.
# null - file was added by 2.23.0 release or newer and associated with the issue.
# otherwise - file was added or linked by 2.23.0 release or newer and associated with an issue note.
$g_upgrade[210] = array( 'AddColumnSQL', array( db_get_table( 'bug_file' ), "
bugnote_id I UNSIGNED DEFAULT '0' " ) );
```

mci_file_add does not respect this and always sets the bugnote_id to 0
I think this has to do with the default value being 0 and NULL not being specifically provided when adding the attachment.

0037451: string_get_bug_view_link() passes project_id as the $p_user argument to get_enum_element()

Sun, 18 Oct 2026 22:04:31 -0400

In `core/string_api.php`, `string_get_bug_view_link()` builds the status label for the link's `title` attribute with this call:

```php
$t_project_id = bug_get_field( $p_bug_id, 'project_id' );
$t_status = string_attribute( get_enum_element( 'status', bug_get_field( $p_bug_id, 'status' ), $t_project_id ) );
```

However, the signature of `get_enum_element()` (in `core/helper_api.php`) is:

```php
function get_enum_element( $p_enum_name, $p_val, $p_user = null, $p_project = null )
```

So `$t_project_id` is being passed as the **third** argument (`$p_user`), not the **fourth** (`$p_project`). Internally `get_enum_element()` forwards both to `config_get( 'status_enum_string', null, $p_user, $p_project )`, meaning the bug's project id is used as a user id when resolving the `status_enum_string` configuration.

Effect: the status label shown in the bug link tooltip does not honor a per-project override of `status_enum_string`, and the project id is mistakenly treated as a user id. In most installations the impact is negligible, because `status_enum_string` is rarely overridden per user and `config_get` falls back to the global value — which is likely why it went unnoticed. But it is still incorrect: a per-project `status_enum_string` override is ignored, and under specific user-level overrides the resolved label could be wrong.

Expected: the project id should be passed as the fourth argument:

```php
$t_status = string_attribute( get_enum_element( 'status', bug_get_field( $p_bug_id, 'status' ), null, $t_project_id ) );
```

Notes:
- Confirmed present in the installed version and still present in 2.28.1 and 2.28.4 (latest checked), so this is long-standing, not a recent regression.
- The resolved-class computation a few lines below already resolves the project correctly, via `config_get( 'bug_resolved_status_threshold', null, null, $t_project_id )` (project as the 4th argument) — which highlights the inconsistency in the `get_enum_element()` call.

0037450: Session lock during shutdown email delivery delays issue pages after updates

Fri, 16 Oct 2026 06:03:52 -0400

After adding a note or updating an issue, the redirected issue page
intermittently takes 5–15 seconds to load.

email_shutdown_function() calls fastcgi_finish_request() and then
email_send_all() while retaining the PHP session lock. The browser
receives the response and follows the redirect, but the next request
using the same session blocks in session_start() until email
processing finishes.

PHP-FPM slowlog captured nine affected requests, all waiting in
session_start() at core/session_api.php:149.

Expected behavior: save and release the active session before
finishing the response and processing notification emails.

0037449: Accessibility: Contrast ratio of text in bug_update_page.php fails WCAG

Wed, 14 Oct 2026 11:29:59 -0400

When editing a bug, the color of 'select option', 'input' and 'textarea' is #858585 on background #FFFFFF. The ratio being 3.96:1.

Thus, #858585 fails Web Content Accessibility Guideline (WCAG) success-criterion 1.4.3 and 1.4.6 for text and 1.4.6 for large-scale text.

**Solution**: Enhance text-color to #393939

0037447: summary_page.php without submenu

Tue, 27 Oct 2026 11:40:09 -0400

if you go to the summary_page there is no submenu, that leads to the graphic pages, anymore.
you can call for example the mantis/plugin.php?page=MantisGraph/resolution_graph.php direkt and that page shows the submenu. But without the submenu on summary_page, you cannot navigate the the graphic pages.

0037444: Anomalous skip from day 24 to 26 in Date selectors

Tue, 27 Oct 2026 07:13:00 -0400

In all platform forms (ticket creation, editing, or filters), the dropdown lists generated for "Date" type Custom Fields fail to display the 25th day of the month. The list visually counts ... 22, 23, 24, 26, 27 ..., completely blocking users from recording that exact day regardless of the month or year selected.

0037443: Issue created via REST API with too long value for custom field fails in the middle of operation with 500 error

Mon, 12 Oct 2026 02:14:01 -0400

When you create an issue via REST API with a custom field (String type) and send value which is too long, more than 255 characters, it creates an issue but fails during 'INSERT INTO mantis_custom_field_string_table [...]'. Exception is thrown from database that data is too long for column 'value'.
Issue exists but without all provided values for custom fields and 500 response code is returned.

We were able to find a root cause quite quickly because we found deprecation message in logs:
Unhandled deprecation warning in /var/www/mantis/core/classes/DbQuery.class.php line 298: 'Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, throw an exception or call exit with a string message instead'.

It fails in:

`if( !$this->db_result ) {
db_error( $this->db_query_string );
trigger_error( ERROR_DB_QUERY_FAILED, ERROR );
$this->db_result = false;
}`

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

Tue, 27 Oct 2026 07:12:06 -0400

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

getting blank

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:

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.