Overview
The goal of this story is to introduce a level of flexibility in the parent/child relationship between artifact. Until now, everything is under "Tracker Hierarchy" control, that is to say for an artifact to be a child of another one, it has to be blessed by Tracker Hierarchy regarding the configuration (hence tracker based).
Tracker Hierarchy is structural for a couple of very important features:
- Agile Dashboard Scrum (Planning, Taskboard, ...)
- Triggers
Hence it's not something we can remove without large consequences.
This story introduce a different approach where Tracker Hierarchy shifts from enforcing the parent/child relationship to an helper that "guides" this relationship.
Tracker Hierarchy as an helper
- Tracker Hierarchy stay as it is: one parent tracker, N child trackers.
- However,
_is_child link type can be set on any artifact link, regardless of the hierarchy defined
- The apps consuming
_is_child (planning, cardwall, taskboard) renders children regardless of the hierarchy
- The apps creating children (Planning, Cardwall, Taskboard) must create links in the right order and with
_is_child type
- When creating a children between 2 artifacts at tracker level, the type must be provided
- The "auto correction" of links that allowed to create a children by just linking a child to a parent is removed, a warning is displayed in this context to inform the users about the change of behaviour.
- When changing the hierarchy in tracker administration, links are no longer updated to match the new hierarchy.
- That is to say after changing the hierarchy, the tracker administrator will have to change links type one by one.
- We consider this operation is rare enough to be done by hand.
- Triggers that relies on tracker hierarchy doesn't change
- The computation of the status will still be done with artifacts from the children defined by the tracker hierarchy
- A warning is displayed in Tracker Hierarchy page to inform admins about that
- A warning is displayed to users when they add a _is_child type AND there is a trigger on the tracker.
Parent/child without the tracker hierarchy
- When using the apps (Planning, Cardwall, Taskboard) thinks will be transparent as it's handled directly by the app itself
- When team want to add a child "outside the hierarchy" they will have to do it "under the hood" directly at artifact level by adding the child with the
_is_link type
_is_child link type
_is_child link type can no longer be disabled and will be force-enabled in all projects.- some projects might see changes if they defined _is_child links between artifacts without having a tracker hierarchy (before the parent/child relationship was not used, after it will be).