- Frequently Asked Questions
- Organizing and Prioritizing a Backlog
- Troubleshooting
- Integration between Targetprocess and Slack
- Targetprocess System Requirements
- Cannot Prioritize Cards on a View
- How to configure Google OAuth for Email Integration Plugin
- How to configure Outlook OAuth for Email Integration Plugin
Brief summary of this article:
Q: Why is it that when I move an epic into a different project, associated features, user stories, bugs and tasks don't move along with it? Is there a way to do this?
A: Indeed hierarchical links (such as Epic > Feature > User Story > Bug) in Targetprocess do not always limit the assignment of all work items to the same Project / Release etc. The system allows these links and does not consider them as invalid ones.
We plan to make it possible to move a Feature with all its Stories across Projects quickly and easily. This action will be released soon.
For other use cases there we can recommend the following workarounds: filtered views, automatic custom rules, webhooks (deprecated) and Automation Rules.
Filtered views
These views may be created and used by power users to detect orphaned entities and correct broken and missing dependencies manually.
Example of such view: Show Features that are parts of Epics from other Projects.
Cards: Features Filter: ?Epic is not None and Project.Id != Epic.Project.Id
Custom Rules
Use automatic Custom Rules for the use cases that are supported by existing rules. Activate custom rules that fit your needs to prevent issues in future.
An active Custom Rule does not correct existing broken dependencies. They should be still fixed manually.
If you would like to activate one of the rules or check the status of your existing rules, you're welcome to do the following. Being an Administrator, find them at Settings -> System Settings -> Custom Rules -> Activate.
Most likely the ones below will be most helpful:
- Assign team of a story to all its tasks and bugs
- Assign team of a feature to all its stories and bugs
- Assign a Project’s Team to a User Story
- Assign a User Story’s Feature to a Bug
More rules are on the way. So far we postponed implementation of other missing rules. However, we continue to gather the use cases on UserVoice.
Use cases
Project of Feature vs Project of its User Stories
Starting from v3.11.3 User stories will now follow their parent Feature.
Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).
If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.
Release of Feature vs Release of its User Stories
Incomplete User Stories inherit Release field from their parent Feature when they are assigned to the same Project.
The reason behind it is that obviously, we do not want Release burndown chart to be corrupted by moving completed user stories out. And to avoid mess and lost work issues we do not recommend to create stories in projects that are different from the parent Feature.
Create a new user story
Release field of a new user story is set from the Release field of its parent Feature. For this purpose, you should create a new user story in the same project where the Feature is.
Assign user story to feature
Release field of a Feature is inherited by open user stories from the same project that are not assigned to any release yet.
Assign feature to a release
Release field of a Feature is inherited by open user stories from the same project with a similar value set into their Release fields.
Let's consider the data sample. User Story U1 is part of Feature F1. User Story U1 is in the same project where F1 is. User Story U1 is not closed. Here are supported actions:
Use Case | Action | Result |
Feature F1 is not assigned to any Release
User Story U1 is also not assigned to any Release |
move Feature to some Release R1 | U1 is moved to R1 together with F1 |
Feature F1 is in Release R1
User Story U1 is also in Release R1 |
move Feature to other Release R2 | U1 is moved to R2 together with F1 |
Team Iteration of User Story vs Team Iteration of its Tasks
Tasks inherit and follow Team Iteration field from their parent User Story when User Story and Task are assigned to the same Team Iteration or when Team Iteration field as blank in both of them. In this case, whenever you assign a User Story to some other Team Iteration, the same assignment is made for Task automatically. However, Tasks can be re-assigned manually to other Team Iteration. Then changes of User Story assignments are no longer reflected in Tasks.
Still have a question?
We're here to help! Just contact our friendly support team.