Missing Artifacts

Products

• Rally On-Premise
• Rally SaaS

Issue/Introduction

Losing a user story, defect, test case, or other type of CA Agile Central work items can be frustrating. With the exception of a permanent deletion by another user, it is unlikely that the missing item is gone forever. Below is a list of the most common reasons why you may not be able to find an artifact, and what to do to check or resolve each.

• Search first
• Work item deleted
• Revision histories
• Permissions changed
• Parent story deleted
• Parent story is not on the backlog
• Restore parent associations

 

Resolution

Search first

When you can no longer find a work item, the first thing to do is search for it. The search field in the upper-right corner of any CA Agile Central page will scan the entire workspace for the artifact.

If possible, it's best to search for the full Formatted ID of the missing artifact, such as US1103?

Note: When searching, it's best to be logged in as a workspace or subscription administrator. This ensures that if the artifact was in a project your user no longer has access to, it will be included in search results. See the Permissions changed section below.

Work item deleted

A common cause for missing items is another member of your team deleted the artifact. If you cannot find your item through search, check the Recycle Bin next. The link for the Recycle Bin is at the bottom-right corner of any CA Agile Central page.

Default sorting will show the most recently deleted items at the top of the page. You can select the columns at the top to sort by other criteria, such as Name, Type, and Deleted By. Select the gear icon to the left of a work item to restore it.

Note: Like any CA Agile Central page, the Recycle Bin is pinned to your project picker. Make sure you are looking at the proper workspace or project that the missing item was from and that you have proper access permissions.

Revision histories

If the missing work item was associated to another item in CA Agile Central?a user story, defect, iteration, release?you can check the other item's?revision history?to find the missing artifact.

For an iteration or release, a work item will be removed from these timeboxes if you delete the item or move it to another project. When a work item is moved to another project, the revision will read the same, but will not include the Moved to Recycle Bin text. If the missing item was attached to another artifact, you will also see an entry.

Permissions changed

If you have permission to a project that contains your stories, and an administrator then removes your permissions, you will no longer be able to see those work items.

The easiest way to check for a permission change is to go to the Setup ? Profile page. Select the Revisions link. You may also check with your subscription administrator to see if your access rights have been removed or modified.

Parent story deleted

A user story can be deleted inadvertently if it has a parent. When you delete a parent story, all child stories within are also deleted. When you attempt to delete a parent story, a pop-up displays asking you to verify you want to delete the parent story and all associated children.

When a group of parent and child stories is deleted, only the top-most story will display in the Recycle Bin page. To restore any children inside:

1. Restore the parent user story from the Recycle Bin.
2. Navigate back to the story in its original project.
3. Edit the child user story that was missing.
4. Click the red X icon that appears next to the Parent field.
5. Save the changes. The child story is now independent.
6. Delete the parent story once more, if necessary.

***Restoring the child User Story will add the User Story entry to the Recycle Bin and allow it to be "found" by the API.  This functionality is working as designed.

BEST PRACTICE - In order to make the child stories visible in the Recycle Bin, it will be necessary to delete the child stories first THEN delete the parent story.  

 

Parent story is not on the backlog

Consider the following about parent-child relationships:

• If you add a child user story to an existing user story (now a parent story), the parent story won't display on the Plan ? Backlog page or the backlog view on the Plan ? Plan page.
• When editing a parent user story, the Iteration and Release fields are disabled.
• If a user story is already assigned to an iteration or release, those fields are cleared out if the story is made a parent.
• If a user story has tasks assigned to it, those tasks are automatically moved to the new child story.

This behavior is in accordance with Agile methodology. When you create child stories underneath an existing story, the scope of work is too large to fit into a single iteration. Multiple child stories are completed during several iterations instead, and when all of the work in the children is complete, the status will roll-up to the parent story.

Since the backlog is a collection of work that is ready to be scheduled, and parents are too large to schedule, parents do not display in these locations.

If you are trying to denote a theme of work and do not want to use parent stories, consider these options:

• Use naming conventions in user stories to link them to a common theme.
  • Example: US123 - [Website Redesign] - Improve functionality in Firefox.
• Use tags to track themes of work across user stories.
  • Use the Tagged Story Burndown report for a graphical view of progress on all tagged stories.

Restore parent associations

When you delete a user story that has a parent, the association to the parent is automatically severed when the story is moved to the Recycle Bin. If the story is later restored, it will not be re-associated to the parent automatically.

CA Agile Central's database rules require this behavior, to prevent work items from being restored with an association to a work item that does not exist. For example, Story A is the parent of Story B. Story B is deleted, and a few days later, Story A is also deleted. If Story B is restored without these rules, it would show Story A as the parent, which is a null object. This could cause broken links and problems with various apps and pages.

However, because the association is removed immediately prior to a deletion, the ID and name of the former parent are preserved in the revision history. You may restore parent associations with the following method:

1. Restore the child user story from the Recycle Bin.
2. Navigate to the detail page of the story, then click the Revisions link on the sidebar.
3. Find an entry prior to the delete that states PARENT removed [US123: Story One].?The Formatted ID and name of the former parent are in brackets.
4. Ensure the former parent story is still available in your project.
5. Edit the child user story, then click the search icon next to the Parent field.
6. In the chooser that displays, enter the name or FormattedID of the former parent.
7. Select the parent and save. The stories are now associated.

If you need to parent several restored user stories, consider using the Story Hierarchy app to do this efficiently.