View Issue Details

IDProjectCategoryView StatusLast Update
0017145mantisbtchange logpublic2023-01-03 13:08
Reportergmisally3 Assigned To 
PriorityhighSeverityfeatureReproducibilityalways
Status feedbackResolutionopen 
Product Version1.2.17 
Summary0017145: Need to show obsolete versions in Change Log.
Description

Sometimes, I need to list change log for several SW versions, including obsolete versions.
After upgrade mantis from 1.2.10 to 1.2.17, obsolete versions are not showed in Change Log.
I've tried the solution in 0010873:0026242 but it doesn't help.

TagsNo tags attached.
Attached Files

Relationships

related to 0011604 closedvboctor Versions marked as obsolete appear on change log page 
related to 0012636 new Obsolete versions not selectable as filter in `View Issues' 
related to 0008334 acknowledged Paginate/Limit Changelog 
related to 0024821 closedcproensa Wrong caching in version API 

Activities

gmisally3

gmisally3

2014-04-07 02:15

reporter   ~0039841

Any comment?

atrol

atrol

2014-04-07 02:54

developer   ~0039842

Last edited: 2017-01-04 02:34

Your feature request is contrary to what has been requested in 0011604. (which seems to be fixed in latest version)

obsolete versions shouldn't appear on the change-log page

vboctor wrote at 0011604:0039773

If there is a desire to still keep it in the change log, then don't mark it as obsolete. I don't believe we need another flag.

What do you think?

gmisally3

gmisally3

2014-04-07 03:23

reporter   ~0039843

We have a lot of SW releases.
If I don't make test and old released versions as obsolete, I'll get a long list while choosing "Product Version", "Target Version" and "Fixed in Version".
In Roadmap, I'll see a lot of versions and make the page not so clear.

atrol

atrol

2014-04-07 05:02

developer   ~0039844

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.

In Roadmap, I'll see a lot of versions and make the page not so clear.
You don't see a version in roadmap after the version has been set to "Released"

artiflo

artiflo

2015-05-19 05:34

reporter   ~0050788

Last edited: 2017-01-04 02:35

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.

ric

ric

2016-04-26 09:01

reporter   ~0053024

Hi,
I've just updated from 1.2.15 to 1.2.19 and I'm facing the same problem because normally I use obsolete flag to hide the versions that are not more supported. The users has the need to take a look on all the changelog because the versions, even if are not more supported, are still used by them

vboctor

vboctor

2017-01-04 02:37

manager   ~0054912

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.

dregad

dregad

2017-01-04 04:14

developer   ~0054913

Or do we think a separate flag per version that determines whether it should show up in changelog/roadmap

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.

simtel

simtel

2017-02-09 04:35

reporter   ~0055606

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)?

Bozz

Bozz

2017-03-10 02:07

reporter   ~0056026

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.
We are use to keep track of the evolution of the project, one aspect is the bug tracking system. Once a project is finished (terminated or in service for a very long time) we set it as "obsolete" to clean the view for the project in development for the developpers.

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.

Bozz

Bozz

2017-03-10 02:12

reporter   ~0056027

to be linked with 0012636 as well

dregad

dregad

2017-03-10 02:49

developer   ~0056028

Last edited: 2017-03-10 02:55

@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
EDIT 2: now it works !? ::confused::

Bozz

Bozz

2017-03-10 03:20

reporter   ~0056029

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.

Bozz

Bozz

2017-03-10 09:34

reporter   ~0056036

Hi again,

Actually that works for versions only. But for projects it does not work.

Let me explain:
I have a major project "My Tool" in mantis. I create subprojects of "My Tool" when developping important feature (so that they have their own lifecycle). For instance "feature 1 dev phase 1" is a subproject of "My Tool". Once the dev is finished, validated, accepted, and in service, there is no need to keep "feature 1 dev phase 1" project in the list (this project is finished), so I uncheck the "Enabled" checkbox in the project settings (there is no "obsolete" property on a project". That way this finished project will not polute the project list dropdown view, reporters would not be able to create mantis ticket on these finished project, etc...

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.

Bozz

Bozz

2017-03-10 09:39

reporter   ~0056037

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.

Mr.Bricodage

Mr.Bricodage

2017-10-22 16:51

reporter   ~0058022

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 :

  • vboctor merge GitHub PR 983 to fix 0011604 that asked not to show obsolete version.
  • users complains about the new behaviour (this issue and others, see 0009488:0051187 that point to others PR done to fix their problem)
  • everybody seems to agree that an option should be added to define the changelog behaviour regarding obsolete version
  • a PR (618), that added an option in config to define the behaviour has been rejected. Reason : "it would be better to modify the changelog page to allow user to dynamically select what to display". The same proposal is done by dregad in this issue (see 0017145:0054913).
  • everybody seems to agree with this proposal (me too), but the issue is in a feedback status since 2014 an the changelog page still doesn't display obsolete versions.

Maybe we could acknowledge the issue, I will be happy to try to help when a solution will be chosen

neumann

neumann

2017-10-30 06:41

reporter   ~0058084

We need the same Feature. We need to see obsolete Versions in the Change Log.

c2pil

c2pil

2019-06-10 06:06

reporter   ~0062229

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 !

atrol

atrol

2019-06-13 18:01

developer   ~0062253

Is there any update or decision on this issue ?

I don't see any progress, e.g. this PR has been closed due to inactivity https://github.com/mantisbt/mantisbt/pull/618

c2pil

c2pil

2019-06-21 12:13

reporter   ~0062285

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 ) :

  • First one is a button for each project, "Show/Hide obsolete". On click, it displays only the project with obsolete versions. It is illustrated by the 2 "changelog_show_obsolete_buttons" screenshots. A click in the first button in image 1 leads to image 2.
  • Second one is a filter style display to show or hide obsolete versions for all projects displayed. It is illustrated by the "changelog_filter_style" screenshots, the first one hiding obsolete (default), the second one showing them.

Would you mind giving me a feedback on those ideas ?
Thanks a lot

changelog_filter_style1.PNG (96,280 bytes)   
changelog_filter_style1.PNG (96,280 bytes)   
changelog_filter_style2.PNG (76,121 bytes)   
changelog_filter_style2.PNG (76,121 bytes)   
simtel

simtel

2019-06-21 12:57

reporter   ~0062287

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).

atrol

atrol

2019-06-22 07:43

developer   ~0062288

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.
This could be prevented by implementing a paging mechanism similar to the one on View Issues page.
See also 0008334 where paging has been requested.

@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 No Change Log information available if the version is an obsolete one.

c2pil

c2pil

2019-06-24 04:11

reporter   ~0062303

Thanks @atrol for the feedback.
Those branches were only created to visualize ideas. The code is only a quick & dirty implementation with a URL param for both branches, and I have not tested them extensively.

What do you think of such functionnalities ?

dregad

dregad

2019-06-24 04:25

developer   ~0062304

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.

c2pil

c2pil

2019-06-24 05:35

reporter   ~0062306

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.

Mophilly

Mophilly

2019-10-12 12:09

reporter   ~0062974

Last edited: 2019-10-12 12:11

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.

jweberhofer

jweberhofer

2019-12-13 03:13

reporter   ~0063264

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.

cbradney

cbradney

2021-06-17 11:02

reporter   ~0065633

Just noticed this issue for Scribus. Yes, we need a way to display obsolete versions, please! :)

00

00

2023-01-03 13:08

reporter   ~0067256

Also interested in this feature �

I see another way to implement it, maybe easier:

  • display all versions with a pager if necessary
  • display the version "state" information (obsolete or not) in brackets next to the version

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?