Mantis Bug Tracker - Forums

Well, following a lot of "soul searching" and fruitless conversations with many, many LLMs (that all provided the same lie), it's clear to me that what we're trying to do isn't something a plugin can do. It's going to have to be "core modifications", and TBH, I want to avoid that entirely (this time ...

Just to add, I'm comparing what I'm doing against "MantisCoreFormatting", which has at least allowed me to get my very old and never worked properly in the first place plugin code for MantisBT 1.3 config page working again in MantisBT 2.27.

Hi,

I'm trying to write a really simple "CRM Integration Plugin" for our MantisBT installation (against MBT v2.27). It's not going to be anything spectacular; when a value is saved into a particular custom field in MBT, the value is turned into an anchor tag by the plugin that points at the ...

Many thanks for the reply atrol.

Mea culpa for the many "errors" in my post - yes, v1.3.20 not v.13.20, and I really should have said "Legacy support" rather than "long-term support". Irrespective, you are entirely correct that if we want to use newer PHP versions, we'll need to keep up with v2.x.

As part of "national cyber security nonsense", we are required to only use "supported software". This is not a problem for us, v1.13.20 is LTS. However, we also realise that it is unlikely to remain LTS forever.

We're using a reasonably heavily modified v1.13.20 ("nonsense changes" because staff ...

atrol wrote:I assume this is your issue https://www.mantisbt.org/bugs/view.php?id=23031

Hi atrol.

Yes, that reads very similar. I'll see if I can add any more information to that issue (assuming I still have my login on your bugtracker).

[strike]Just to keep everyone "in the loop", I'm having a fiddle about in core/history_api.php to see if I can "fix" this for us in the short term; if I comment out the entirety of the "#bugnotes" section of history_get_event_from_row() (lines 344 to 365 in my install), the history shows everything ...

Hi

It has been noticed that history isn't showing everything anymore. I'm pretty sure that once upon a time, the history of an issue would show you every operation that occurred against an issue, but now it appears to be hiding items.

Direct "for instance": one of our users was looking at an issue ...

Somewhat answering my own question, I thought I'd just give it a go.

Created two bare minimum users directly in the database (they don't appear in Manage Users), but with our existing modifications, it appears that Mantis is now happy for things to be assigned to the two users.

Hi

In 1.2.X, we created a couple of "fake" users for Assigned To that are used (infrequently) to indicate that particular departments should deal with an issue, rather than individual users (basically, we added a couple of extra "<option>" tags to the two "Assigned to" fields, and then some very ...

That was what I had thought. Thanks for the confirmation.

Hi all,

Is it possible to have a status that is applied to a particular issue category? We run with two categories (Change Request and Defect) and I've been asked to add a new status to Change Request (only), but I'm not sure if that functionality is currently baked into MBT.

MantisBT v1.3.1

#21712 (had to ask for a password reset, I'd forgotten whatever it was...)

[strike] Bug Report

Version : 1.3.1
Summary : No way to filter "negative" for checkbox custom fields
Description : If you create a checkbox custom field, you can use the View Issues filtering to look for the value that indicates a checked checkbox easily enough, but there's (currently) no way ...

And that doesn't work either; guessing Mantis creates the database entry with a value of '' (the null string).

I suspect that this may, in fact, be a bug of some description, either in 1.2.X that has carried over with this custom field or in how 1.3.X handles checkbox fields now. That or it's ...