Feature #15340
open
Custom field referencing other tickets
Added by Il Igid about 11 years ago.
Updated over 3 years ago.
Description
Redmine could become much more powerful if it would be possible to add custom fields which reference other tickts. It should be possible to filter the set of tickets referenceable per field. Via this a user could setup very powerful structures.
The field should be
- configurable to show #id, name or both
- displayed as a hyperlink which when clicked opens the referenced ticket
In general handling tickets as objects and applying filters to create sets of filters and support referencing between tickets would be a very powerful architectural choice. Next logical steps would be powerful reporting features (you want to be able to analyze according to the interdependencies), powerful dependency handlers (e.g. showing content of a referenced ticket directly in a referencing ticket).
Example 1: customer database
- a user could create a customer project with tickets per customer
- in a reference custom field the admin could define a filter which only allows references to tickets in this customer project
- the user can select from the available customer tickets and the ticket would allow to click on the customer reference and get detailed information
Example 2: Multi scale categorization
- You have a hierarchical project structure setup with architectural work packages
- You additionally want to group V&V tasks, engineering tasks, ... across the hierarchy and across trackers
- You additionally want to group according to features (across the hierarchy), which may be available as tickets already
- You additionally want to group according to requirements (not necessarily the same as a feature)
Files
- Category set to Custom fields
+1. Very useful. One of the important usecase is to indicate a chain of cause-effect issues where the fix of ticket #xyz has caused the current bug. Most issue relations follow-preced / blocks etc. are used mainly to deal with planning; however there is no way to create custom relationships between issue. Hence, CF of the type "issue-reference" will make it very easy to create such relations easily.
Here is a basic implementation I made (from trunk development version)
Just use a classical Text custom field. If the content begins with '#' (like in "#42"), it will convert the number that follows in link to the corresponding issue. No idea of what happens if the number is not a number or if no issue corresponds.
If you list #values separated by a comma ( "#42,#24,#422" ), it will display as a list of links.
Nice to see some progress on this.
However, even today this is possible by creating a text field (and using one of the plugins that converts text in link). Unfortunately, it will except all other type of text as well.
I think a good way would be equivalent to what works in related issues or parent issue field.
- The field should accept only integers, (avoiding any invalid text)
- The field can use the same tool tip to show issue title as one enters the number (used by parent/related issue )
- The field can render issue along with subject line under
format_value
If you want to gain more insight about how custom fields of arbitrary types can be developed look at the project:
http://projects.andriylesyuk.com/projects/extended-fields
thanks for the nice little implementation for prototyping.
For a final solution I would rather make a new field type available for custom fields and make the use very similar / same to the current relation fields. However, the current relation field implementation does contain some specifics (e.g. relation types) which do not make them easily reusable for a more generic theme without a refactoring.
#13690 proposes a solution to allow new relationships to be added. However, I'm not fluent enough in Ruby to implement it (in fact, my patch is my very first lines of Ruby)
- Related to Feature #13690: Allow plugins to be able to add relationship types added
+1. It's a very useful feature.
Also available in: Atom
PDF
Updated by Toshi MARUYAMA 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by