View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017145 | mantisbt | change log | public | 2014-04-01 02:05 | 2023-01-03 13:08 |
Reporter | gmisally3 | Assigned To | |||
Priority | high | Severity | feature | Reproducibility | always |
Status | feedback | Resolution | open | ||
Product Version | 1.2.17 | ||||
Summary | 0017145: Need to show obsolete versions in Change Log. | ||||
Description | Sometimes, I need to list change log for several SW versions, including obsolete versions. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Any comment? |
|
Your feature request is contrary to what has been requested in 0011604. (which seems to be fixed in latest version)
vboctor wrote at 0011604:0039773
What do you think? |
|
We have a lot of SW releases. |
|
I don't have time for a deeper look at the moment, but I am sure that at least this statement is not related to the "Obsolete" flag.
|
|
I have read that vboctor write but I am agree with gmisally3. I have lot of SW release, and I use "obsolete flag" to hide this old version from field "Product Version", "Fixed in Version", "Target Version" for my developers. But for my manager it's easier to see all history on "Change Log" instead of "View issues". That's why I need to have "obsolete version" AND "release version" on changelog. |
|
Hi, |
|
If the users still have these versions, don't they need to be able to report bugs against such versions? Why do you think it is OK to hide their version when reporting bugs, but need it to be shown when viewing changelog? Would a config option that enables obsolete versions to show in changelog address your needs? Or do we think a separate flag per version that determines whether it should show up in changelog/roadmap makes sense. I suspect the former, but just checking. |
|
As mentioned elsewhere, instead of adding flags to the versions, I would rather offer filtering capability on the Changelog page, allowing users to decide what they want to see. |
|
a filtering option would do (and if it would remember the choice, even better). Seeing obsolete versions in Changelog is important for us too. Any hope to see this being addressed in the same release as 0011604, or shortly after (so we'll skip that one)? |
|
Hi, we absolutely need this option. hiding the obsolete versions from the search queries (view issues page) and changelog messes up our KPI, and quality reports of the project. But our quality manager reported a defect because suddently a lot of tickets disappeared from the system (a decrease in the total number of issues in Mantis), because the obsolete projects are not query-able anymore. This is serious issue for us at the moment. I whish we could have this option very soon. Thank you. |
|
to be linked with 0012636 as well |
|
@Bozz if this is critical for you, I invite you to revert https://github.com/mantisbt/mantisbt/commit/92cdfde8325155ac2e0ee511c222f9a4e34bd699 until a proper solution is implemented. EDIT: not sure why source integration is not picking up MantisBT master 92cdfde8 |
|
I usually don't like modifying the src code of mantis because it's a risk during mantis update. But I guess this issue is going to take long, so I'll have to revert it then. Thanks for the info. |
|
Hi again, Actually that works for versions only. But for projects it does not work. Let me explain: But there is no reason to completely remove them from the system: the view issues page does not list their tickets, the changelog neither... Is it a still a bug related to the current ticket, a misuse of the project properties, or is it a new feature request ? Thanks. |
|
Sorry, I wrote a false statement. There is an obsolete attribute of the project (development -> release -> stable -> obsolete). But setting the project à release or obsolete, does not set it as read only. The users are still able to report issues on it, and the project is still listed in the projects dropdown. |
|
Hello all, I face the same problem to display "obsolete" version in changelog for some uses. I try to summarize what I've read in the tracker and in github :
Maybe we could acknowledge the issue, I will be happy to try to help when a solution will be chosen |
|
We need the same Feature. We need to see obsolete Versions in the Change Log. |
|
Hi everyone, Is there any update or decision on this issue ? We too would need to see obsolete versions in the changelog, and would be glad to help implementing this feature ! |
|
I don't see any progress, e.g. this PR has been closed due to inactivity https://github.com/mantisbt/mantisbt/pull/618 |
|
Hi everyone, I tried 2 designs for this feature, which you can find there (https://github.com/c2pil/mantisbt/tree/feature/show_obsolete_button , https://github.com/c2pil/mantisbt/tree/feature/changelog_filter ) :
Would you mind giving me a feedback on those ideas ? |
|
I prefer the button idea: it makes it easier to switch than the drop down box. The default state should be configurable (ie. I would always want to show obsolete versions by default). |
|
On instances like mantisbt.org/bugs, it would mean that a single click of a user fetches some thousands of change log entries, thus stressing the server. @c2pil, I didn't check your code, just tried a bit your branches. There is a bug in current implementation: Clicking on the buttons with the version number gives |
|
Thanks @atrol for the feedback. What do you think of such functionnalities ? |
|
I would favor the "filter style" options. While the buttons approach seems easier at first, it is also quite limited; ideally, as a user, I would like to be able to have more filtering options than just the obsolete flags, for example date range and/or version range. Having a filters section would allow implementing that more easily later on I also second atrol's idea on paging, although that would be a separate work item. For the record, I have not actually tested the code, just looked at the attached screenshots. |
|
I'm not familiar with the filtering system in Mantis, but it seemed to me that implementing it would imply a lot of rework for both the Changelog and Roadmap pages. I see the buttons as a dynamic, quick and short/medium term way to address the issue, although I understand this is not the approach you would adopt for the long term. |
|
Here is another opinion. FTR, I started with MantisBT circa 2003, and my team has customized our installations extensively. I like the convenience of the button. I have to change the Obsolete flag on old releases in order to complete certain housekeeping tasks far more often than I care to admit. It takes time and time is short. The "show/hide" obsolete option would be a nice addition to the selectors for Product, Target version and Fixed In version fields as well as to the Change Log. The filter approach has the benefit of being easily amended should other filter options be adopted. We have added filtering to the Roadmap and the project managers like it very much. Adding filters to the Change Log, and adding the "show/hide obsolete" option to the View Issue filter set would be a boon to my team. All that amounts to quite a bit of work; especially since this issue suggests a more universal implementation of search and filter functions. I appreciate that most, if not all, the people maintaining MantisBT are volunteers. Thank you for your efforts to keep this project current and fresh. |
|
This ticket is also relevant for mantis 2; I could also imagine to have an interface listening current versions on page 1 and offering an pager which shows maybe 10 obsoleted versions per page starting with page 2. |
|
Just noticed this issue for Scribus. Yes, we need a way to display obsolete versions, please! :) |
|
Also interested in this feature � I see another way to implement it, maybe easier:
To go further, I think it would be valuable to display the complete state information (not yet published / published / obsolete) systematically / not only in this page. But this is another issue, isn't it? |
|