Content
View differences
Updated by Jens Ulferts over 4 years ago
**As** a project member
**I want** to have additional information in see the project name along with the related work package autocompleters, e.g. (both when selecting candidates for and viewing a relation work package)
**so that** I can easily distinguish between equally named see which project a work packages and can make an educated decision since I know more of the context.
#### Proposed solution
Similar package belongs to how (esp. for work packages are already presented with the same name in the search auto completion, the auto completer for relations will display additional fields per work package: different projects).
* Project
* Author (via an avatar)
* Status **Acceptance criteria**
The currently existing field
* Type
is removed Display project name along with work package (or possibly behind to make room.
The currently existing field
* Id
is kept but it is placed differently.
The results of the relation auto completer will look similar to how the search auto completer currently displays its results (without the avoid issues with very long project selection):
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/21423/content"></div></figure>
Currently, only id and subject are considered names (or abbreviate project name)) when searching for selecting a relation candidate. This is to be extended to also include the project. As a result, the user can type in 'company auto completion' to find work packages with the subject 'auto completion' within the 'company' project. Other examples include:
* 'company auto completion' -> Work package in project 'lorem ipsum' with subject 'Improve auto completion for Company' the relations section.
* 'company auto completion' -> Work package in Display project 'completion' with subject 'automate Company' name for related work packages.
* '123' -> Work package in Display project 'lorem ipsum' with id '123'
The parts of the fields 'id', 'subject' and 'project' matching the search string are highlighted to convey why a name when selecting / viewing child work package is part hierarchies from relations section. (not directly requested but useful in terms of the result set. consistency)
#### Acceptance criteria **Mockup (preliminary)**
* The autocompleter for managing work package relations (parent, child, follows, precedes, blocks, ...) shows the following elements:
Selecting relations:
<figure class="image op-uc-figure" style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20036/content"></div></figure>
* Work package subject
Viewing relations:
<figure class="image op-uc-figure" style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20038/content"></div></figure>
###
**Open**
* Project name
* Work package id
* Work package status name
* Work package author's avatar
* The autocompleter highlights (e.g. colored background) Does it make sense to re-use the parts of auto-completer provided in the attributes matching the global search string for the attributes
* Work package subject
* Project name
* Work package id
* The work packages are searched by the following attributes. Partial matches, and matches in multiple attributes are also supported.
* Work package subject
* Project name
* Work package id bar (which contains e.g. project information)?
### **User Problem**
#### **User**
_What persona, persona segment, or customer type experiences the problem most acutely?_
* Project managers who use project templates a lot and create work packages by the same name.
* e.g. project which contains engine-parts which are copied over.
#### **Problem**
_What problem or job does the user have?_
* Not clear which project a work package belongs to - especially if work packages have the same name.
* e.g. not clear which model (project name) a part (work package) belongs to.
#### **Pain**
_What is the primary workaround that users perform that we could remove or replace? Why is it painful?_
* The project name can be manually added to the name of the work package. This is however quite bothersome to add and can disrupt users working just within a project. It would also require that each time a project is created from a template, the names are manually adjusted for all work packages which reduces the benefit of using the template.
**I want** to have additional information in
**so that** I can easily distinguish between equally named
#### Proposed solution
Similar
* Project
* Author (via an avatar)
* Status
The currently existing field
* Type
is removed
The currently existing field
* Id
is kept but it is placed differently.
The results of the relation auto completer will look similar to how the search auto completer currently displays its results (without the
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/21423/content"></div></figure>
Currently, only id and subject are considered
* 'company auto completion' -> Work package in project 'lorem ipsum' with subject 'Improve auto completion for Company'
* 'company auto completion' -> Work package in
* '123' -> Work package in
The parts of the fields 'id', 'subject' and 'project' matching the search string are highlighted to convey why a
#### Acceptance criteria
* The autocompleter for managing work package relations (parent, child, follows, precedes, blocks, ...) shows the following elements:
<figure class="image op-uc-figure" style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20036/content"></div></figure>
<figure class="image op-uc-figure" style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20038/content"></div></figure>
###
**Open**
* Work package id
* Work package status name
* Work package author's avatar
* The autocompleter highlights (e.g. colored background)
* Work package subject
* Project name
* Work package id
* The work packages are searched by the following attributes. Partial matches, and matches in multiple attributes are also supported.
* Work package subject
* Project name
* Work package id
### **User Problem**
#### **User**
_What persona, persona segment, or customer type experiences the problem most acutely?_
* Project managers who use project templates a lot and create work packages by the same name.
* e.g. project which contains engine-parts which are copied over.
#### **Problem**
_What problem or job does the user have?_
* Not clear which project a work package belongs to - especially if work packages have the same name.
* e.g. not clear which model (project name) a part (work package) belongs to.
#### **Pain**
_What is the primary workaround that users perform that we could remove or replace? Why is it painful?_
* The project name can be manually added to the name of the work package. This is however quite bothersome to add and can disrupt users working just within a project. It would also require that each time a project is created from a template, the names are manually adjusted for all work packages which reduces the benefit of using the template.