"Extended Relations" and usage in Board view

[Edit: rewritten for clarity.]

Hi,

In our real-life usage, we have found that it will be very useful if the concept of type to type Relations can be extended to include “extended” relations too.

For example, if type User Story is related to type Feature and type Feature is related to type Epic, then “extended relations” of an instance of User Story will include the instances of Epic related to that User Story via a Feature.

In Board view, currently the configuration options for Columns/Rows includes only the types directly related to the type(s) selected as Card. It will be very useful if the selection option also includes types that the Card type has extended relations with. This will allow creation of very useful Boards, for example a board where User Stories are cards, Features are rows and Epics are columns - an all-in-one board for a common need. Currently in order to create this view, a direct relation has to exist from the User Story to the Epic, which is quite tedious to maintain for each user story.

However, if an extended related type is selected as either Column or Row, then drag and drop between either the columns or rows can’t be supported (will have to be restricted) since the card actually doesn’t have any direct relationship with the type in the column or row (as the case may be). With this restriction put in place, such views will still be very useful.

Thanks!
Shafqat

2 Likes

Is this related to the “Polymorphic Relations” you mentioned in another post’s comment, @mdubakov?

In fact, further extension of this concept to types farther away in relationship chain can be used for the most common need of the Program/Project containers (all entities under a given project will have an implicit indirect relation ultimately ending in the program/project).

The following existing feature probably addresses this need: