View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030973||mantisbt||change log||public||2022-09-08 16:46||2022-09-15 15:33|
|Summary||0030973: 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:
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.
|Tags||No tags attached.|
A filter "Issues entered for a specifc version" does not necessarily mean that all issues are introduced in this version (regressions).
Do you agree, that I close with "won't fix"?
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.