OpenProject/Ticket relation: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 4: | Zeile 4: | ||
**''Parent-Child relation'' | **''Parent-Child relation'' | ||
**''Follows or proceeds, blocked by, part of, etc.'' | **''Follows or proceeds, blocked by, part of, etc.'' | ||
=Work package relations= | |||
*Work package relations indicate that work packages address a similar topic or create status dependencies. | |||
*To create a relationship between two work packages: | |||
#Select a work package, click on Relations to open the relations tab and click the + Create new relations link. | |||
#Select the type of relationship from the dropdown menu. | |||
#Enter the ID or name of the work package, to which the relation should be created and choose an entry from the dropdown menu. | |||
[[Datei:Relation.png|mini|ohne|Relations between Work Packages are useful to establish a time schedule for every task]] | |||
*You can select one of the following relations: | |||
**'''Related to''' – This option adds a link from the work package A to work package B, so that project members can immediately see the connection, even if the work packages are not members of the same hierarchy. There is no additional effect. | |||
**'''Duplicates / Duplicated by''' – This option indicates that the work package A duplicates a work package B in one way or another, for example both address the same task. This can be useful if you have the same work package that needs to be a part of a closed and public projects at the same time. The connection in this case is semantic, the changes you make in work package A will need to be adapted in work package B manually. | |||
**'''Blocks / Blocked by''' – This option defines status change restrictions between two work packages. If you set a work package A to be blocking work package B, the status of work package B cannot be set to closed or resolved until the work package A is closed (in a clode meta-status). | |||
**'''Precedes / Follows''' – Defines a chronologically relation between two work packages. For example, if you set a work package A to precede a work package B, you will not be able to change the starting date of B to be earlier than the end date of A. In addition, when you move the start or due date of A, the start and due date of B will be updated as well. | |||
**'''Includes / Part of''' – Defines if work package A includes or is part of work package B. This relation type can be used for example when you have a rollout work package and work packages which should be shown as included without using hierarchical relationships. There is no additional effect. | |||
**'''Requires / Required by''' – Defines if work package A requires or is required by work package B. There is no additional effect. |
Version vom 1. Februar 2021, 16:43 Uhr
Introduction
- Relations between work packages are used to give a Hierarchical structure to the work packages
- Hierarcies indicate any functional or timely relation:
- Parent-Child relation
- Follows or proceeds, blocked by, part of, etc.
Work package relations
- Work package relations indicate that work packages address a similar topic or create status dependencies.
- To create a relationship between two work packages:
- Select a work package, click on Relations to open the relations tab and click the + Create new relations link.
- Select the type of relationship from the dropdown menu.
- Enter the ID or name of the work package, to which the relation should be created and choose an entry from the dropdown menu.
- You can select one of the following relations:
- Related to – This option adds a link from the work package A to work package B, so that project members can immediately see the connection, even if the work packages are not members of the same hierarchy. There is no additional effect.
- Duplicates / Duplicated by – This option indicates that the work package A duplicates a work package B in one way or another, for example both address the same task. This can be useful if you have the same work package that needs to be a part of a closed and public projects at the same time. The connection in this case is semantic, the changes you make in work package A will need to be adapted in work package B manually.
- Blocks / Blocked by – This option defines status change restrictions between two work packages. If you set a work package A to be blocking work package B, the status of work package B cannot be set to closed or resolved until the work package A is closed (in a clode meta-status).
- Precedes / Follows – Defines a chronologically relation between two work packages. For example, if you set a work package A to precede a work package B, you will not be able to change the starting date of B to be earlier than the end date of A. In addition, when you move the start or due date of A, the start and due date of B will be updated as well.
- Includes / Part of – Defines if work package A includes or is part of work package B. This relation type can be used for example when you have a rollout work package and work packages which should be shown as included without using hierarchical relationships. There is no additional effect.
- Requires / Required by – Defines if work package A requires or is required by work package B. There is no additional effect.