Project

General

Profile

Actions

Feature #15698

open

Custom Field of type version for inter project reference

Added by Dipan Mehta about 10 years ago. Updated about 10 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Custom fields
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

Currently the primary use of any custom field of type version, is similar to 'target-version' or 'affected version'. The version listed as possible values for CF is from the same roadmap. In some cases version's can be shared within the hierarchy but these versions will not only appear for the given CF but all version type fields in that project including the target version.

There is a major limitation when version is required to be used as reference without having to be included as part of the road-map of the project. One such example is a dependency field between two project. Say you have Product-A and Product-B both are independent product with versions such as A.1.x and B.1.y etc. Note that A.1.x cann't appear as the target version or in the roadmap of Product B. However, these two products have a dependency relationship. Say Product B depends on
Product-A, hence as versions A.x evolves, versions of B will have dependency on the minimum/maximum versions of A.

You can think of Product-A as say Ruby and Product-B as Redmine. You cann't have Ruby's target versions 'shared' with that of Redmine; and they have to be separate project. In the current system, there is no way define versions which have inter project reference.

The solution should include a 'Scope' variable for each CF of version type - with a project. Hence, Product-B can have a dependency-cf field which select 'Product-A' and there by enlist the Product-A's version not Product-B's version or any other project's version. This selection should be per CF of version type so there by multiple fields can be defined which all references different projects.

It is obvious that by default, the version can select the self project as well; thereby we can do what we are doing currently.

Actions #1

Updated by Dipan Mehta about 10 years ago

Some mistake! The status is not resolved.

Actions #2

Updated by Jan Niggemann (redmine.org team member) about 10 years ago

  • Status changed from Resolved to New
Actions #3

Updated by Dipan Mehta about 10 years ago

Since 2.5.0 is heavily focusing on custom fields can this issue also be included in this?

Actions

Also available in: Atom PDF