View Issue Details

IDProjectCategoryView StatusLast Update
0030973mantisbtchange logpublic2022-09-15 15:33
Reportervic-t Assigned To 
Status newResolutionopen 
Product Version2.25.5 
Summary0030973: Display Errata (open issues) in the Change Log

The change log currently only displays information about issues that have been fixed for a particular version.

There are a few buttons that come with each change log:

  • View issues - Opens the "View issues" page with the Filter "Fixed In Version" set to the version mentioned in the change log
  • Two more buttons that will restrict what is shown in the change log

What I personally miss here is the information how many issues were created with that specific build or version.

Say I release version 25 and the change log shows how 10 issues were fixed for that version. But then, a day later, it turns out that version 25 introduced a bug that is so severe that most people will not actually want to switch to version 25 but stay with 24 (or whatever it is they have).

Of course, one can get this information easily by simply opening "View Issues" and filter the field "Product Version". But it would be nice if this information was somehow integrated with the change log.

As a quick and probably easy fix, a button "View issues introduced in this version" (or a similar wording) that opens "View Issues" pre-filtered would be quite nice.

TagsNo tags attached.




2022-09-10 13:21

developer   ~0066985

As a quick and probably easy fix, a button "View issues introduced in this version"

A filter "Issues entered for a specifc version" does not necessarily mean that all issues are introduced in this version (regressions).
Maybe it's true for the way you are using MantisBT, but for other installations this would be a confusing button, providing questionable results.
E.g. there are users entering feature requests and enter the version number they are using, or they enter bugs where the bug exists also in earlier versions.

Do you agree, that I close with "won't fix"?



2022-09-15 15:33

reporter   ~0066996

Last edited: 2022-09-15 15:33

I thought about this and you're right, of course, it would be a lot more than just regressions so I agree that it wouldn't work for everyone.

Having said that, it would be nice to have the option to add and customize a button. If I look at the buttons currently used, it's just a query string that uses the version in question as a variable. Here's the view issues button query string as an example:

I just replaced the project and version number with ThisProject and ThisVersion, respectively, as those are the two variables in this query string.

So, one could simply create the query string they need, optionally add the variables, then bind this string to the button. The button itself could be created using a configuration option, something like "changelog_custom_button" or "changelog_custom_button_1" if there was a need or desire to be able to support multiple buttons. An array could be assigned where the first item is the button name and the second item is the query string.

This way, only those who want an additional button would get it, all others wouldn't be affected. I personally would probably use the opportunity to create a filter that would allow me to show actual regressions (using an additional category or tags) and thus reach my original goal.