New way to display work item associations in details view

[sanbornsen]

Reference: 1608E102/1608E063
Note: This is an extension of story #306

Description

As a user, I want to be able to see and drill down into an associated work item details on a work item detail view.

Functional Acceptance Criteria

1. The user can see a list of associated/linked work items.
2. Associated work item entries are presented with id, title and the type of association in a way that it does not clutter the interface.
3. The user can directly go to the detail view of an associated work item from the list of associated work items. (Note: according to Display and Update Work Item Details [20] [20] #298, the back operation on the drilled down detail view will go back to the previous view, which in this case would be this view).
4. The user can delete associations by clicking on the delete button. Deleting an association requires a confirmation. Deletion of an association removes the entry instantly from the presented list.
5. UX implementation as defined by the UX team (Workflow, Wireframe).

Non-functional Acceptance Criteria

1. All updates are done in-place.

Dependencies

1. Userstory Display and Update Work Item Details [20] [20] #298

Tasks

• New UX design considering multiple work item link types
• Expose available workitem link types to link with current item in Work Item API Expose available workitem link types to link with current item in Work Item API #324
• Implement UI to support updated work item API with exposed available link types

[sanbornsen]

Questions

• Can one link type has multiple source types and target types?
• What happens if the reverse name and forward names are same for a link type? I believe in that case all the source and destinations should be same in such kind of link types. For example, for a link type relates to where the forward name and backward name is both relates to, the source and destination work item types should be same. i.e. type1, type2 <- relates to -> type1, type2

[sanbornsen]

@kwk @aslakknutsen please comment.

[sanbornsen]

@Mgranfie @mindreeper2420 any update on the new Wireframe / Visuals for linking? Please provide an issue number if you have any in UX.

[michaelkleinhenz]

This issue was moved to fabric8-ui/fabric8-planner#644

[kwk]

@sanbornsen

The user can delete associations by clicking on the delete button. Deleting an association requires a confirmation. Deletion of an association removes the entry instantly from the presented list.

This doesn't really matches the issues title which starts with "Display...". But anyhow...

---

@sanbornsen

Can one link type has multiple source types and target types?

This is a good question. To answer it we have to decide on how we want to expose work item types (WITs) in the UI. For the core, each WIT has a path (e.g. system.bug has the path /system.planneritem/system.bug) that describes some form of hierarchy. Correct me if I'm wrong @aslakknutsen but to my understanding that means that a type like foo with a path of /system.planneritem/system.bug/foo would satisfy as a three types:

1. system.planneritem,
2. system.bug,
3. foo

The way work item link types (WILTs) currently work is that the source and target have to be of a WIT. In other words, given a WILT with source and target of type system.bug, you can create a work item link (WIL) to/from a work item of type foo. Now, I now that the UI currently has no notion about this. But I think we can operate transparently when doing a type-ahead search in the UI for the source and target work item. Simply search by the type. For example, if the source type is system.planneritem you will find many work items with types that do not match system.planneritem but instead are derived from it:

http://demo.api.almighty.io/api/search?q=Test%20updated%20type:system.bug

All that UI has to do is to NOT filter this list by type. Instead accept what the core gives you and put it in the correct source or target. DON'T check for the type of the work items.

The only potential problem I see is how the UI will know where to put the linked work item: in the source or in the target. Let's play through some scenarios:

Simple scenario (exact matching types)

given WILT:

source_type = "system.bug"
target_type = "system.feature"
forward_name = "foo"
reverse_name = "bar"

1. The user opens a bug X (of type system.bug) and wants to create a link of the above given WILT:
   1. The drop-down menu for WILT selection needs to show only "bar" because it is obvious that the current work item is the source based on the given type.
   2. The user selects "foo"
   3. The UI knows now that it needs to filter for the type "system.feature" and that the current work item needs to be in the source of the link.

The remaining question is how obvious it really is that the UI knows about where to put the current work item (in the source or in the target).

Not so obvious scenario (not exactly matching types)

given WILT
(NOTE: Only the source type has changed from "system.bug" to "system.planneritem".):

source_type = "system.planneritem"
target_type = "system.feature"
forward_name = "foo"
reverse_name = "bar"

1. The user opens a bug X (of type system.bug) and wants to create a link of the above given WILT:
   1. The drop-down menu for WILT selection needs to show only "bar" because the current work item type "system.bug" is derived from "system.planneritem".
   2. The user selects "foo"
   3. The UI knows now that it needs to filter for the type "system.feature" and that the current work item needs to be in the source of the link.

In my PR #602 I tried to solve this problem by returning the possible WILTs that can be used to create a work item. This does not truely solve the problem and my question to @aslakknutsen is whether we want to expose WIT hierarchy information to the UI to be able to figure out such problems where to put a work item (in the source or target field).

---

@sanbornsen

What happens if the reverse name and forward names are same for a link type? I believe in that case all the source and destinations should be same in such kind of link types. For example, for a link type relates to where the forward name and backward name is both relates to, the source and destination work item types should be same. i.e. type1, type2 <- relates to -> type1, type2

I would not make this assumption. The list of WILT to choose from in the UI should always show the forward and reverse name and only collapse it to one if the forward and reverse name and the source and target types are equal.

[kwk]

After talking to @aslakknutsen we have decided to provide UI with a list of WILTs where can be used to create a link with the current work item as the source. Also we will be providing a list of WILTs that can be used to create a link with the current work item as the target. That way the UI can transparently handle types.