View Issue Details

IDProjectCategoryView StatusLast Update
0013147mantisbtfeaturepublic2017-01-18 16:56
Reportertoddpw Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version1.2.5 
Summary0013147: I really want true global versions (like global categories)
Description

I just spent a few hours tonight which should have been minutes because there is not true global version support. The subproject inheritance is great, but we have many projects with a few subprojects each, so the only way I can have the same list of versions across our whole installation is to use Copy Versions every time I add a version, and woe be to anyone who RENAMES versions, which is what I just had to do tonight. You either rename each version in every project in which it appears, or you delete the old ones (one at a time!) and copy the new ones over. It's VERY tedious, and I've burned up quite a few version ID numbers just tonight.

Steps To Reproduce

Have lots of projects.
Create a set of version numbers and copy it to each top level project.
Try to rename most of your versions without spending a lot of time clicking.

TagsNo tags attached.

Relationships

related to 0009197 closedjreese Versioning/roadmap across all projects 
related to 0005668 acknowledged "versions" of parent project should be used in subprojects. 

Activities

toddpw

toddpw

2011-07-14 09:53

reporter   ~0029168

I see 0009197 has been closed. The auto-inheritance for subprojects is great, but without a global set of versions to inherit in the top-level projects, I am still looking at a ferocious amount of effort to maintain a large VERSION x PROJECT matrix. All our versions are consistent across the various projects, but they do slip and get rearranged, so about the only thing I could do to workaround the existing state of things would be to keep version names very vague and put all the information in the scheduled date.

vincent_sels

vincent_sels

2011-09-16 18:56

reporter   ~0029761

I would very much like to see this added too. Versions should be treated in exactly the same way categories are. Ie: there should be a mantis_version_table just like the mantis_category_table.

I can understand the intention why this hasn't been added yet - if you require the same set of versions for multiple 'products' or 'projects', they are most likely released together and thus you could create a 'super-project' and attach all 'sub-projects' to this.

For various reasons I would not opt for this resolution, one being that this would negate the use of the 2 seperate project-dropdownlists, as the first one would only be occupied by this topmost project, and the latter would then always contain <i>all</i> projects.

djcarr

djcarr

2011-09-19 22:06

reporter   ~0029807

It's only my opinion but it seems that the super-project solution is the right one for the problem described. The issue with the 2 project dropdowns is a smaller UI problem which could be solved with a better UI design.

vincent_sels

vincent_sels

2011-09-20 11:37

reporter   ~0029814

You're right. I moved those projects under the main project. As far as usability concerns a less beautiful solution, but functionally correct.

fbraun

fbraun

2012-06-22 04:48

reporter   ~0032139

There is another problem with global versions (also 1.2.5).
The main project owns the versions. If you add a new issue at the subproject you can set the global versions from the main project at "Product Version", "Target Version" and "Fixed in Version". This works right.
But if you want to use the version filter in "View Issues" for the subproject (Combobox "Project:"), the filter comboboxes are not filled with the global versions of the main project. I think the global version should be listed there.

I hope the description is ok and understandable.
Maybe it is fixed or there is ab better solution in a later version.

dregad

dregad

2012-06-22 04:56

developer   ~0032140

@fbraun this is a known issue, see 0005668