I'm getting some sort of bizarre issue with uploads on my MantisBT install, I've had 2.22.0 running for months and nothing ever been changed, I just updated to 2.24.1 to try fix my issue but still encounter the same problem. It is to do with file downloads, older uploads that have a certain pattern to the binary data in the BLOB field all give errors (do not load inline on page and when downloaded just error in image viewers).
(not the same version, though :D hahaha)
@Expression93_gitlab the information you provide is too vague to get an idea of what could be happening.
@dregad I ain't sure how else to explain it, as far as I am concerned nothing about my setup changed, it's been the same for weeks. Files uploaded by any user up to a certain point are now broken, when the file is downloaded (as it's supposed to be an image) it cannot be read in an image viewer (it just gives an error). Newer uploads appear to work fine, but these problematic file uploads would have worked at the time (otherwise we'd have noticed the issue sooner). The only difference I can see is that the BINARY data changes, all the broken files start with the same data, and they're all broken, if I try the first file where that data changes, the download is fine. (For the record though, the data is still unique for all of those problematic files)
@Expression93_gitlab if I understand correctly, you had a 2.22 instance working perfectly, then you started noticing corrupted attachments and you tried upgrading to 2.24.1 to fix it but it didn't ? If so, everything else being equal, I would say that excludes MantisBT from being the problem's root cause...
Since you mention BLOB field, I assume you're storing attachments in the DB (as opposed to file system). Maybe some corruption on the database ?
When I say "too vague" you mention bizarre issue, certain pattern, errors etc. Nothing specific that anyone could objectively use to analyze and try to find out what the problem is.
I got the release-2.24.2.tar.gz and went into the directory.. did a php -S 0.0.0.0:8080
Get this error.. :[Tue Aug 25 20:43:32 2020] 127.0.0.1:43520 [500]: GET /admin/check/ - require_once(): Failed opening required '/home/mantisbt-release-2.24.2/vendor/autoload.php' (include_path='.:') in /home/mantisbt-release-2.24.2/core.php on line 91
there is no autoload.php in the tgz or github..
this does nothing to make anything work.. :p
I don't see that in the documentation anywhere.. but that, of course, changes things..
Of course, running
composer install would fix the problem.
As for this not being documented, please check again - https://mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.contrib.clone.clone
Hi, I have a question (probabily very dumb btw) how do I use https://github.com/mantisbt-plugins/Snippets ?
@andrerosamatos did you read https://github.com/mantisbt-plugins/Snippets#usage if something is not clear please ask specific questions.
Hello, I have the following need: allow some users to specify another user as the reporter when they create a bug, but also record who actually created the bug, in order to use it later in custom database queries. My first idea would be to modify the https://github.com/mantisbt-plugins/CustomReporter plugin so that it keeps track of actual bug authors. Now there are two main approaches to this idea: either manage a separate bug author table with two columns (bug and author IDs), or add an 'author_id' column to the bug table. Which would be preferrable?
I am attempting to create a process that exports from my current ticket system to I can import it in to mantis. I have used the spec to create the XML file appropriately and that works just fine. I have thousands of tickets w/ attachments and I am trying to find a good way to get that imported in to mantis in an automated fashion. Is there a way i can automate the import process? I have played with using a script that will do http POST calls, but by having to authenticate, have session and header/cookie information, it's a royal PITA. I was wondering if there would be a way i could put the XML generated files on the mantis box and run something from the server to import those files by somehow calling the PHP to get them to import. I know it's a longshot because the import page ruins things by making you use project_id as a Posted field rather than doing something in the spec itself.
Not sure what spec you are referring to and what this XML file is, but anyway if you need to import issues you can try to use the XmlImportExport plugin (although TBH I have not used that for over 10 years so don't ask me for details). Alternatively if you are familiar with scripting, I would recommend you use the REST API rather than trying to go through the GUI via POST requests.
MantisBT 2.24.3 has just been released
This is a security release fixing 6 security issues including 3 CVEs. https://mantisbt.org/blog/archives/mantisbt/670
The error affects several parts of the site, the forum as well.
I was able to add the option on the manage plugins by altering the Snippets.API.php
The last one in this pic is summary
But the snippet don't appear in the summary field when creating a task
MantisBT 2.24.4 has been released
Security and maintenance release, addressing 6 CVEs (XSS, SQL injection and several information disclosure issues including a critical one). Also includes a few PHP 8.0 compatibility fixes. https://mantisbt.org/blog/archives/mantisbt/675
Announcing end of PHP 5 support
The upcoming MantisBT 2.25.0 release will be the last one supporting PHP 5; starting with MantisBT 2.26.0, the minimum PHP version will be 7.0.https://mantisbt.org/blog/archives/mantisbt/678
Hello, I have the same need as described in https://www.mantisbt.org/bugs/view.php?id=12602#c40973, that is: have a custom date "resolution date" field which is kept hidden until resolving the ticket, at which point the field is displayed and mandatory and should be pre-filled with the current date. As stated in the issue I am linking, mantisbt does not behave this way: "{today}" only works on ticket creation, not in later state transitions. So my question is: how do I best go about getting this field to work as I intend it to?
After some testing with ticket workflow and digging in the database, I get to the following conclusions:
- if a custom date field has a default value and is configured to be shown on issue creation, then it is set to its default value;
- if a custom date field has a default value but is not configured to be shown on issue creation, then it is left unset (the default value is not applied);
- if a custom date field is unset but must be displayed when e.g. updating the issue, then the field is displayed empty, and if left unchanged, will remain unset;
- if a custom date field is required, then the user must set the field to some valid date in order for the issue update to be allowed.
The combination of the above results in the following: if an unset custom date field (due to 2) must be displayed and is required, then it will be displayed empty (due to 3) but that empty value won't be allowed (due to 4). In that precise case, I think it would make sense to apply the default value regardless of the ticket state, before displaying the field.
I am of course willing to provide a patch.
Opinions / comments welcome.